Building APM Requirements And A Business Case

Last week, we looked at laying the foundation for an APM solution, but now it's time to get to work. We introduced Jim - a veteran IT manager who lacks any APM solution. As we discussed, he needs to establish key performance indicators around a critical application, including performance metrics and SLAs. His billing system also has a service catalog and detailed security and reporting modules built into the system. As a Web-based application, the backend database is distributed and the application serves just under 2,000 users. As Jim lacks application fault or performance monitoring, he really is starting from scratch. So we are going to start with creating a document Jim can use for his requirements and build his business case. 

Jim's first inclination was to search the Internet and analysts like Gartner for potential APM vendor products that might fit in his environment. After some discussion, we encouraged Jim to first build a business case that includes his requirements. Even though time is short, and Jim is under pressure to deploy a solution, to effectively evaluate the APM vendors he needs to understand what specific technical and business requirements he has. Otherwise, even the seasoned IT manager may get lost in a sea of marketing.

We worked with Jim to develop a template that breaks down columns for stakeholders, a description of the APM requirement, its priority, and the source of the requirement -if it came from a document or a person, including granular details citing the date and pages when appropriate. We helped break these requirements down into three technical categories: data collection, data aggregation/analysis and data presentation. Each of these areas were critical to understand the complete APM offering.

Jim wanted to identify the cause of the performance slowdown, not just that a problem exists. Data collection requires a detailed understanding of the application architecture in place, which means agent-based or synthetic transaction monitoring. The source of key metrics and data collection intervals were important considerations. Jim already had some network infrastructure monitoring tools, so he needed to consider how to integrate that information into the APM tool.

Most important to the CIO, the data presentation must include a way to quickly see the performance of the app and include out-of-the-box reports around the performance from the user perspective. While many APM tools have good dashboards, we shared with Jim that he might need another tool specifically for a dashboard, depending on the complexity of the visualization that links business data. The impact of a performance issue with a specific customer may require a dashboard with some intelligence.Beyond technical requirements, we had a fourth section in the requirements document that dealt with training, online documentation, and support levels that will be required from the vendor Jim selects. We also took some time here to speak with Jim about the process needed to ensure the performance monitoring adapted to the changes that will occur with the application. Planned downtime was an example of this, as the tool needed to adapt to the company's planned weekly maintenance window, and exclude performance data from that timeframe.

With the requirements complete, Jim now had to justify how much he could spend on the APM tool. His budget was tight and while this was a mandate from the CIO, he still needed to present a business case to the CFO. Jim was really concerned that his budget would not match his requirements. Building the business case for APM around revenue generating tools like an online ordering application is a bit easier than a billing application, because with online ordering it may be a bit easier to calculate revenue impact.

This is why Jim never had an APM tool in the past.  He knew there was value in APM, but it was hard to quantify. Jim did his best creating the business case and with the CIO, went to present to the CFO. If approved, Jim can then move to the next step of evaluating vendors. We'll tell you how it goes next week.