Lots of IT organizations use an informal metric for measuring how satisfied employees are with application performance: If they aren't calling the help desk, things must be OK. But this is less a strategy than an avoidance tactic. Proactive organizations will work with business units to create internal service-level agreements that define acceptable performance metrics. An SLA provides a formal mechanism for CIOs to report on progress in meeting performance goals--and to demonstrate to business leaders the very valuable services that IT provides.

Of course, if we're going to offer SLAs, we must measure service levels with some kind of quantifiable metric. This is where application performance management comes in. APM tools are a vital source of information about the components that support an application, including software, server hardware, and network systems.

There are three basic steps to formalizing an internal SLA.

First, you need to define the metrics that will be used to calculate meaningful performance to the business; a promise of less than 10% packet loss is meaningless to the national sales manager. Focus on simple, yet telling, metrics such as user response time, the average time for a business unit to order IT services, or other customer-centric measures. Behind the scenes, these metrics will comprise a mix of transaction response times, CPU utilization, I/O responses, and so on.

Second, determine how you'll enable business units to review SLA-related metrics. Will IT create regular reports to send to business leaders, or will information be provided via other means, such as an intranet? If you already have a corporate portal with scorecard metrics, you should be able to disseminate APM data there. If not, you may need to use a third-party management portal or an external reporting tool. In addition, many enterprise APM systems, including those from vendors such as BMC, CA, Compuware, and IBM, can present application service data to management.

Third, the IT group and business units must discuss how violations or potential violations will be reported and agree on consequences if IT fails to meet its agreements. For example, if a user phones the service desk to complain that an application is slow, should this kick off a process to investigate whether an SLA has been violated? Or should IT and business units meet regularly to examine performance numbers?

Behind the scenes, IT organizations that implement internal SLAs have to grapple with new technologies, such as cloud computing and virtualization. When it comes to public cloud services, including applications delivered in a software-as-a-service model, IT can't get complete visibility into the provider's infrastructure, complicating SLA measurement. As for virtualization, you need to ensure that your team can properly monitor and measure virtual environments. If IT can't see performance issues in a virtual machine, it risks violating SLAs.

IT's ultimate objective is top-notch application performance. SLAs and APM systems work in tandem to help achieve this goal.

Download a free PDF of InformationWeek magazine (registration required)