An Introduction to Service-Level Agreements (SLAs)

Source:www.cio.com Date:2007-8-9 Font Size:

SLAs are a critical component of any vendor contract. Beyond listing expectations of service
type and quality, an SLA provides remedies when requirements aren't met.
By Lauren Gibbons Paul
A service-level agreement (SLA) is nothing more than a type of contract between two parties. In the
context of managed IT services (in which SLAs most frequently appear), SLAs dictate the quality and
type of service that will be provided to the client in exchange for a fee. SLAs also provide the remedy,
such as a reduced fee structure, that will apply in the case of a service outage.
So, for example, if the contract specifies 99.9999 percent uptime and that is not met, the customer
would have the right to reduce its bill by an agreed-on percentage. SLAs are important because they
set the tone for the relationship between the parties and will govern if and when things break down. A
"good" SLA is a balance between being thorough and clear on one side, while not being overly onerous
on the service provider on the other.
Table of Contents

What is an SLA?
Why is it important to have an SLA?

Which side should prepare the SLA?

What are the basic components of an SLA?

What about indemnification?

Are SLAs transferable to a third-party provider?

How can I be sure the service provider is meeting the service levels set out in the SLA?

What is SLA monitoring and verification?

What are some SLA metrics?

What should I consider when selecting metrics for my SLA?

What are the typical uptime provisions for an IT network services provider?

Should we review our SLAs periodically?

What is an SLA?
A service-level agreement (SLA) is a document that spells out two or more parties' rights and
obligations under a contract for work (such as between a company and its service provider). The main
purpose of an SLA is to spell out the level of service that will be provided under the agreement. An
internal IT services organization may also provide an SLA to its internal business "customers."
The classic example of an SLA is with a network services provider or telecom provider, where the
document dictates what penalties the provider will incur if its performance falls short of specified levels.
Usually, in this case, the penalties will follow a stepped schedule - for example, "If the network is down
for an hour, the customer is entitled to a 10 percent rebate of its monthly network service fees; if the

network is down for two hours, the customer is entitled to a 20% rebate of its monthly network service
fees" and so on.
Why is it important to have an SLA?
It is as important to have an SLA as it is to have a contract for business arrangements of all types -because it constitutes a single document that contains the terms of the agreement as understood by
both parties. With the SLA in place, it is much more difficult for either party to claim ignorance if the
agreement breaks down. CIOs should expect to have an SLA (reviewed by their legal counsel) in place
for every significant service relationship they have.
Which side should prepare the SLA?
Most service providers will offer a standard SLA as part of the work agreement. Ideally, you should use
that as a starting point. Give their SLA to your in-house counsel department, if you have one, and let
counsel make adjustments that are favorable to your side. Or add some provisions that reflect your
priorities. If time is of the essence, however, you may have to use the service provider's standard SLA.
What are the basic components of an SLA?
An SLA can comprise a few short pages up to a few hundred pages. The basic components are a
statement of the parties' intent, an outline of the responsibilities of each party (including acceptable
performance parameters with applicable metrics), a statement on the expected duration of the
agreement, a description of the applications and services covered by the agreement, procedures for
monitoring the service levels, a schedule for remediation of outages and associated penalties, and
problem-resolution procedures.
What about indemnification?
The SLA should include a provision in which the service provider agrees to indemnify the customer
company for any breaches of its warranties. Indemnification means that the provider will have to pay
the customer for any third-party litigation costs resulting from its breach of the warranties. If you use a
standard SLA provided by the service provider, it is likely this provision will be absent; ask your in-house
counsel to draft a simple provision to include it, although the service provider may want further
negotiation of this point.
Are SLAs transferable to a third-party provider?
The issue of transferability usually arises when the service provider is acquired by or merged with
another company. If the new entity intends to carry on the acquiree's business as usual, the customer
will have a natural expectation that the acquirer will assume the previous provider's SLAs.
Unfortunately, this may not be the case. SLAs granted by one company do not automatically transfer to
a new owner of that company. If your service provider has merged or been acquired, it is likely you will
need to renegotiate the terms of the SLA. In many cases, however, the new entity will not want to risk
causing ill will with the client base and will therefore assume any existing SLAs.
How can I be sure the service provider is meeting the service levels set out in the SLA?
Most service providers (especially in cases where high availability is critical, such as network services)
make reports available, often on a Web portal. There, you can see how your application or system is
faring, whether service levels have been maintained and whether you are owed any rebates for service
outages. If the service being provided is mission-critical (that is, your business is in jeopardy if the SLAs
are not met), you will want to consider using an SLA management tool or monitoring service.
What is SLA monitoring and verification?
Service providers typically have their own means of ensuring that SLAs are being met. But if the service
is truly critical to your business, you should consider engaging a third-party monitoring company to
monitor your SLAs, ideally in real-time, so you can be sure you are getting what you paid for. It's an
extra layer of hassle and expense but key for that extra peace of mind.
What are some SLA metrics?
Most SLA metrics concern the quality of work to be performed by the service provider. According to Ian
S. Hayes of Clarity Consulting in Beverly, Mass., a quality definition may contain several individual

metrics that may form part of the deliverable's acceptance criteria, or that may serve as standalone
measurements of a single aspect of service.
Examples of quality metrics include:
Defect rates. These are counts or percentages that measure the errors in major deliverables, including
number of production failures per month, number of missed deadlines, number of deliverables rejected
(reworks), and so on.
Technical quality. In the case of outsourced application development, this includes measurements of
the technical quality of application code, normally produced by commercial tools that look at items such
as program size, degree of structure, degree of complexity and coding defects.
Service availability. This indicates the amount of time/window of time that the services managed by
the outsourcer are available, ranging from online application availability to delivery of reports by a
specified time of day. Measures can be reported positively or negatively and usually incorporate some
level of tolerance (for example, online application availability 99 percent of the time between the hours
of 8:00 a.m. EST and 6:00 p.m. EST).
Service satisfaction. This relates to the client's level of satisfaction with the perceived level of service
provided by the outsourcer captured for each major function through internal and/or external surveys.
Ideally, these surveys are conducted periodically by a neutral third party. Although subjective, they are a
good double check on the validity of the other SLA metrics.
What should I consider when selecting metrics for my SLA?
According to Hayes, it is important keep these guidelines in mind:
Choose measurements that motivate the right behavior. The first goal of any metric is to motivate
the appropriate behavior on behalf of the client and the service provider. Each side of the relationship
will attempt to optimize its actions to meet the performance objectives defined by the metrics. First,
focus on the behavior that you want to motivate. Then, test your metrics by putting yourself in the place
of the other side. How would you optimize your performance? Does that optimization support the
originally desired results?
Ensure that metrics reflect factors within the service provider's control. To motivate the right
behavior, SLA metrics have to reflect factors within the outsourcer's control. A typical mistake is to
penalize the service provider for delays caused by the client's lack of performance. For example, if the
client provides change specifications for application code several weeks late, it is unfair and
demotivating to hold the service provider to a prespecified delivery date. Making the SLA two-sided by
measuring the client's performance on mutually dependent actions is a good way to focus on the
intended results.
Choose measurements that are easily collected. Balance the power of a desired metric against its
ease of collection. Ideally, the SLA metrics will be captured automatically, in the background, with
minimal overhead, but this objective may not be possible for all desired metrics. When in doubt,
compromise in favor of easy collection; no one is going to invest the effort to collect metrics manually.
Less is more. Despite the temptation to control as many factors as possible, avoid choosing an
excessive number of metrics or metrics that produce a voluminous amount of data that no one will have
time to analyze.
Set a proper baseline. Defining the right metrics is only half of the battle. To be useful, the metrics
must be set to reasonable, attainable performance levels. Unless strong historical measurement data is
available, be prepared to revisit and readjust the settings at a future date through a predefined process
specified in the SLA.

What are the typical uptime provisions for an IT network services provider?
When it comes to hosted network services, most companies will need at least 99 percent uptime; many
providers will offer 99.9 percent uptime or higher. It is important to understand exactly what this means,
as 99.9 percent uptime equates to 43.2 minutes of unplanned downtime per month. For many
enterprises, that level of availability is not acceptable. It is a common practice for a provider to offer
nearly 100 percent uptime for certain business-critical applications, but you must be prepared to pay for
this guarantee. Many providers offer different levels of uptime guarantees, priced accordingly.
Should we review our SLAs periodically?
In a word, yes. The service-level commitments contained in the SLA are developed from estimates of
current and desired service levels that are subject to fluctuation. Accordingly, the SLA should be viewed
as a dynamic document and should be periodically reviewed and changed when the following events
occur:

The environment has changed

Workloads have changed

Better metrics, measurement tools and processes have evolved.

When it comes to SLAs, it is worth spending the time to get them right. As with any long-term
relationship, it is best to have the expectations communicated as clearly as possible before the
relationship begins. And if things do break down, it helps to have the remedy there in black and white
without the need to renegotiate.

http://www.chnsourcing.com/article/Article/abc/163420070809133104.html
esamultimedia.esa.int/docs/GMES/TF_SLA.pdf
en.wikipedia.org/wiki/Service-level_agreement
pic.dhe.ibm.com/infocenter/tivihelp/v58r1/.../c_types_slas.html