A lot of individual consumers have never heard of a service-level agreement (SLA), or if they have, it’s been hidden, unnoticed, in the fine print of a signup form for internet or digital services. On the other hand, quite a few executives and others in higher level business management know what SLA means and why it's important for businesses that source various kinds of technical services from third-party providers. And you should too. In fact, if you're buying a tech service, it's a good idea to read the service-level agreement before signing on.
A service-level agreement is essentially a written agreement that describes what clients can expect from service providers. The idea behind an SLA is that services differ from consumer products. It’s easy to explain what someone is getting if they’re buying a piece of clothing, an appliance or even something like a car, but it’s a little harder to explain exactly what a customer gets from a service provider. An SLA solves this problem by spelling out the precise selling points and values of a service in a way that helps customers and providers get on the same page at the time that a deal is made. At least, that’s the main goal of these documents.
SLAs in the IT Market
In past decades, SLAs were often issued by internet service providers (ISPs) offering broadband connections. Nowadays, the rapid rise of cloud hosting services, software as a service, and other "web-deliverables," there is a bigger need for complex SLAs that spell out when a service will be available, how it will be supported and what customers will have a "right" to by signing on. (Learn more about cloud hosting in 5 Things to Know About Cloud Pricing.)
Common Provisions in SLAs
One of the problems involved in really understanding what an SLA entails is that for the average reader, tackling one of these documents is a major chore. The legalese and complex phrasing of many SLA documents can pressure a busy reader to ignore most of what’s in them. That said, there are some simple conventions that are part of many kinds of SLA documents. One of the best examples is an uptime provision. The phrases uptime and downtime are commonly used to describe when a service may be available, or unavailable, during a given time period.
Uptime and downtime in an SLA also present a good example of how the crafters of these documents need to try to quantify something that is inherently unquantifiable. In other words, with so many unknown factors, it’s impossible to know exactly how much downtime there may be for a system. With that in mind, an SLA often includes a "minimum" or "benchmark" for how much uptime the client can expect, where the actual service may be more available than what’s written into the agreement. By providing an estimate of uptime, there is at least a basic plan or agreement in place, where without the SLA, no one would have any idea of what to expect from a service.
Other aspects of an agreement are easier, such as specifications about how much data will flow through a particular service, in terms of actual gigabytes (or other scaled measurements.)
Big, Complex SLAs
One reason that concrete service identifiers, like uptime and downtime, may be hard to find in the average SLA is that another major portion of these documents often involves specific protocols and parameters for making complaints or "claims" against an agreement. Here, an SLA can start sounding a lot like an insurance document. As with insurance, the SLA may feature various "exclusions," which absolve the provider from some responsibilities. Expressions like "good faith" may also be used to describe client or provider responses. For example, in an SLA for Windows Azure, Microsoft uses a system of "service credits" to compensate clients for "SLA claims," stating: "Service Credits are Customer’s sole and exclusive remedy for any violation of this SLA." This first and important statement sets the stage for how clients will negotiate with the provider on any unforeseen issues around the SLA. Then, the provider sets up very specific rules and regulations for dispensing these service credits, based on how and when clients can submit claims. All of this is surrounded by a document structure that, like a legal document, first defines terms, then nests important aspects of the agreement in a series of tagged subsections with their own carefully enumerated lists of contractual details.
As another example, take a look at the SLA for Google Apps (G Suite). Google also uses service credits, and many of the practical parts of the agreement are similar, but everything is reduced to one page, with the big details up top. The SLA sets up the benchmark within the first sentence: "G Suite Covered Services web interface will be operational and available to Customer at least 99.9% of the time in any calendar month…"
"Useless" SLAs? When the Agreement Becomes Controversial
While readability can make a difference, some of the biggest issues with SLAs go far beyond how they are worded, and some of the most extreme cases eventually make their way public after drawing the attention of expert critics. One example is the attention directed at hosting giant Amazon Web Services and its SLA. Some have taken aim at the requirements of the AWS agreement. In one case, writer Brandon Butler cites Gartner’s Lydia Leong, who points out that the burden AWS is shifting onto clients in requiring multiple availability zones (AZs). Leong also slams the construction of many SLAs, calling them "word salads." The issue here is that adding AZs, or replicating storage, builds costs, and, as Leong points out, the creep of additional user responsibilities can make the eventual chances of any effective use of the SLA, in her words, "virtually nil."
A User’s View
Other issues around the terms of an SLA are brought up in user forums where individual users discuss SLA terms and what they mean. In one Amazon S3 SLA forum, where users discuss the documentation requirements for service credits, specifically, certain kinds of "error logging." This leads to another point on why Amazon uses a "synthetic" formula for uptime and whether customers can "game the system" on success ratios by sending a high volume of requests during a short amount of downtime.
Along with the controversy around the specific points of a SLA, some users wonder whether these contracts can also cause companies to acquire services and IT setups differently. One user in this VMware community forum seems to suggest that some businesses could rush to install virtual machine setups under the direction of an SLA, neglecting key support work in search of a quick build.
All of the above discussions illustrate why it’s a good idea to read through a service-level agreement fairly closely, and understand what these documents commonly include, rather than just pushing aside this kind of paperwork. Despite the fact that a lot of SLAs don’t read well, they tend to include some very important information for service users. If you're going to pay for those services, it's a good idea to get a sense of what you should be getting in return.
