Application Performance Management Best Practices

Good application performance management requires structure, and like a well built physical structure, application performance management requires good building blocks that fit together well.  The application performance management structure starts with a framework that defines a set of processes that are then delivered using best practices.

Think of the structure in terms of making a great meal.  In a culinary context:
          Framework = Cuisine
          Process = Recipe
          Best Practices = Cooking

On March 10 we described a compendium of management frameworks and concluded that the ITIL is the best of the bunch because it is most comprehensive and describes IT as a service.  The March 17 post described how to find the APM essentials within ITIL.  Then in our March 18 post we described the processes essential to managing the performance of an operational service (incident, availability, capacity and service level).

Today we introduce the next layer--best practices.  Application performance management best practices require you to understand, measure, and communicate about application performance--and to link application performance to the business.

Understand performance by learning about your applications and their requirements, application users and their requirements, and your infrastructure environment.  The most basic understanding comes from watching users doing their jobs--or having fun if that is what you deliver--interacting with an application.  It is also valuable to talk to users about the experience.  We know many technologists who play key roles supplying application services yet never talk to users!  Understanding users and how an application works is a must.

Measure any technical parameter and user behavior as soon as you learn about it.  You can never have too much data.  Yes, you may not use it all--but you will have data to show changes.  Performance management is about incremental improvements.  Measure early small improvements even if they appear modest.  This gives you data to justify bigger changes for larger gains.  The bottom line is you must measure, measure, and then measure some more.

Communicate your findings.  This means showing people your measurements and explaining the performance gains--or losses.  Write your reports so non-geeks can understand them.  You must communicate technical data differently to non-technical audiences than to your tech-savvy peers.  Again, we know many excellent application performance managers who never show their reports to anyone.  Like gnomes, they hoard data for their own use--and only retain it to cover their backsides should a decision backfire.

Link performance to business needs.  Performance reports shared outside of IT should be grounded in "what matters" to the business.  Is management eager to see availability and/or response time numbers?  Not!  What executives want is information like amount of revenue made or lost, number of orders processed, patients treated, users positively or adversely affected, etc.  The business metric you choose must first be important to your business and second must have a business goal.  The link is how well the application's performance supported the business goal.