AppDynamics started as an application monitoring solution for Java. In a few short years, the product team not only built monitoring solutions for other languages, but for other layers of of the tech stack as well. However, despite becoming the one-stop shop for all monitoring needs, each technology was heavily siloed with dedicated screens under different tabs.
Users were becoming increasingly frustrated with wasting time flipping through multiple screens in order to find the root cause of an issue. A single problem in one layer of the stack can propagate errors through other layers. If we're collecting all the data, shouldn't we be able to see how those errors are correlated?
How might we graphically tie related entities across the end-user, application, and infrastructure layers?
Even if all technical challenges could be solved, trying to visualize these relationships presents their own set of headaches. Between the three main layers of our monitoring stack, there are multiple levels of one-to-many and many-to-many relationships in addition to various ways of categorize groupings within each layer. Topologies between layers simply don't have clean relationships. We also had to take into account that different users would want different layers to be the main lens of focus. Not everything should be forced into a visualization from 'top' (end-user) to 'bottom' (infrastructure).
Since I was dealing with pretty technical concepts, I first met with our platform architects to better understand the layout for each layer and the relationships that are formed between all of them.
After establishing a foundation for the base concepts, we were able to examine our personas to determine what relationships were important to each type of user:
The initial concepts attempted to juxtapose disparate types of entities by either using direct connectors and nested diagrams (top) or by using textual inferences (bottom).
Unfortunately the displays turned out to either be too cluttered or too sparse, one offering too much detail and the other offering not enough. After gathering feedback we went back to the drawing board and decided that stacked diagrams were the most logical and easily parsed method for visualizing technology layers.
Instead of drawing every request out, it was more efficient to aggregate all requests from a single grouping and denote volume through the thickness of the connector.
One of the most challenging decisions for this project was axing connectors to the infrastructure layer. It was simply far too complex for an at-a-glance overview to depict relationships to the infrastructure layer using lines. Instead, related entities would be denoted via opacity during a mouse roll-over.
With the layer cake approach, this also allows the use to determine what the top level lens of focus should be. As an application owner, I might prefer to have the application layer at the top.
In order to account for flexibility in our personas, we proposed two main concepts. One was presenting different grouping paradigms for each layer, and the other was introducing the concept of zoomability. With these tools, all three of our personas would be able to create a view specific to their needs.
Lastly, to help all users pinpoint errors and alerts faster, we adopted the path highlighting from our usual flow maps.
By offering a novel visualization to the unique data set that AppDynamics posses, we have enabled users to be more effective at solving their issues at hand. Through simplifying relationships between each layer and building in flexibility for different views, we allow users to only view information they need at the level of granularity that they want.
Granted more time on this project I would continue to work with customers to refine the specific use cases that are important to them and further develop these designs at a more micro interaction level.
Fun fact: This visualization is patented!