Application Performance Management’s (APM’s) time is only beginning.
That’s certainly not the impression several headlines have given over the last quarter. Judge by them, and you’ll conclude APM is nearer its death.
What’s really happening is simply that APM is growing up. As 2012 closes, we’re finally in a position to evaluate how APM can make the biggest contribution, and where its approach needs a bit of refinment.
Much of what has happened over the last couple of years of APM deployment and speculation is simply that we’ve learned APM’s strengths and weaknesses, how to make the most of the former, and where a different approach is the best solution for the latter. Look, for example, at Tom Batchelor’s article, “APM is Dead: Long Live APM!”. It’s a response to the same article by Art Wittman, “What’s Killing APM“, that “Application Monitor” covered earlier under the title, “No time to give up on APM“. Batchelor summarizes that “… the APM market is growing and healthy but there is great dissatisfaction with some of the tools … legacy APM solutions … are terminally ill.”
Batchelor is on-target: there’s plenty of demand for what APM advertises, or, in his words, we have “a fundamental need for these tools …” The most prominent products to this point, though, “… require configuration at each component … [with] high costs and long implementation cycles … [and] a large human overhead to maintain.”
The idea of APM is right; it’s simply past time for vendors to “… focus … on deployment efficiency …”, and for customers to demand a good out-of-the-box experience. That’s a major element of the message for today: it’s not just that APM’s role will continue to need to be filled, but that you have an opportunity to choose the right APM by insisting on a product with good usability and ease of maintenance.
That’s not all that today’s APM should provide. Raul Cristian Aguirre writes even more trenchantly than Wittman about “The Problem with APM“. For Aguirre, the problem is that APM doesn’t go far enough: what truly matters is not the application but the business service. Aguirre recommends Business Service Management (BSM) projects.
BSM is attractive philosophically. Maybe it’ll be the right advice–some day. For now, though, it looks to me too much like a “spherical cow”: an assumption that simplifies planning. I don’t know how to implement BSM in practical circumstances. APM, though, I can buy, configure, update, and adjust now. APM is the right engineering base for process improvement now, even if lacks BSM’s ontologic purity.
Part of that engineering base is matching APM to your own circumstance. I already emphasized the importance of the out-of-the-box experience. Another dimension of APM design and application is what Amir Gabrieli introduces through the question “What Does Operations-Centric vs Developer-Centric APM Mean to You?” This Dev-vs-Ops contrast is a bit like the APM-vs-BSM opposition Aguirre describes, because there’s no question “Developer-Centric APM” has the deeper history and wider customer base. In this case, though, “Operations-Centric” is undeniably practical, because there are already successful ops-centered APM projects. It’s a more realistic engineering choice than BSM.
“Application Monitor” will continue through the next month to explore the characteristics of APM projects that make for success. Until then, focus on whether your own needs are more dev- or ops-centered, and whether the APM you’re considering is easily configurable for the operations typical in your business. It’s no longer enough to pick the market-leading APM; now it’s time to match it with your own situation.