CIO — Everybody’s doing SLAs—service-level agreements. But there’s a lot of confusion about what they are and how to go about doing them. As a result of this confusion, some IT organizations are finding that SLAs do little more than generate a lot of bureaucracy and minimal benefits.
What’s this buzzword really about, and what does it take to do SLAs right?
Two Different Animals
The term SLA is being used to refer to two very different things: metrics and internal contracts.
One meaning is a benchmark of performance that applies to all customers of a given service. For example, an SLA for a given service might promise that it will be up and running 99.999 percent of the time. This is not really an agreement at all. It’s a metric of performance (availability), and a benchmark that defines success on that metric (99.999 percent). Essentially, it’s a dial and the desirable green zone on the dial.
Since it’s not really an agreement, it’s a waste of time (and indeed a nuisance) to ask clients to sign this type of SLA. The IT organization can (and should) establish its own metrics and performance targets without clients’ permission.
A far more interesting definition of SLA is an internal “contract” between a customer and a supplier for a specific deliverable. This is a very different animal. This type of SLA documents a purchase decision, and certainly requires a commitment (be it an actual signature or a figurative one) from both the customer and the supplier.
Let’s examine this type of SLA further....
SLA as an Internal Contract
An SLA represents an agreement to sell a service to a customer (e.g., a client in a business unit) for a period of time (e.g., a year). It clarifies the service (IT’s deliverable), including its level of quality (where performance targets are relevant). And it represents an agreement by the customer to pay for the service, albeit in many cases by allotting a portion of the IT organization’s core budget.
In fact, an SLA is a subset of the broader concept of internal contracts. IT is a business within a business that contracts with clients to “sell” (whether or not money changes hands) both products and services.
The term SLA generally applies only to services, but the broader concept of internal contracts is relevant to both. In practice, all the processes involved apply equally to both. There’s no need to establish one process for service contracts and another separate process for projects (or worse still, a third process for small projects such as repairs). Contracting is contracting; it’s all the same.
