DX Application Performance Management

 View Only

High Noon for Current APM, 1: What’s wrong with this picture?

By Legacy User posted Jan 04, 2016 05:32 AM

  

Our current thinking must change: from buyers to users to truly help customers.

 

When I meet with our APM customers, I often discover that they have very few people responsible for APM Tools: a small core, two or three people. Sometimes even just one. So, APM teams are quite small and exclusive. And they are busy, often even overloaded by participating in close to every issue to the point where they are unable to deliver enough value. Value that will actually progress and advance the business. A somewhat paradoxical situation that must be addressed by actually protecting these APM experts from a substantial part of their reactive burden.

 

Our thinking on this started a few years back when we realized that, increasingly, we were finding ourselves trapped by requirements driven development. Receiving about three requirements every business day meant it became progressively more difficult to keep up with customer expectations on the one hand, and juggling rapidly accumulating issues to maintain consistency and direction for development of CA APM, on the other. In other words: With our ambition to deliver truly visionary APM, requirements driven development was dead.

 

So, we decided that we had to change our development paradigm radically towards research led development to regain control of consistency and direction for CA APM as well as seizing the opportunity to develop an ambitious new vision for APM. From customer feedback, we understood that we had to develop a vision for APM that should democratize it: making it significantly easier to use for the APM core as well as for all APM users and making it useable by a larger audience.

 

This led to the extensive ethnographic research designed to acquire the necessary deep understanding of users real, daily APM requirements for our new vision for APM, including workflow, information, visualisation, actions, navigation, guidance, focus, context, collaboration, processes, procedures, complexity, knowledge, and skills. Carefully documented in detailed persona use cases.

 

One of the important lessons we learned was actually strikingly simple when you start reflecting. Let me present this as a question. What is wrong with this picture?

 

What is wrong with this picture.png

   [1]

 

For the non-expert this display is not helpful: Because it is not focused on what is relevant; it is not guiding as to what the problem is; nor is it readily actionable: what action can or should be taken? In other words: Knowledge and skill is required to digest the sheer quantity of data presented to make a functional decision as to which action to take. This display is nothing more than descriptive: It is displaying data and not visualizing information since contextual help is completely absent.

 

After completing our research, we started talking about durable APM problems: Problems that are hard to solve because they require tenacious effort and commitment over an extended period of time – spanning several releases. And addressing descriptiveness was one of the very first durable problems we understood we had to tackle.

 

Too often the complexity of the application infrastructure is being reflected in the metrics presentation: displaying inundated amounts of data in the user interface. Instead, the user interface should be designed to be prescriptive: flexible and dynamic focus on relevant context and detail, intuitive in guiding the user to understand the most significant problem(s), and actionable: what actions can be taken or even suggesting a recommended action.

 

Obviously, a very significant move from descriptive to prescriptive user interface design is not something we can achieve with a single release. This is why we started talking of a paradigm for durable problems: we actually can resolve durable problems within our new paradigm of research led development. As you’re starting to see in CA APM V10.

 

This is the first entry of several, in a series about our APM journey. Please join me next week to “Meet the personas”.

 


[1] The screen shot is an application map depicting an application components (vertexes) and call paths (lines) for transactions meant to provide a helpful and intuitive visual map of the application’s landscape. If, to you, the impression is that the map is too overwhelming with too much detail and too little help you’ve got the point.

0 comments
0 views

Permalink