White PapersSetting Expectations with SLAs
Outsourcing SLA - Setting Expectations
In a new industry, where defined metrics do not yet exist, expectations are unclear – what should a consumer expect with regards to a Service Level Agreement or SLA? Is this a mere insurance policy against failures, is it nothing more than a discount structure applied through punitive means, or is there room for a true SLA to provide competitive advantage to a business customer? This document provides businesses with details about what to expect when navigating the myriad of issues surrounding Service Level Agreements in the outsourcing marketplace.
Online backup is an example of an outsourced service and some of the criteria below may apply to this simple, yet critical business process. This document does not, however, imply that the criteria below are strictly relevant to online backup nor that all the criteria are applied by Backup Direct™ in relation to its online backup service.
Why ask for an SLA anyway?
The first question that must be answered in dealing with any SLA is ‘why bother?’ While it may seem trite, understanding why a business wants an SLA is fundamental to the mutual success of both provider and consumer. At its core, an SLA is a punitive document. It is part marketing brochure, part boast. It is a statement about what capabilities a business believes it can offer, and what performance it can sustain. But at its heart, the document boils down to punitive measures enforced when promises do not meet performance. Remedies are typically financial and seldom can repair the damage that can arise from non-performance. For example, when a mission critical application hosted by a third party service provider, goes down due to infrastructure failures at the service provider. While the clock may start ticking against the SLA warranted down times, the damage incurred by the business consumer will far outweigh the credits given. These credits are generally against the hosting service charges of a particular month’s bill. Credits offered against miniscule monthly hosting fees are insignificant against lost revenues of a business consumer, damage to business reputation and credibility, as well as potential career damage to the decision maker who authorized the outsourcing contract in the first place. Since no financial remedy will ever be adequate enough, focusing on the punitive aspects of an SLA is one of the pitfalls to avoid when crafting this document. The business consumer should avoid too much attention on remedies for failure, and focus more energy on the mechanisms that prevent failure from occurring in the first place. A successful SLA will alleviate doubt from the consumer’s mind, and help ensure business continuity more so than offer financial compensation for substandard performance.
What approach makes the most sense?
One of the contested issues around SLA’s in the Online Backup marketplace is an ongoing philosophical difference between component based agreements and holistic / service based agreements. Providers are more often able to measure elements or components of discrete services and thus tend to offer remedies and documentation that address component-by-component the items of a given service – without ever tying it all together. Other providers have opted for a more holistic approach at the service level, but the pitfalls have been non-specific warranties, generic language, and mismatched expectations between provider and business consumer. The most successful implementations of SLA agreements begin by looking at the service as a whole, from the customer’s point of view. Identifying the key aspects of a solution that must function properly, serves as a first step in identifying how to tie these elements together under a complete SLA. Providers must realize that a partial solution is no solution and use component based capabilities to build a complete overview that warrants all the components of a service and gives the business consumer assurances that the overall solution will be delivered as promised.
What should be in an effective SLA?
There are three key areas that are generally addressed in the successful SLA. The first is categorized as ‘infrastructure warranties’. In the Online Backup marketplace this category tends to include performance characteristics around facilities, connectivity, hardware reliability and general availability of discrete technologies. The second key category of an SLA is ‘process warranties’. This category includes items like turn around times for work process events such as – add new user, delete user, and setup new account. However it may be extended to include items like … develop new scripting module to accommodate ‘x’ requirement in ‘y’ period of time. The third key category of a successful SLA is ‘escalation warranties’. This category is designed to give as much assurance as possible during unforeseen failures, acts of God, external contributor failures, etc. As no-one, perhaps excluding God, can guarantee perfection, this category is designed to outline the flow of how a failure is resolved, what time frames to expect, what percent of failures may fall within a given level of disaster, etc..
The infrastructure warranties section of an SLA is the easiest section for a business consumer to become enamoured with. Providers are generally quick to throw out impressive quality standard numbers such as the ‘five nines’ availability percentages (99.999%) uptime. Some vendor’s only count the nine’s behind the decimal point, some imply it. But the net effect is to offer an extremely high amount of availability to the consumer, and ideally lift that consumer’s feelings about how the vendor will perform given the guarantee. But herein lies another pitfall to avoid, the number of nine’s in a given guarantee can quickly be negated by two factors, the first is exclusions, the second is relevance.
Most service providers who offer such high availability standards provide a laundry list of exclusions from which time is exempt against the overall SLA measurement. Common exclusions are ‘scheduled maintenance windows’ which may involve anything from upgrading equipment, to periodic reboots, to backing up critical information. For example, depending on the application technology being offered by the Online Backup and the proficiency and skills of the provider, an NT platform is often placed on scheduled reboots, to ‘clean-up’ a given system’s performance and thereby reduces the number of ‘unplanned’ negative events. If this reboot schedule is more than once a week, and takes 15-30 minutes or more to complete, the ability to offer true 5 nine’s performance is negated. Other exclusions may involve the infamous acts of God, warfare, terrorism – but more importantly may exclude SLA provisions for failure of a third party which the service provider does not directly control. This limitation is often rightly used to exclude a local ISP of the business consumer where the provider does not directly control the ISP’s operations. It may also be deployed against software vendors for ‘anomalies in the code base’, which require the software vendor to fix themselves. Sometimes connectivity providers fall into this arena for the sections of the network they operate between consumer and the end-all hosting provider. Business consumers should be wary and closely examine the exclusions of an agreement and ensure that the ‘real’ availability of the service matches the perceived warranties.
A business consumer should also take special note of the ‘Application’ wording in the outsourced marketplace with respect to exclusionary provisions. Closely examine the software license agreement of any off the shelf product and the language used excludes the software from providing any benefits at all – except by sheer accident it would appear. Every possible liability is disclaimed. Given that primary software providers disclaim all warranties of their software, Online Backup providers then have a difficult task attempting to warrant a service, which relies at its core on products the original manufacturers refuse to warrant in any way. While premium service providers will attempt to ‘own’ the entire service experience for their customer base, at least from a single point of contact, or responsibility point of view, no service provider can warrant software code above what the developer will take responsibility for.