In my last blog, I shared the general concept of Application Performance Monitoring (APM) and why it should matter to IT professionals. In this blog, I want to get more specific about what is required for an IT organization to shift from a silo'd infrastructure centric monitoring perspective to an APM centric perspective. The challenges are both technical and organizational. At the end of the day, the end goal of all of this is not just to declare successful “APM adoption”, but rather to obtain the following very tangible and quantifiable benefits:
- Rapidly identify when there is a problem that is now or will soon impact the business, and quantify that impact.
- Radically reduce the time spent and the number of IT staff involved in bridge calls and in war rooms for incident management activities by simplifying the challenge to pinpoint the location of a problem in both simple and complex application architectures (multi-tier, multi-platform, virtualized, cloud, clustered) found in modern IT ecosystems.
- Measure IT service in a way that aligns with the business.
As APM continues to evolve, various vendors and analysts promote similar technical visions of the space. These visions are all loosely aligned with the end-goals established above, but vary in their implementation and focus. Generally speaking the key functions of APM include:
End-user/transactional monitoring: The end-user/transactional perspective is what enables IT to align well with the business. This is really where the rubber meets the road. If transactions are not executing as expected, then IT needs to pay attention before IT Helpdesk or Customer Service Desk phones start ringing. Historically, most IT organizations minimally employ some form of synthetic transactions via on-premise or external synthetic services. More recently, a next generation of monitoring technologies have emerged to capture real user experience and identify aggregate and individual user issues, and isolate the root of the problems to either IT or somewhere outside IT on the network path into the infrastructure or on the client.
Discovery and modeling of the technology stack: While end-user/transactional monitoring tells you that there is or is not a problem that needs to be addressed, understanding how an infrastructure/application components are interconnected is what gives IT operations context for addressing problems. This information also provides the foundation for war-room analyses.
Monitoring elements in the stack: Once the transactions and application stack are understood, it is necessary to gain visibility into the health of the elements in the stack. Importantly, the depth of data that you choose to gather in each domain can significantly affect the level of difficultly to implement, and the depth of analysis that is possible. For example, high-level monitoring that focuses on the general health/availability of a given element—will facilitate basic triage use cases, but will not typically provide the information needed for complex root cause analysis. A good adage to adopt here is “walk before you run”.
A way to analyze/visualize the data across the stack: Ultimately, the reason that you collect all of the data from a single solution is to enable visibility of current and historical data in a single unified vision. This is what enables IT staff to rapidly locate the source of technology issues and avoid or facilitate war room situations. This also facilitates the more proactive analytics of problem management to get in front of issues before they impact the business.
Transactional paths through the technology stack: Understanding how specific transaction types or instances of transactions flow through the technology stack helps solve the hardest APM problems—the cases where most transactions are fine, but a specific or a subset of transactions behave abnormally. Take care here, as from one vendor to the next you may hear radically different definitions of what a “transaction” is, ranging from a single hit on a web page to a complex sequence of asynchronous interactions with a set of web applications. Again, the key here is to take a practical approach, start simple and evolve.
The breadth of APM can be frightening, but it doesn’t have to be. It is not necessary to implement the full breadth to gain value. Rather, by analyzing the current situation in your organization, there are a handful of simple “on-ramps” to APM that can provide immediate value AND serve as stepping stones towards comprehensive APM adoption. Interestingly, the other large (and sometimes even more challenging) factor beyond the technical aspects of APM adoption is your IT organizational structure and associated operational processes. More on that next time…