Do service-level agreements (SLAs) scare you? SLAs are often (and unfortunately) misconstrued as unattainable goals levied on system owners because of fancy dreams that organizations would like to have their customers experience. But that’s not the case. In this article, I explain the basics of SLAs, and what to look for as you and your service provider design a SLA to put in place.
An SLA does just what it hints at: It defines the service being offered and agreed-to by everyone concerned. The document describing an SLA covers particulars such as the level of service that customers expect, the metrics for measuring “enoughness” of the service, and the remedial course of action in the event that the service is not met.
Generally SLAs are drawn up between customers and their vendors, service providers, suppliers, or other organizations. In larger businesses, where departments can work like independent organizations, SLAs can be chalked out between departments as well.
In IT, we tend to behave as though SLAs are relevant only to computing, but they apply to most business types. Imagine an SLA established between a freight service provider that serves an online store. Such an SLA might cover the promptness of providing transportation, with details about delays allowed and delays unaccepted. For example, the SLA for that online store can lead everyone to expect its freight provider to assure 24-hour delivery to customers, with permissible delays of up to 48 hours on busy days. But this is just a single example; ideally an SLA covers all aspects of a service being offered.
So what is in it for me?
In one word – everything! SLAs set expectations accurately, for both customers and vendors!
An SLA tells you what you do and what you do not do. It describes what a service is, and what it is not. It explains what each party involved (both customer and service provider) should be doing, what each should avoid, and the consequences if those expectations are not met. For example, with Druva inSync, a typical SLA stresses the backup of endpoints as opposed to servers. Druva would have a separate SLA in place for (the new, awesome) Phoenix to cover server backup.
It’s not just “what gets done when.” An SLA documents the security goals are (and are not). For instance, Druva’s SLA explicitly mentions that we use AWS, and hence, we use the security measures adopted by Amazon.
SLAs also contain the details for what each party does when an ugly problem is encountered, such as describing the support and escalation mechanisms. They also dictate uptime and availability targets. In so doing, SLAs bring out organizational performance priorities.
An SLA puts in place the disaster recovery, backup, and restore processes. For example, an SLA for Druva Phoenix can explicitly contain details about customer data retention policies.
The essential components of an SLA (which can be anything from a few pages long to a few hundred pages) including a statement of the parties’ intent, a description of the responsibilities of each party (including acceptable performance parameters and applicable metrics to measure their delivery), monitoring procedures, a schedule for remediation of outages and associated penalties, and problem-resolution procedures.
The SLA may have a statement regarding the expected duration of the agreement, as well as a description of the applications and services covered by the agreement (though when that’s all there is we often call it a “customer SLA”).
What’s in an SLA?
At the broadest level, an SLA should focus on two areas: services and management. Services include what a vendor offers, and management covers all that they agree to do to make the receipt of the offering acceptable. If there is any room for doubt, the SLA should also make it a point to include all that is not promised.
What should “service” cover? Think of elements such as services provided, conditions for service availability, service standards, responsibilities of the buyer and the seller, and escalation mechanisms.
Management includes elements that enable service delivery and receipt. Examples include definitions of measurement standards, reporting, dispute resolution mechanism, indemnification clauses, and a mechanism for updating the agreement.
What if everything falls apart?
Software is not invincible. (What is?) There could be scenarios where the promises cannot be kept and the company cannot meet the agreed-upon standards; the SLA should come to your rescue. For example, a cloud service provider’s SLA might promise an uptime of 99%. An SLA clause such as “We will credit you $50 for every hour of downtime” might not be fair; that amount may not be representative of the company’s loss of business during a service outage. By default, the SLAs almost always tilt (even if slightly) in favor of the service provider! So look for the cloud service providers’ responsibilities in the case of a breach of agreement (even if unintentional) that match your company’s dependency on the feature or attribute.
Who provides SLAs?
Providers of services (as if the term wasn’t hint enough) should be armed with SLAs as a natural part of drawing up the business deal. But it does not stop at that. If you are the customer, you should involve your legal counsel in the process. SLAs are typically reviewed by your legal team in order to determine the adequacy of the SLA’s clauses.
An SLA usually comes from the provider, which is why you should not be too surprised to find them tilting in favor of the providers. Legal assistance, therefore, is an absolute must! That’s especially true if you foresee mergers or acquisitions; they can impact the SLAs as well.
One important section of the SLA is indemnification, which means the provider agrees to pay the customer for any third-party litigation costs resulting from its breach of the warranties. A standard service provider’s SLA may not include this provision; in-house counsel may choose to draft a simple provision to include it, although it may cost more time in negotiation with the service provider.
Organizations often renegotiate their SLAs to suit changing needs, but this is not a blanket rule. Your SLA might stay unaffected as well. That is why your legal team should be your new best friends!
What about the “levels” in SLAs?
Not every SLA follows the same boilerplate. Often, SLAs are defined at different levels of the offering. SLAs commonly address a definition of services, performance measurement, problem management, customer duties, warranties, disaster recovery, and termination of agreement.
At the most general level, an SLA looks a lot like a customer agreement or work agreement. Think of these as appearing on a scale, like this:
- Customer SLA: Such SLAs cover all the services that a vendor offers to a customer. For example, inSync customers have their own special SLAs that cover details such as the number of licensed users and chosen add-ons.
- Service SLA: This type of SLA differs from a customer SLA in its scope. It is applicable to all customers, but contains details about each services that each customer stands to enjoy. For example, a garage can roll out an SLA indicating the type of maintenance services for which the customer paid.
- Multilevel SLA: This is a hybrid of a customer SLA and a service SLA. A multi-level SLA is broken into the different levels; each such level addresses different customers for the same services.
- Corporate-level SLA: Such an SLA covers all aspects of service level management (SLM) across an organization. These issues require less frequent updates because of their propensity to avoid volatility.
- Customer-level SLA: This SLA covers all SLM issues for a customer group, regardless of the services that they use.
- Service-level SLA: This SLA is a contrast to a customer-level SLA. It covers all SLM issues for a service, irrespective of the customers that consume the service.
Give me an example of how an SLA makes sense
Cloud computing benefits from using an SLA! In fact, you should endeavor to make sure all cloud services include an SLA.
The single most striking benefit of cloud computing lies in sharing of resources. This involves shared infrastructure, which in turn, creates a new need: that of defining the what, how, and when of what is shared – all of which are individual expectations that need to be documented in writing.
In a cloud environment, the SLA metrics depend on how end-users perceive their cloud experience. That is also why SLAs in a cloud environment are a complex accompaniment; the nature of the cloud infrastructure makes it difficult to determine service interruptions. In a cloud environment, SLAs focus primarily on the characteristics of the data center and the network to lay down comprehensive SLAs.
To sum it all up, SLA is the most valuable document to keep you happy, and your customers happy as well. Unquestionably, SLAs tiptoe on the fine lines of political correctness. But that is all a given. After all, imagine the wars that would erupt without one in place!