As some of you know by now, my colleague Jonah Kowall (@jkowall) has announced that he is leaving Gartner for an opportunity in the vendor community. When this was announced internally, I was approached by my team manager to see if I might be interested in taking Jonah’s place in covering APM as I used to cover an early version of this area years before and so I was a logical candidate.
My first thought was that Jonah would be a hard act to follow as he’s done an exemplary job of covering the topic and thus there were big shoes to fill. My second thought was that I was really enjoying working with companies in transforming to a DevOps and Web-scale IT culture and wasn’t sure if covering APM would allow me to have the same impact. After a few days of thinking it over, I decided to “volunteer” to co-cover APM with my colleague Will Cappelli (who supports APM in EMEA and is also focused on IT Operations Analytics or ITOA).
So, it’s reasonable to ask what made me decide to say yes (to an offer that I could in fact refuse – Gartner is great about that). To be honest, as I surveyed the market, I didn’t feel like I was that out of touch and I thought that I could step in fairly quickly and begin to assist our clients (note: I hope this is not a case of too much hubris). Sure, when I used to cover the precursor to APM (I developed the first Magic Quadrant for J2EE Application Server Management in 2003), the lapels on our suits were broader, but when I was reviewing the industry to help influence my decision, I didn’t feel like that scene in the movie Somewhere in Time where Christopher Reeve shows up in clothes that were decidedly out of date for the era.
In other words, the technologies while more advanced did not seem at least to me to be a quantum leap beyond what was available a decade or more ago. Prettier faces or UIs for sure … and some improved install mechanisms, but with the possible exception of the use of more insightful analytics, nothing screamed radically new (and from my perspective, SaaS is largely about improving the delivery mechanism, not the functionality – at least in many of today’s offerings). And that’s a problem I think. With that as a basis, I’d to share with you some additional thoughts that I have on APM:
Situation awareness – I think a criticism of the analyst community (that I have been guilty of myself) is that we are often held captive by the shiny object syndrome. We’re geeks – it’s probably why most of us are in this industry, but, we need to look beyond the technology “porn.” More specifically, while the technologies are in some cases getting better, you can make I think a claim that our overall situation awareness may not be. And this goes beyond not just applying analytics to deal with the digital tsunami but also how to better understand how we process information (cognition) as well as looking at ways to improve usability through improvements in visualization, workplace design, etc. In my research, I hope to go outside the IT domain to see how operators in other mission critical areas are improving their sensemaking to help them in their day to day activities.
Work roles and processes – One of the reasons that I gravitated to covering DevOps in 2010 here at Gartner was because I didn’t see our clients getting any better using frameworks like ITIL. Process complexity seemed to be increasing (and not decreasing as I thought it should because we were certainly getting better with all of the money we were throwing at it – weren’t we), and this approach was becoming a cash cow for consultants. So, with this in mind, I want to ask how is APM improving the monitoring “process?” As a consequence of our investments, what are we no longer having to do? Related to this is the question of how is APM improving systems administration, operations and development collaboration? There is, I think, a lot of work that can be done better understanding the ethnography of the individuals charged with the monitoring and management of our IT environments.
Parochialism – I’m not sure that this is the correct word, but what I’m suggesting is that it seems that we in the IT operations world are guilty of the “if the only tool that you have is a hammer, to treat everything as if it were a nail” perspective. In other words, we often seem to say that the only way to fix an application problem is to buy more APM tools. We don’t seem to reflect much on how changes in the application architecture can result in a (potentially) reduced need for lots of expensive add-on management technology – at least in the long run. In the DevOps world, feedback loops are critical and we need to do a better job of suggesting how to improve the application from the metrics that we are collecting. In essence, we need to become better systems thinkers as philosophies such as DevOps are recommending.
Billions and billions – Astronomer Carl Sagan liked to use big numbers when talking about the cosmos to put its size in context. Closer to home, there are seemingly near equally big numbers when it comes to things like microservices, mobile applications, sensors (IoT) and so on. How can we possibly manage these using management architectures that are not that far removed from their traditional client/server ancestors? Perhaps a better question is do we need to manage them – or will more and more intelligence have to be built in to have a hope of being able to manage exponentially larger numbers of things (including applications) than we have to date so far?
These are just a few of the things that I’d like at least some of my future APM research to focus on. Of course, there will be lots of continuing detail on the APM technology providers themselves in upcoming Gartner deliverables. In the meantime, let me know if you think I’m missing something and best wishes to Jonah on his new journey!
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.