This week I was working with a client, we will call him Jim, who was telling me about their mission critical business application. It's primarily a billing system, but also has service catalog and fairly detailed security and reporting modules built into the system. As a web-based application, the backend database is distributed and the application services just under 2,000 users. The CIO is seeking to establish key performance indicators around the application including performance metrics and SLAs. Unfortunately, there is currently no fault or performance monitoring in place. The current performance of the application is judged based on anecdotal calls to the help desk. Obviously, this will not cut it.
The community of APM vendors grows each week. As the industry finally adopts a service-based approach for IT management, the services really end up being applications at the end of the day. The tidal wave of ITIL process initiatives has been a big catalyst for APM projects as organization try and consolidate their legacy application and system management tools from the past 20 years and provide more proactive metrics around the critical business applications.
When we talk about end-to-end APM, usually vendors will come into environments where network monitoring and perhaps some system level monitoring already occurs. Jim's environment is very different. Discussing business dashboards, integration and real-metrics is a real problem for many organizations but does not resonate with Jim. Like a large percentage of the IT community Jim is still in the dark around application performance. For him, end-to-end APM is an almost unimaginable nirvana which seems out of reach and too complex for their environment. He has survived for years without it, so when the CIO asks him for metrics, he really does not know where to begin.
The bright side of my conversation with Jim is that many of the issues surrounding legacy APM applications will not come into play, the elegance of designing a solution in a Greenfield environment has real potential. The real trick is to select the right type of tool and architecture that can meet Jim's needs, scale as the organization grows, but also not break the bank (which for Jim is not very big). So, how does Jim get started selecting the right APM solution for the environment? Over the next few weeks we'll discuss our approach and provide a roadmap for anyone implementing APM. From building the business case, developing your architecture and selecting the tool and implementation, we will map out the steps required to try and select the right tool for the job.
We also would like to hear about your recommendations and ideas for each of the stages, so feel free to share APM success (and failure) stories with us in the comments.