The attendant market frenzy would have you believe that if you haven't inked an SLA (service-level agreement), implemented an SLM (service-level management) strategy or arranged for OLAs (operational-level agreements) right down to the alternate paper tray on every printer, you're a fool.

But despite the market hype and acronym blitz, you're not alone if you're still waiting to take the service management plunge. In fact, if you have widely deployed SLAs, you're in the minority. Service management products can be expensive to deploy and maintain, and securing the necessary capital can be tricky. Some SLA products are based on enterprise systems and network management solutions that can devour an entire IT staff. Others are much simpler and less expensive, but target only a specific aspect of service management.

With the confusion over what constitutes an SLA, how it will be measured, and what it means to IT and its customers, it's clear there's no "one size fits all" solution. But before you can tailor an approach to fit your organization, it pays to familiarize yourself with some key SLA and SLM strategies and components.

Service management is not really a new concept, but it is more difficult than it used to be. The idea dates back to users who insisted that their mainframe systems track availability and response time. Centralized processing and the deterministic service of the SNA protocol made this measurement possible. But in the client/server environment, distributed processing, non-deterministic protocols and disjointed management have complicated service-level tracking.

Despite the complexities of client/server management, you can get a handle on it if you break it down into its basic elements--client, network, server, database and application. Service management encompasses the setting, monitoring, diagnoses and projection of future service levels from each perspective.

To pick an approach, you must start with an understanding of what your company (or your customer) does to make money, and IT's impact on the process. Without an insight into the revenue stream, you'll be clueless about what to measure for an SLA. And though it's easy to find consultants who claim to help with service management, don't call them in too soon; the initial analysis is best done internally, by an IT department that knows the business.

Speaking the Same Language The first area to attack is the disconnect between the IT manager and the business user. It's a rule of thumb in service-level measurement that the more technical the index or matrix, the less it will mean to the business user. Conversely, the more meaningful something is to the user, the harder it is for IT to measure. For example, "it works" makes complete sense to business users as a measurement, but leaves IT itching for quantifications and comparisons.

Conversely, if IT responds to complaints by telling the business user that application disk and memory usage as well as network utilization is at or below previous thresholds, all you'll get is a blank stare. The accuracy of the statement matters little if the data has no meaning for the other party.

Another rule of service-level management states that technical measurements must accurately relate to the business user's experience. For example, the percentage of busy and available ports on a remote-access server will correlate to remote-connection success. Simple technical measurements that are mutually understood work well here. On the other hand, the more technical the measurement, the less likely business users will buy into the SLA. If you have to explain the measurement every time you discuss it, you've chosen the wrong metric.