> Cover Story
the Service Level Agreement
SLA requires an analytical approach with a logical workflow
to break down components that can easily be apportioned
time back, I had a personal experience where a telecommunications
provider failed miserably at accounting for their failure.
Those were the days when SLAs were unheard of.
As the story goes, one month, we received a bill stating
that our 64 Kbps ISDN line had been used for 24 hours continuously
for an entire month. We knew this was impossible as the
only service we had running full-time was an ETRN mail server,
which polls the telco's mail exchange (MX) periodically
and does not run full-time.
We went through loops to dispute the total amount, but fearing
being disconnected, we paid the full fee, and took the issue
with their billing department. After a long tussle, they
promised a refund of around US$2300 which never came. We
painfully wrote off that payment, and took our business
However, the growing number of service providers has created
more choice and driven the need for more accountable service
Do You Need One?
An SLA is binding contract which specifies the provisioning
of performance and service quality parameters between two
legal entities (the service provider and the customer).
One misconception is that SLAs are only managed security
services. In fact, you can set up SLAs with your Internet
access provider, systems integrator, network cabling operator,
and even your auditor.
To craft one that works well requires not only a right dose
of legal know-how, but also an in-depth understanding of
the scope of service, the level of work to be completed,
accountability (or the absence of), schedule, costs, and
human involvement. It also requires an analytical approach
with a logical workflow to break down components that can
easily be apportioned to individuals or entities, and have
costs and time factors assigned appropriately.
Let us look at a simple example of an ISP that provides
leased circuit and business broadband services. It "guarantees"
24 hours uptime per day or it will refund twice the fees
back to the customer. Sounds good? Well yes until you see
the string of constraints attached.
For one, this "guarantee" is restricted to technical
faults on the part of the ISP that arise from a failed connection
at the ISP's gateway or a failed connection due to the ISP's
equipment. The ISP also states that in the event of scheduled
downtime, there will be no refunds.
At the same time, the customer will not get a refund if
the fault lies in the customers' own LAN, equipment, failure
of third-party telecommunication providers (presumably upstream).
Worse, the customer is not protected against hacks by external
parties, e-mail bombs, or viruses. "Acts of God"
a term that those in the insurance trade will be familiar
with are also listed as an exception, which can literally
mean anything. Thus, even if the ISP purports to provide
99.999% uptime or higher, beware of the small print that
can neutralize the intended SLA benefits.
The components required for a good SLA include: Service
description, service availability and/or response time,
acceptable range of service quality, metrics of measurement,
formulae for the metrics measurement, frequency of measurement,
rewards and penalties for performance targets, escalation
and crisis management, and an addendum outlining definitions,
people or departments involved, contact details, costs or
fees, and other related information that completes and encapsulates
Seamus Phan writes for Network Computing-Asian
Edition. He can be reached at firstname.lastname@example.org
ingredients for a successful SLA
you can define and describe your service clearly and comprehensively,
it is a good start to crafting the SLA. For example, a service
description for a managed security offering can be: "To
provide a comprehensive managed (outsourced) security solution
that allows remote employees and business partners to connect
to the internal network and data resources using an IP-VPN."
A service description provides an overview of the service;
detailed metrics, measurements, etc. come in later.
Next, you describe the primary parameter of this service,
be it system availability or response time. If you are buying
managed security, then system availability would be the
primary requirement. If you are buying a technical support
or maintenance service, then response time would be primary.
Here is where the numbers game starts. You need to define
a range within which the service should operate in. In an
SLA for Internet access, you may list the acceptable range
for availability as between 99.9 to 99.999%. If you are
buying technical support services, you may list the acceptable
range for response time as between 4 to 6 hours after a
support call is initiated.
Metrics of measurement
An SLA is then further described by metrics, which
drills down to smaller components of the service. If you
are buying a managed security offering, you may need to
describe QoS, availability, latency, downstream and upstream
bandwidth, service resilience (with auto or manual recovery),
and so on.
Here is where you outline the specifics on which the entire
service will be measured by. If the service provider states
that downstream and upstream bandwidth is "guaranteed"
at 1.5 Mbps, then the method of measurement must so be defined-such
as a Web-based interface or via command line.
The metrics of measurement is also integrated with how you
calculate the results, using formulae that are universally
accepted, or mutually defined. In a bandwidth scenario,
1.5 Mbps means that the leased circuit should allow upstream
and downstream data transfers of 1.5Mbps. This is easily
observed by the peak in an analysis chart for traffic that
goes in, and goes out of the gateway.
Once you identify the metrics and how to measure them,
you next have to define when and how often you measure these
Rewards and penalties
No service provider is infallible. Thus, the SLA must
include service provider accountability. This can be a two-way
street. If the service provider is consistently over-delivering
their contractual promises, you may opt to include within
the SLA a clause where you will increase your contractual
obligations. For example, if the service provider over-delivers
for one year with no major incident, you may automatically
extend an additional year upon the lapse of the contract
with no need for a new contract.
Obviously, make sure your SLA has clauses which allow you
to recover funds, or provision for recovery services and
extra personnel stationed on location till the non-compliance
An SLA is like an insurance policy to protect you against
the unexpected. Thus, at anytime, both parties must be prepared
to enforce the contract objectively and continue the partnership.
The SLA should have full crisis management and resolution
clauses built in. For example, if the service provider has
an upstream connection problem and you are locked out of
the Internet, the service provider should then provide alternative
equipment and a recovery team.
A good lawyer
Remember that the SLA is a legal and binding contract.
Don't simply sign off on a service provider draft. Instead,
engage a lawyer familiar with commercial law as well as
new economy law (including intellectual property), and have
the lawyer co-develop the SLA with your service provider
and their legal counsel.