Unified Monitoring


  • Persona development of general AppDynamics users
  • Collaboration with lead architect to define design deliverables
  • Data visualization concept creation to achieve product goals
  • High fidelity prototyping


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.

Initial info dump session with platform architects: end-user device to application correlation.

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:

  • General ITOPs Admin
    Concerned about the overall big picture; would like to see broad impact across layers. Plays the delegate when solving problems.
  • US Regional Infrastructure Admin
    Concerned only about the infrastructure performance in her region (US). Would like to see how infrastructure performance issues affect upstream applications.
  • Service Owner
    Concerned across the entire stack but only for a one service. As long as their service stack is running well, they don't care about anything else.


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).

Initial exploratory attempts

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.

Layered cross-stack overview

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.

Using opacity to denote relationships between layers reduces complexity.

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.

Drag-and-drop concept for rearranging layers. In this case the APP and EUM layers have been switched.

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.

Variation in grouping for the EUM layer by device type.
Each layer in this diagram is zoomed into a specific subcategory.

Lastly, to help all users pinpoint errors and alerts faster, we adopted the path highlighting from our usual flow maps.

Selecting an 'Unhealthy KPI' will highlight the path in question.

Conclusion & Next Steps

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!

Let's Talk 📨