Our current thinking must change: from buyers to users to truly help customers.
In my previous entry, I discussed that when we shifted to research led development, we seized the opportunity to develop an ambitious new vision for APM.
As we, in our APM team, are keenly aware that our customers have different APM maturity[1] ambitions, a core part of our new vision is the motivation to help customers at all maturity levels become more active, efficient, and effective with APM. Hence, our determination is to enable customers to grow their monitoring maturity without increasing APM investment or resources.
So, to be very explicit, we are deliberately not suggesting nor even implying any requirement to increase APM investment and resources, since we understand our customers’ position as well as the agility, speed and cost dynamics of the application economy and the inherent need to make all APM users smarter and more capable.
Customers at the reactive maturity level have the core personas of Kyle, the APM specialist, and Andrew, one of a team of application developers or architects. At the reactive improvement level you would additionally have Pete, the level 1 support analyst, and Ryan, the production support analyst. And additionally, perhaps, a middle-ware or database specialist, Eric. At the continuous improvement level you might have performance test and production performance engineers Marcus and Jeevan.
Hence we have these seven core personas of whom only one is an APM specialist. But indeed all are (potential) APM users who would benefit from becoming active APM users.
We are strongly convinced that our vision potentially forecasts a tremendous gain to be harvested by our customers, in making all these personas significantly more active, efficient and effective in their use of APM. Value, in terms of value realized, from APM investment and, indeed, in terms of resources freed to progress and advance their business. This is what we mean when we say we intend to democratize APM and why it is so valuable – to your own business.
Thus, for example, enabling Pete, our level 1 support analyst, to carry out more of the problem diagnosis and to go deeper into the root cause of problems Pete would be significantly smarter: more pre-emptive, valuable and trusted in proactive problem triage as well as analysis.
With this in mind, we qualified these key challenges, durable problems:
- Complexity – it takes too much time for users to develop the skills required for tool proficiency
We must stop mirroring the complexity of the monitored infrastructure in the monitoring display.
- Data – users are inundated with the volume of data being displayed.
We must significantly reduce the quantity of metric data simply being shown, however colourful or high-resolution our display is. Masses of data, per se, helps nobody in their problem diagnosis and analysis.
- Knowledge – is held by a few select users
We must recognize, that we should capture knowledge and make it readily accessible throughout the community of APM users at large.
- Sharing – is, currently, an arduous process, spanning tools rather than being readily supported by the APM tool
To be collaborative APM must integrate and simplify collaboration across functions (within IT) as well as across the company thus bridging current collaboration gaps.
From this, we could directly coin “E.P.I.C. APM” as our new design model:
A truly prescriptive design should dramatically reduce complexity and hence skill requirements and vastly reduce the learning curve.
By providing a prescriptive interface supporting context and focus (on what is currently relevant) the tool should visualize information in a guiding and readily actionable manner, enabling the user to be proactive.
Intelligence should be woven into the tool in a prescriptive manner: to support context, focus, as well as guiding in triage and analysis.
Collaboration must be as easy and as straightforward as a single mouse-click, and foster learning and the accumulation of knowledge.
For these reasons we find “E.P.I.C. APM” to be “The Better Model for APM”.
Join me next week for a discussion on “Chaos – Order – Context”.
[1] One common maturity model would include these levels: Reactive (reacting on and resolving problems as they occur), Reactive Improvement (reactively improving application monitoring based on occurred problems), and Continuous Improvement (proactively and continuously improving application monitoring).