I love the challenge of visualizing new types of data in new ways because being able to convey meaning succinctly is a brilliant challenge. Last week I worked with a data set from an Avaya Call Manager. Looking at call data is interesting but looking at it in reference to a VOIP system that has network and hardware dependencies presents itself as a common challenge when you distill the data down to its common parts. The common parts of that system are; performance data, network, hardware, and application dependencies. These are the essential categories of how most systems work in an IT environment. One can quarrel over how to categorize parts of a system or that there are five parts and not four, but that’s not the point of this blog, which is to identify how to visualize it.
There are several approaches on how to visualize the whole while also observing the essential value of the components that make up the system. Two of my favorites are network topology drawings and process flow diagrams. Each style of visualization looks at things based on the pieces of the system and represents each with perspective to either physical/logical topology or where it belongs in a process flow. This isn't a bad start, but what it doesn't convey for example is performance data for how the system works, and in the network diagram it doesn't even represent a system necessarily. A process flow might include more than one system aka application in its process flow for data as it flows from one end of the process to another, but what typically escapes the diagram are the key performance indicators for the application’s inside that process. What this points out is that there is data within the system that any given mode of visualization may naturally suppress without intending to suppress it. This can be very challenging to overcome and is one of the reasons why I like to return to basics and identify what the components of a system are, and what the key performance metrics for each piece of that system might be, assuming we are measuring all the KPIs in each system. In fact it’s entirely possible to derive a meaningful KPI from a conversation like this that can bear meaning to a process or system. Take for instance a financial institution that monitors trades. It’s logical that one of their KPIs would be the number of transactions over a time period. Where this begins to get more interesting is as the transaction is followed from system to system what each system’s KPIs are and then how each of those KPIs impact the transaction KPI and viola a new KPI of transaction KPI/system KPI has been derived by exploring a logical dependency. Now, how do you visualize it on the process flow for example?
Visualization is always a data driven exercise, but this one is typical. A KPI needs to be placed on a process flow in relation to a system comprised of a number of servers in the process flow. Lets just say, for the sake of being concrete, that this KPI is system capacity and its represented in percentage where 100 means it is at capacity. This metric could go in the process flow diagram in and be placed in proximity to the system it represents. Logically it could be given a color based on some thresholds as well, but the essential design could be a colored circle with a number in it.
Figure 1- Simple Process Flow Diagram with Multiple KPI's
For visualizing the VOIP system I played with last week I like the topology view better than a process flow. It lends itself to conveying physical dependencies that are paramount when troubleshooting which part of the network the VOIP or call quality stunk at, right? The fact that a call is the data that flows through this system is consistent between the two visualization paradigms. So similar to the financial process flow diagram we want to count the number of calls the
VOIP system handles on a daily basis. What we want to represent on this diagram as well is the number of calls handled by use case; which ones were internal calls, external calls inbound, internal sourced calls that where outbound, voice-mail, pages, etc. These types of calls can all be characterized and counted and represented in a legend on this diagram. Each part of this system however will impact calls differently because internal calls don’t require an external router or switch, because they only traverse over the internal switches and trunks for example. This presents a challenge of how to derive a meaningful visual dependency between parts of the system and how each impacts a different use case call.
Instead of a legend the Internal Call Count per day or hour could be placed near the internal switch and labeled ‘internal calls’. The physical pieces of the system could also be grouped and then placed in a rectangle or shape that signifies it’s the internal system and the internal call KPI could be placed in visual proximity to this logical group.
Figure 2- Simplified Avaya CM Topology with Metrics
These are just a few ideas that can help to convey small pieces of information on a topology that includes the monitored conditions of those pieces the system is dependent on, which can yield greater understanding to a wider audience and not just an IT audience. Good luck with your data visualization and let me know if you have a unique challenge visualizing data in your environment! I’m always up to a challenge.