This view of service management...

On the origin and the descent of managing services. We put meat on the bones.

Visualization of Configurations

by Leave a Comment

In this article, I will delve into some of the issues associated with vi­su­a­liz­ing the con­fig­u­ra­tions of systems.

As with many other dis­ci­plines in ser­vice ma­nage­ment, the use of vi­­s­u­a­l­i­­za­­tions in con­fig­u­ra­tion ma­nage­ment can be prob­lem­atic. I hope to highlight some of these issues with a view toward:

  • improving the func­tionality soft­ware de­ve­lop­ers build into con­fi­gu­ra­tion ma­nage­ment
  • expand­ing how con­sumers of con­fig­u­ra­tion in­for­ma­tion make use of vi­­su­­a­l­i­­za­­tions.

Many IT or­gani­za­tions have a high opinion of tools pro­vid­ing vi­­su­­a­l­i­­za­­tions of con­fig­u­ra­tion in­for­ma­tion. One or­ga­ni­za­tion with which I worked 15 years ago used this ca­pa­bi­lity to jus­tify choos­ing a par­ti­cular ITSM tool. I was not sur­prised, how­ever, when they never used that ca­pa­bi­lity as part of their con­fig­u­ra­tion ma­nage­ment work. It was a good exam­ple of an ex­cite­ment factor in a product or even a reverse quality. But why was this so? What qualities should vi­­su­­a­l­i­­za­­tions have for them to become per­for­mance fac­tors in manag­ing con­fig­u­ra­tions?

Scope of this discussion

By “con­fig­u­ra­tion vi­su­a­li­za­tion” I mean vi­su­a­liz­ing the structures of systems. A sys­tem consists of a set of elements that may relate to each other in many ways. A con­fig­u­ra­tion vi­su­a­li­za­tion should identify:
  • the system being visualized
  • the scope of the particular elements in the system being visualized
  • the dimensions of re­la­tion­ships among ele­ments being visualized.
For example, a system might be the set of nodes in a network to which data packets may be addressed. Those nodes are generally some sort of computing device, such as general-purpose computers, routers, prin­ters, load balancers, etc. These nodes might relate to each other in many different ways. They might be phy­si­cally connected. They might be able to route data to each other. They might follow each other as part of a business transaction, and so forth. Con­fig­u­ra­tion vi­su­a­li­za­tions represent the struc­tures of systems. Designers do not intend them to directly represent the dy­na­mics of those systems. These vi­su­a­li­za­tions do not have the purpose of describing a process or any sequence of events. That being said, the vi­su­a­li­za­tions of such events generally include the nodes at which the events take place. Designers often present these nodes in a structured way based on a con­fig­u­ra­tion vi­su­a­li­za­tion. Consider the difference be­tween the map of a trans­por­ta­tion network (e.g., Fig. 1) and the display of the route to follow for a particular journey (e.g., Fig. 2). Building the itinerary—a process vi­su­a­li­za­tion—on the foundation of the former—a structure con­fig­u­ra­tion—greatly enhances its usefulness.
TPG network map
Fig. 1: A configuration visualization of a transportation network shows the possible routes, their spatial relationships and the possibilities for interconnection.
itinerary
Fig. 2: A process visualization of the use of a transportation network shows a specific itinerary. In this case, it also shows the timing of events.

In sum, the con­fig­u­ra­tion vi­su­ali­zations I will discuss here document only the struc­ture of a system. They do not document the activities of managing that system or even the activities of managing the sys­tem’s structure. However, con­fig­u­ra­tion vi­su­a­li­za­tions gene­ral­ly document structures from the perspective of only one, or perhaps a few, func­tions of the system.

Configuration Visualization Tense, Aspect & Mood

When documenting con­fig­u­ra­tions we may speak of various
  • tenses—when the depicted con­fig­u­ra­tion exists (past, present, future)
  • aspects—does the visu­ali­za­tion re­pre­sent a single mo­ment, an ex­tend­ed period, a series of re­pe­ti­tions; and
  • moods—the attitude of the visualization de­sign­er to the documented structure, or how the designer in­tends the viewer to relate to the visualization.

Configuration Tenses and Aspects

Often, we wish to know the con­fig­u­ra­tion of a system in the current tense. How is the system con­figured now? People changing systems also want to know the future tense of the con­fig­u­ra­tion. After a change will be made, what will the con­fig­u­ra­tion look like? (Such con­fig­u­ra­tions might be understood as imperatives rather than futures since changes often have unexpected or undesired results.) Part of the diagnosis of a problem involves un­der­stand­ing how a system was configured in the past. Sometimes the di­ag­nos­tician wishes to know the past perfect (aspect) configuration. This aspect might show how the system was configured at an instant in the past (perhaps as part of an incident). Other times the con­fig­u­ra­tion stakeholder needs to know the past im­per­fect con­fig­u­ra­tion—the con­fig­u­ra­tion dur­ing a con­tinu­ous period in the past. One might also consider in­ten­tion­ally tem­po­rary con­fi­gu­rations, often as part of a transitional phase in a series of changes.

Configuration Moods

The above examples mainly concern the indicative mood. Planners of potential changes also take interest in the conditional mood. “If we make such and such a change, what would the resulting con­fig­u­ra­tion look like.” Con­fig­u­ra­tion controllers need to distinguish between the in­di­ca­tive—what is the cur­rent con­fig­u­ra­tion—and what the current con­fig­u­ra­tion should be. Architects might establish jussive prin­ci­ples—principles that the org­ani­za­tion expects every con­fig­u­ra­tion to follow. Finally, stra­te­gists and high-level architects concern them­selves with the subjunctive, pre­sump­tive or optative moods. “If we were to adopt the following principles or strategies, what might the resulting con­fi­gu­ration look like?” As often as not, such hypotheses serve to discredit a certain approach

Conventions for Visualizing Moods and Tenses

Unfortunately, authorities provide no standard visual techniques to distinguish among these various tenses, aspects and moods. Vi­su­al­i­za­tion designers must resort to labels as the means to distinguish be­tween what was, what is, what will be, what should be and what could be. And, un­for­tunately, de­sign­ers seldom indicate these moods in their vi­su­al­i­za­tions. At most, they indicate the initial pub­li­ca­tion date, or perhaps the date of the last update.

Intelligent Visualization Tools

I suggest here how intelligent visualization tools might ex­press the various tenses and moods described above.

Animation

Analysts often wish to compare two con­fig­u­ra­tions of the same system, differing by tense or mood. Animation provides an in­tu­i­tive way to achieve this by highlighting the transitions between states. For example, a visualization might have a timeline with a draggable pointer. The viewer drags the pointer to the desired date (past, present or future) and the tool updates the con­fig­u­ra­tion accordingly.

If the visualization depicts a small number of changes to a system, animating each change separately makes the nature of the change more visible (see Fig. 3).

Fig. 3: An example of an animated change to a server cluster. Animation makes visible each change (namely, the new servers and their connection to the load balancer).

Animation may be useful but only under various con­di­tions. First, the elements that change must be visually distinct. For example, visu­ali­zation viewers might have great difficulty per­ceiv­ing the change from IP address 2001:171b:226b:19c0:­740a:­b0c7:­­faee:­­4fae to 2001:171b:226b:19c0:­740a:­b0c7:­­faee:­­4fee. The tool might mitigate this issue by high­lighting changes For example, the visualization designer might depict the background of changed ele­ments using a contrasting color.

Second, a stable, unchanging visual context should surround the elements that do change. Lacking this stability, the viewer might have great difficulty visualizing what has changed.

Third, the layout of the elements should be stable (excepting those that change, of course). For example, if two new elements replace a single element in the upper right corner of a visualization, those new elements should also be in the upper right corner. Tools automating the layout of elements using a force-directed placement al­go­rithm might not respect this constraint. Such al­go­rithms intend to position the elements and their links in the most legible way.

For example, they might attempt to make all nodes equidistant and minimize the number of crossed links. However, if the change involves a significant increase or decrease in the number or size of elements, such algorithms might radically change the layout. The change in layout makes it difficult to perceive the change. Allowing for very slow animation might mitigate this issue.

See also Fig. 8.

ERD generated by phpmyadmin
Fig. 4: This illegible entity-relationship diagram generated by phpmyadmin exemplifies the usefulness of force-directed algorithms

Color Saturation

Visualization viewers can easily detect the saturation, or vividness, of color (although certain people might have difficulty seeing colors). We might assign different levels of saturation to different tenses or moods (see Figs. 5–7). Of course, such a convention would require training to be correctly understood.

Color saturation used for configuration tense—past
Fig. 5: A past configuration. Saturation 95%
Color saturation used for configuration tense—present
Fig. 6: A present configuration. Saturation 45%
Color saturation used for configuration tense—future
Fig. 7: A future configuration. Saturation 15%

Used in conjunction with animation, though, the change in saturation would both highlight the change and be intuitively obvious (Fig. 8).

Fig. 8: An example of combining animation and color saturation to indicate a change in configuration tense. The unsaturated color indicates a future configuration. Of course, the animation could be more sophisticated but would be labor-intensive and its creation very hard to automate.

Designers might use many other attributes of color to indicate different moods or tenses. However, we already use most of these attributes for various other purposes. Using such attributes as hue, which often indicates element type or location, to reflect mood or tense risks creating confusion.

Watermarks

Watermarks might be an excellent means for indicating the tense or mood of a con­fig­u­ra­tion visualization. Authors often use them to distinguish between a draft version of a document and a final version. A simple text watermark highlights in an un­ob­trusive way precisely which con­fig­u­ra­tion the visualization depicts.

One might imagine that a visualization without any water­mark would represent the present. Any other tense or mood would have the pertinent watermark. To correctly interpret older vi­su­al­i­za­tions, they should display the date at which the visualization was last known to be valid.

Future configuration with watermark
Fig. 9: A future, planned configuration with a watermark

Multi-dimensional configuration visualizations

As with the analysis of any data sets, visualization de­signers often find it very useful to reduce the number of dimensions being analyzed.

When I speak of “multi-dimensional” vi­su­a­li­za­tions, I am referring to more at­tri­butes than just the po­si­tion­ing in Car­tesian space. In addition to “2D” or “3D” di­men­sions, I refer to any other attributes of a system’s elements or re­la­tion­ships use­ful for depiction and analysis.

As I mentioned above, a visualization takes the per­spec­tive of one or a few functions of the system being documented. Let’s take the example of the map of a transportation net­work (see Fig. 10) to illustrate this point.

LIRR map
Fig. 10: The configuration of a transportation network

The network functions to transport people or goods from place to place. Therefore, the map must give an idea of the relative positions of those places and, often, their surroundings. Often, the map depicts these positions schematically, but close enough to “reality” to be useful. A second dimension of the map illustrates the pos­sible in­ter­con­nections a­mong routes. A third di­men­sion might indicate the types of vehicles used on the line, such as train, boat, bus, etc.

The map depicts each di­men­sion using a different con­ven­tion. It might indicate sta­tions with a circle or a line per­pen­di­cular to the route, together with the stations’ names. Different colors might indicate the various possible routes. Solid or dashed lines might indicate the type of vehicle. Other symbols might indicate the types of inter­changes.

Only the designer’s imag­i­na­tion and the visualization’s messages limit the types of dimensions that a con­fig­u­ra­tion vi­su­a­li­za­tion might display. The classical di­men­sions include:

  • position—the coordinates or relative location of an element in two- or three-dimensional space
  • ontological classification of element type—the classification of the esvsential nature of the element, such as “computer”, “printer”, “modem”, etc.
  • ontological classification of re­la­tion­ship type—if the visualization depicts relationships among ele­ments, what are the types of relationships, such as “is part of”, “is connected to”, “depends on”, etc.

Other dimensions might include, for example, the age of the element, its manu­fac­turer, its model, its vendor, its gua­ran­tee status, its main­te­nance contract status, etc., etc. and so forth.

Visualization idioms

Designers use various types of visualization idioms to depict static configuration infor­ma­tion:
  • node-link diagrams (graphs or directed graphs)
  • enclosure diagrams
  • treemaps
  • adjacency matrixes
  • labeled illustrations.
Needless to say, designers regularly innovate new idioms useful for this purpose.

Directed Graphs

directed graph
Fig. 11: A simple directed graph

Components of directed graphs

A graph consists of a set of nodes some of which are connected by lines, called “edges”. A directed graph is a graph whose edges have directions. Con­fig­u­ra­tion ma­na­gers com­mon­ly use directed graphs to represent a network of components, such as com­pu­ters and other active network de­vices. Node-link diagram is a synonym for directed graph in this context.

Handling the complexity of directed graphs

Unless the system do­cu­mented by the vi­su­al­i­za­tion is trivially small, a directed graph quickly becomes unwieldy. The tool creating the visualization may handle the complexity of such systems in four ways:

  • it uses an algorithm, such as force-directed place­ment, to position nodes in as pleasing a way as possible
  • it can collapse collections of nodes into individual symbols
  • it can filter the diagram based on any dimensions of the nodes and/or edges
  • it can limit the scope of the diagram, generally by showing a limited number of edges

Collapsing nodes uses such principles as physical location or logical function. For example, all nodes located in a building, a floor, a room, a city, etc. may be collapsed into a single symbol. Thus, a cluster of computers each with the same function may be collapsed into a single node. Inter­ac­ti­vity with the viewer makes such diagrams most useful. The visualization user should be able to collapse and expand nodes at will or filter on node and link attributes.

Managing link ambiguity

visualization with ambiguous links
Fig. 12: Ambiguous relationship—all links are the same
visualization with different link styless
Fig. 13: Relationship type indicated by link style
visualization with labeled links
Fig. 14: Relationship type indicated by text labels

Any two nodes in a socio-technical system may interact in a variety of ways. Consider the relationships between a set of devices used in an organization and its various teams or personnel. In a graph, what does an edge between a certain machine and a certain team or other entity signify (see Figs. 12-14)? It might indicate many dif­fe­rent types of interactions, such  as:

  • the team uses the machine to achieve its business purpose
  • the team operates the machine so that others might use it
  • the team supplies the machine, being either a vendor or procurer
  • the team repairs the machine
  • the entity manufactures the machine
  • etc.

Thus, each edge or link should characterize a relationship be­tween two nodes ex­pres­sible as a verb (see Fig. 14). Unfortunately, many con­fig­u­ra­tion managers—as well as the tools they use—use verbs so ambiguous that they add little value to the ma­nage­ment of con­fig­u­ra­tions. “Depends on” and “relates to” offend the most. These catch-all terms mean “a relationship exists, but one unlike any type of re­la­tionship that we have already defined.”

Of course, a single entity or team might have multiple types of relationships with a single element. A semantically un­am­bi­guous visualization would require a separate link type for each type of re­la­tion­ship between any two nodes. But this approach quickly clutters the diagram, ren­der­ing it less legible. The visualization becomes a poorer communication  vehicle (un­less the vivsu­al­i­za­tion purports to de­scribe that com­pli­ca­tion). As a result, some vi­su­ali­za­tion designers collapse multiple relationship types into a single type of edge or link. The resulting vi­su­ali­za­tions might be simpler to view, but their ambiguity makes them much more difficult to in­ter­pret. Thus, they would be much less useful for any particular purpose.

Links and modes of visualization

Recall the discussion above about visualization modes. Designers of directed graphs often ignore this concept and mix different modes. A precise visualization would depict only a single mode at a time. The same issue applies to any con­fig­u­ra­tion vi­su­al­i­za­tion idiom. I address it here given the popularity of using directed graphs for docu­ment­ing configurations.

As an example, let us consider a vi­su­ali­za­tion of nodes and the com­muni­ca­tion of data packets among them. We might be interested in the im­per­fect indicative aspect of such a system. In other words, between which pairs of nodes are packets being sent. Or, we might be interested in the pairs that could transmit data to each other, whether they do or not. Or, we might want to see the pairs that should be sending packets to each other, again, whether they do or not. Capacity management can make good use of all these modes. Others are par­ti­cu­larly interesting for problem or inci­dent ma­nage­ment. And yet others are useful for system design, availability, release and change ma­nage­ment.

Tools may draw graphs of a particular by gathering data from various management tools. Network sniffers can gather the data about which pairs of nodes are com­mu­ni­cating with each other. An appropriate lapse of time must be selected for per­forming this analysis.

Describing which nodes could com­mu­ni­cate with each other requires knowledge of both the physical connection layer and the network layer.  Intelligent switches could report which nodes have physical connections. Routers and firewalls could report the rules allowing for or forbidding the routing of data. The visualization tool could then draw a diagram based on this data. But however could a tool automate the creation of a diagram depicting the lack of com­mu­ni­ca­tion between nodes? Tools can hardly detect physical connections that do not exist.

Such visualization auto­ma­tion might suffer from several constraints. Firstly, a com­mu­ni­ca­tion defect might prevent the collection of the very data useful for managing an incident. Secondly, while the tool could collect current and historical data, collecting data for a planned, future con­fi­gu­ra­tion would ad­di­tion­ally require some simulation capability.

Link density

Link density is a key metric for managing graphs. This metric measures the ratio of edges to nodes in the graph. If the link density is greater than three or four, it becomes very difficult to interpret the graph. The drawing tool should be able to detect link density and propose a collapsed, initial view of the system with a lower link density. The view should then have the chance to in­ter­actively filter the data displayed and expand col­lapsed nodes.

Strengths
  • Ease of tracing node to node paths
  • Interactive features permit scaling over a very wide range
 

Weaknesses
  • Easy to confuse the functional purposes and directions of edges
  • High link density renders the diagram illegible
  • In large diagrams, it may be difficult to find nodes by visual scanning of the diagram
  • Non-deterministic positioning of nodes
 

Treemaps

treemap at city level
Fig. 15: A treemap showing the relative number of nodes in a system by country and then by city.
treemap at node level
Fig. 16: The same data, but with the nodes themselves indicated.

Most systems consist of elements whose attributes may be organized in a hierarchic taxonomy. The physical locations of the nodes in a system provide a simple example of this. Consider the hierarchy Country→City→Site→­Building→­Floor→­Room. Suppose you wish to analyze the numbers of end nodes of a data network, by location. A treemap gives an immediate view of the site or building or room that has any number of such nodes.

If the visualization tool allows for searching based on node identifiers, a treemap also gives a quick means for visualizing the value of the attribute for a given node. For example, suppose you seek the node “ABC123”. If the tool shows it in a contrasting hue, you can see immediately its position in the hierarchy.

Fig. 17: In this variant of the treemap, called a "circle packing", a query on a certain model of the node reveals the blue dots (5, 13, 26, etc) and where they are located. Note that that model is used only in Switzerland.

This feature may be expanded to include queries on at­tri­butes outside of the taxonomy (see Fig. 17). For example, suppose you have a treemap showing the lo­ca­tions of the desktop computers. You do a query to display the computers of a certain model. You see im­me­di­ately the location and the clustering of those computers.

In theory, a treemap might document different node at­tri­butes at different levels of the hierarchy. However, viewers are likely to have difficulty interpreting such maps.

Strengths
  • Easy to document a very high number of leaf nodes
  • Fast querying of the attributes of leaf nodes
  • Easy to judge relative quantities of leaf nodes at a given level of the hierarchy
Weaknesses
  • Only useful for single attributes in a hierarchic taxonomy
  • Groupings are completely abstract, bearing no relationship to the real layout of the nodes

Adjacency Matrixes

adjacency matrix
Fig. 18: This adjacency matrix documents 10 nodes showing—in this example—both the direction of communication (arrows) and the bandwidth of the link (colors).

An adjacency matrix has all the nodes to be documented laid out on both the vertical and horizontal axes. The information in the cells at the intersection of the columns and rows documents the relationships between the corresponding two nodes.

Depending on the link attributes being documented, the matrix might contain re­dun­dant information. For example, in Fig. 18 the color of cells 1:2 and 2:1 must be identical. On the other hand, the arrows may be different.

Fig. 18 shows a very simple adjacency matrix. A more sophisticated matrix might add rows and columns to document other attributes of the nodes. An analyst might use the values in these additional cells to inter­ac­tive­ly sort and filter the matrix. Thus, adjacency matrixes can be powerful analytical tools.

Strengths
  • Scalability even with high link density systems
  • Fast lookup of nodes (if  listed in a structured order, such as alphabetically)
Weaknesses
  • May require training to make good use of the diagrams
  • Difficult to analyze topologies

Enclosure Diagrams

node-link diagram of failover cluster
Fig. 19: Even a simple node–link diagram of a failover cluster can be messy, with many edges.
enclosure diagram of failover cluster
Fig. 20: An enclosure diagram of the same cluster is much more elegant.

An enclosure diagram dis­plays one or more collections of nodes around which a line is drawn. Vi­su­al­i­zation designers com­mon­ly use enclosure diagrams to display clusters of nodes with similar functions. An example might be a set of IT servers that can fail over to each other. Figs. 17 & 20 provide examples, wherein nodes are enclosed by a set of circles.

An enclosure diagram is thus visually cleaner and simpler than a directed graph. Suppose a cluster contains four servers that can fail over to each other. A directed graph would require ten edges to display the cluster (see Fig. 19). An enclosure diagram would require only two lines (see Fig. 20).

Strengths
  • Visual simplification, as compared to a directed graph
Weaknesses
  • The layout of multiple enclosures within a complex system may be very difficult to compute

Labeled Illustrations

Rack mounted telephone equipment
Fig. 21: A labeled illustration of a system, such as this telephone equipment rack, and its installed components, is an excellent way to help identify the parts when you are viewing or seeing that system. This configuration visualization method is very old.

Product managers or manu­fac­turers often use labeled illustrations to help device managers to understand what they see. For example, a technician might enter a ma­chine room to remove a device from a rack. A labeled illustration of that rack could indicate the slots and the locations of the installed devices. Technicians find such illustrations especially useful if the devices themselves are poorly labeled. Examples in­clude labels being damaged, lost, too small to read, or in inaccessible positions.

Service agents might also use such illustrations for identifying the type of system before their eyes. This is especially true if the organization de­scribes the attributes of the system using a highly standardized taxonomy. Anyone having used a guide book to identify birds or plants understands this.

switch icon
Fig. 22: Although icons are compact, recognizable functional symbols, they do not help to identify the model or serial number of a component (unless labeled)
fiber channel switch
Fig. 23: Service personnel can use illustrations to identify a specific component or its model; a label identifies its serial number.

Thus, the illustration designer makes a trade between the level of detail shown and the details helping to identify the object. In other words, the designer should abstract the gestalt of the object in question. For example, a data switch model might be readily identifiable by its overall shape, the number and the layout of its ports and other significant details.

Strengths
  • Easy identification of the components of a system
Weaknesses
  • May require a library of component images
  • May require specialized functionality in the drawing tool to correctly place components within the system
  • Not useful for physically large systems (like a data network) or abstract components (like a database or an application)

Hybrid visualizations

We have seen that many different visualization idioms have the capability of doc­u­ment­ing con­fig­u­ra­tions, especially net­works of ele­ments. Each has its strengths and weaknesses. Why not make hybrid visualizations, combining the strengths and palliating the weaknesses?

Containers work well at the highest level of a vi­su­al­i­za­tion. They effectively portray com­plete­ly separate domains and parent-child relationships within a domain. Al­though they can also overlap, as in a Euler diagram, such visualizations provide little information about the nature of the shared area.

Graphs or trees may effectively document the higher-level details within a container. If the number of nodes is not too great, they could go to the leaf level. In particularly complex struc­tures or hier­archies with many levels, con­tainers might in­di­cate sub-graphs. A drill-down function would allow viewers to visualize the details within those containers.

A network of great depth may be too confusing or too computationally intensive to display a graph’s full level of detail. Illustration designers may resolve this problem by replacing rooted sub-graphs by adjacency matrixes, trees, treemaps or, as we saw above, containers.

Failure to benefit from con­fig­u­ra­tion visualizations

It would seem that con­fig­u­ra­tion data has everything to gain from visualizations. System stakeholders have difficulty in grasping the connectivity of IT com­po­nents using words alone. And yet, so few or­ga­ni­za­tions really benefit from creating diagrams. Why is this so?

In include among the reasons:

  • Inaccurate and in­com­plete un­der­pinning data
  • Not following Shnei­der­man’s mantra
  • No direct relationship between higher-level archi­tecture diagrams and phy­sical layer diagrams
  • System component re­la­tion­ships too complex for easy diagnosis via vi­su­ali­za­tions

Inaccurate and incomplete data

The problem of inaccurate or incomplete con­fig­u­ra­tion data is not, strictly speaking, a visualization issue. None­the­less, I will brief­ly summarize some of the reasons for this issue.

Consider, though, that a visualization drawn directly from data recorded in some database can hardly depict missing in­for­ma­tion. If a cluster contains ten servers but the con­fig­u­ra­tion ma­nage­ment system records only seven of them, do not imagine that the visualization will show the ghosts of those three missing machines.

Maintaining con­fig­u­ra­tion data as an afterthought

Service personnel often consider main­taining con­fig­u­ra­tion data as non-essen­tial administrative overhead. Up­dat­ing the data is a low priority step distinct from performing the corresponding changes. As a result, that personnel sometimes do not update data at all. Or, they might update data long enough after the fact that the details are no longer fresh in mind.

Configuration discovery as an afterthought

Some organizations attempt to address the poor integration of data ma­nage­ment into change activities by automating the dis­co­very of new or changed con­fig­u­ra­tions in a system. Indeed, recording of con­fig­u­ra­tion data often not established at the very start of a system’s creation. In such cases, automated con­fig­u­ra­tion discovery is often adopted as the means to address the daunt­ing task of documenting existing con­fig­u­ra­tions. And yet, such automated dis­co­very is often blocked in its attempts to discover. Furthermore, it often reports unmanaged ele­ments and attributes, need­lessly com­pli­cating the data. And automated dis­co­very can circumvent the intellectual process of strug­gl­ing with un­der­standing how a system is pieced together. It can thereby yield large quantities of data without much un­der­standing of how to use those data.

Unmanageable quantities of data

How do organizations mea­sure the “quality” of the con­fig­u­ra­tion management? I have often seen them use the percentage of con­fig­u­ra­tion elements registered in a database. They struggle to move incrementally up­wards from a very poor 10%. By the time they reach 70%, their progress thrills them and the effort exhausts them so much that they reach a barrier beyond which they hardly advance. They trot out a cost-benefit analysis to justify why it is OK to make only a symbolic effort to maintain or enlarge these data.

Shneiderman's mantra

Ben Shneiderman described the process of finding in­for­ma­tion from a visualization as:

  1. overview first
  2. zoom and filter
  3. details on demand

So common is this org­an­i­za­tional principle, vi­su­al­i­zation tool designers have come to view it as a mantra.

Most ITSM tools with con­fig­u­ra­tion diagramming cap­a­bi­lity do indeed provide zooming and filtering cap­a­bility. Many allow the viewer to see the details of a component via a simple mouse-over or other simple technique. The problem is in how an overview is defined and how users implement the concept of an overview.

In the worst case, an “overview” is implemented without any aggregation of detail. In other words, For example, suppose you doc­u­ment a data center with 500 physical servers. A graph overview might attempt to display those 500 servers with their various network con­nec­tions. The processing power of the computers used to do this is probably inadequate for the task. Even a high-resolution screen could only allocate a few pixels to each server, making the entire diagram useless. The network connectivity of the servers would probably be so com­plicated that the screen would be filled with black pixels.

Showing more components is not a useful way to provide an overview. There must be some aggregation principle applied, one that allows for the sim­pli­fi­cation of the vi­su­al­i­za­tion. Systems with very few components are the exception to this principle. In the latter case, visualization would have relatively little benefit.

The nature of the aggregation depends entirely on the purpose of the visualization. There is no single “right” aggregation prin­ciple. Com­po­nents could be aggregated based on the business functions they support. Another form of aggregation could be the models or versions of components. Physical location at various levels would be another example. Thus, an overview might show first the racks in the data center. With an average of twenty servers per rack, a much more manageable twenty-five nodes would appear in the initial overview.

Remember that this ag­gre­ga­tion is not a form of filtering. Instead, the vi­su­al­i­za­tion needs to display an aggregate as a single glyph or shape. Suppose you wish to depict the set of components supporting a given business function, such as all financial ap­pli­ca­tions. You might achieve this using a rectangular box with three overlapping computer icons. An overview visualization might show as many such rectangular boxes as there are supported business functions. It would then be possible to zoom in to a single rectangle and filter the visualization according to other principles.

Such an approach would adequately im­ple­ment Shnei­der­man’s mantra, but most ITSM tools do not implement the required logic. After all, the business function is an attribute of the application running on the server, not of the server itself. Most users of these tools do not structure configuration data in a way that would support this approach. I cite various reasons for this:

  • Con­fig­u­ra­tion managers make illogical shortcuts in the con­fig­u­ra­tion data model. As per the example above, they assign a business function to a computer, rather than to the ap­pli­ca­tion processes running on that computer.
  • Some organizations have decided to treat archi­tec­tural data, where po­ten­tial aggregation prin­ciples are defined,  separately from service management con­fig­u­ra­tion data. Never the ‘twain shall meet.
  • Even when con­fig­u­ra­tion management tools reflect arch­i­tec­tural principles, how should such data relationships be modeled? Should managers use a framework like TOGAF? Would or­gan­i­za­tions with­out architectural ex­per­tise give in to unwarranted sim­pli­fi­ca­tions? By what means would one know that a physical server supported a finance func­tion: via an attribute of the server itself? via an attribute of the ap­pli­ca­tions installed on the virtual servers realized on the physical server? via an attribute of a functional component of an ap­pli­ca­tion?
  • Functional aggregation would require both know­ledge of the static structure of the com­po­nents and their dynamic use. For example, knowing which functions a message bus channel sup­port depends on know­ing the functional domains of the messages using that channel. A similar problem exists for levels 1, 2 and 3 network components. Short-cir­cuit­ing these is­sues by hard-coding attributes of the components leads to documentation that is exceedingly difficult to maintain.
  • Many con­fig­u­ra­tion ma­nage­ment tools lack the simple functionality that proper diagramming might require. For ex­ample, many of the edges in a graph re­pre­sent­ing a network of components should be bi-directional. And yet, how many tools can simply model this physical reality?

Segregated architectural drawings

Architectural drawings are a subset of con­fig­u­ra­tion vi­su­al­i­za­tions. They are subject to the same con­straints as other vi­su­al­i­za­tions. In many fields, there is a direct relationship between an ar­chi­tect’s draw­ing and the physical objects to be created based on that drawing. In some fields and organizations, however, there appears to be a barrier be­tween the visualizations created by ar­chi­tects and the visualizations of the cor­re­spond­ing physical layer. Many IT departments are a case in point.

There are various reasons for this segregation, which may be organizational, pro­ce­dural or technical in nature. This is not the right place to investigate these reasons in more detail. But the result is often that IT arch­i­tec­tural drawings are generally created from tools specific to the architecture role. These tools may be of two types. Some draw diagrams based on the data in an underpinning database managed by the tool. Others are dedicated to the production of IT arch­i­tec­tural diagrams, with­out an underpinning database. On the other hand, the con­fig­u­ra­tion diagrams are created either from service management tools or from dedicated drawing tools.

In theory, organizations should have some policies, procedures and techniques for ensuring the coherence be­tween ar­chi­tec­tural data and con­fig­u­ra­tion ma­nage­ment data. While good coherence probably exists in some organizations, I have never seen it myself. At most, I have seen one-off attempts to co-ordinate, for example, a list of IT services as defined in the service management tool with the list defined in the architecture tool. The result has been two lists with two different owners and no practice of keeping the lists synchronized. In time, however, there will probably be increasing convergence between ar­chi­tec­ture and service ma­nage­ment tools.

architecture diagram and configuration diagram
Fig. 24: A configuration illustration detail (right) could be an exploded view of a high-level architecture diagram (left)

Why is this important? We have already seen, according to Shneiderman’s mantra, that it is useful for tools to first provide a collapsed overview of configurations and later allowing users to drill down or expand to the details. Architectural drawings at the business, application or tech­no­logy levels provide an excellent set of principles for depicting a collapsed, high-level view. One might even imagine a three-level hier­archy: a top, business layer; a middle physical e­le­ment layer and a detailed physical e­le­ment layer.

Most service management tools capable of generating con­fig­u­ra­tion visualizations rely on relationships to decide how to collapse and expand details. Often, only the anodyne parent-child re­la­tion­ship is the basis for this feature.

As a result, configuration managers some­times end up having the tail wag the dog. They create artificial or incomplete relationships in a CMDB just to enable the tool to draw a certain diagram. In the worst case, the distinction between a “service” and an “application” is lost.

Relationship too complex to diagnose via visualizations

Suppose you wish to use a con­fig­u­ra­tion visualization to help diagnose an incident or problem detected on a certain com­po­nent. Given the pres­sure, especially in the case of an incident, such an approach would be practical only in trivial cases. Suppose the component being in­ves­ti­gated had only a handful of first and second de­gree re­la­tion­ships with other com­po­nents. In this trivial case, a con­fig­u­ra­tion visualization is not likely to be useful. But cases with so few relationships are rare, even in simple infrastructures. Or, it might be true if only a tiny fraction of the relations were documented.

Otherwise, the tediousness of clicking on connected com­po­nents and checking their status  would far outweigh the possible benefits. In short, which approach to diagnosis would be better: using an ap­pli­ca­tion that simply delivers an answer or the trial-and-error use of a visualization?

A rule of thumb for graphs is to limit the number of links to four times the number of nodes. Too many links result in occlusion of elements or the inability to discriminate elements (see Fig. 25). Alas, modern technology brings us well beyond that rule of thumb. Servers contain many more than four managed components. Data switches are typically linked to 16 or even 32 nodes. Racks might contain 40 1U computers. This high link density is not a problem when dril­ling down to a single node and its connections. But, at the overview level, such a high density makes visualizations difficult to draw and harder to use.

a graph of the saa graph with a very high link to node ratiome data with the multilevel scalable force-directed placement (sfdp) algorithm applied
Fig. 25: The structure of the network is not visible when the number of nodes and links is too high
a graph of the same data with the multilevel scalable force-directed placement (sfdp) algorithm applied
Fig. 26: Simplifying the graph using a scaling algorithm makes the structure visible

Conclusion

There is no limit to what one might say about con­fig­u­ra­tion visualizations. I have at­tempted to outline here some of the issues I have found in over 30 years of experience in working with con­fig­u­ra­tion management and its visualizations. I hope these remarks will inspire you to reflect on how you visualize con­fig­u­ra­tion data and what you may do to make those visualizations more useful.
Horizontal bar

Creative Commons License The article Visualization of Configurations by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Bibliography

[a]  Johnson, Brian, and Ben Shneiderman. “Tree-maps: A space-filling approach to the visualization of hierarchical information structures.” Visualization, 1991. Visualization’91, Proceedings., IEEE Conference on. IEEE, 1991.

[b]  Shneiderman, Ben. “Tree visualization with tree-maps: 2-d space-filling approach.” ACM Transactions on Graphics 11.1 (1992): 92–99.

[c]  Shneiderman, Ben. “The Eyes Have It: A Task by Data Type Taxonomy for Information Visualizations.” In Proceedings of the IEEE Conference on Visual Languages, pp. 336–343. IEEE Computer Society, 1996

Credits

Unless otherwise indicated here, the diagrams are the work of the author.

Fig. 21: By Charles S. Demarest – Demarest, Charles S. (July 1923). “Telephone Equipment for Long Cable Circuits”. Bell System Technical Journal. Vol. 2 no. 3. New York: American Telephone and Telegraph Company. p. 138. Public Domain, https://commons.wikimedia.org/w/index.php?curid=84764475

Fig. 25: AT&T Labs, Visual Information Group. Downloaded from http://yifanhu.net/GALLERY/GRAPHS/GIF_SMALL/HB@gemat11.html

Fig. 26: AT&T Labs, Visual Information Group. Downloaded from http://yifanhu.net/GALLERY/GRAPHS/GIF_SMALL/HB@gemat11.html

Summary
Visualization of configurations
Article Name
Visualization of configurations
Description
In this article, I will delve into some of the issues associated with vi­su­a­liz­ing the con­fig­u­ra­tions of systems.As with many other dis­ci­plines in ser­vice ma­nage­ment, the use of vi­­s­u­a­l­i­­za­­tions in con­fig­u­ra­tion ma­nage­ment can be prob­lem­atic. I hope to highlight some of these issues with a view toward: improving the func­tionality soft­ware de­ve­lop­ers build into configuration ma­nage­ment; and expand­ing how con­sumers of con­fig­u­ra­tion in­for­ma­tion make use of vi­­su­­a­l­i­­za­­tions.
Author
Publisher Name
Concentric Circle Consulting
Publisher Logo

Subscribe to our mailing list

Click here to be the first to learn of our events and publications

Reader Interactions

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.