The Good: Emphasis on the process gap and organization maturity as the real barriers to APM success. It includes small vignettes of IT life at the start of each chapter, to highlight to IT situation and challenges. They even define the "M" of APM as Management, not Monitoring. They avoid the word "Dashboards" in favor of visualizations (cool: brings reports back to the table) and mention "application lifecycle" a few times, like "APM optimizes the application lifecycle". And, my favorite: "measuring performance is a proxy for understanding business performance".
The Bad: It purports to "take you through an entire implementation" but doesn't offer any depth. It is more of an extended whitepaper. It does cover the lifecycle of the motivation, decisions and implementation of an APM solution but as a conversation of what could be done. They only acknowledge stakeholders as SysAdmins, Developers and End-users (the guy using the browser)
The revelation for me was that they dredged up a Gartner Maturity Model from 2003 that had some interesting contrasts with the model we derived from our internal analysis of implementation failures and successes. Gartner identified management maturity as "Chaotic, Reactive, Proactive, Service and Value". Our model allowed for "Reactive, Directed, Proactive, Service-Driven and Value-Driven", with Reactive further divided as Reactive-Negotiated and Reactive-Alerting. I don't get too much access to Gartner stuff but here is how I represented Management Maturity:
This is from the first ICMM positioning around 2005. I don't recall why I decreased the size of each box, from left to right. I think I was trying to emphasize efficiency or proportion of IT organizations that might be found practicing at that level."Directed" is using APM metrics to influence the application lifecycle, focusing on QA practices.
"Service-driven" - everybody has this goal, we only tried to put teeth into it by associating it the definition of best practices.
I really liked this slide but it is not the emphasis we have today. We focus more on "visibility" because it provides a more "joining" context among the various tools that are available and their contributions, rather a focus on a particular technology and excluding all others. We also highlight the impact that visibility has on the existing processes in an organization and how this helps us assess their maturity and make meaningful recommendations for remediation.
Management Maturity and the processes that go along with it are the foundation of the Compuware APM message. That's not so bad. But then they fall into some unusal partitioning of APM in order to highlight their transaction monitoring technology. So I conclude that while they are saying the right things they regrettably recast APM as something that their technology delivers - and you only need to look at transactions.
Process re-engineering is actually pretty difficult and for well-established and reasonably successful, Reactive-Management organizations, this message is just way too hollow. These prospects know a lot about processes and may even know where they have gaps. What they need instead is a plan to help them evolve the organization, consistent with APM. What can they do now, and tomorrow, (and without purchasing new technology) that will get them on track to APM? What will derail their efforts? How will they know they have improved the situation? When will investment help accelerate their drive to APM?
No comments:
Post a Comment