There is an old joke about a hot-air balloon pilot getting lost and landing in a field to get their bearings. They see someone nearby and ask them where they are. “You’re in a field,” replied the onlooker. “You must be an accountant,” said the balloon pilot. “What you told me is completely accurate and totally useless.”
Apologies to accountants – they are instrumental and informative. But if we replaced them in the joke with a service level agreement, many people would nod. An SLA is often very good at telling you what’s going on but not what you need to know. In fact, SLAs are often accused of presenting a good picture that can hide a lot of dysfunctions. Some call this the watermelon effect: green on the outside, but under the surface, it’s all red.
“An SLA’s focus is usually on creating a checklist of indicators that, if you meet them, those systems then meet the customer’s requirements,” says Peter Blaauw, CEO of data backup experts Sithabile Technology Services (STS). “The problem is that SLAs are often designed around the indicators, not the outcomes, and so they show diligence but not overall performance.”
Take data backups as an example. An SLA might state that there should be 95% backup performance. That sounds great, especially if the provider hits the target. But what about that extra 5 percent? It’s unrealistic to expect an SLA to maintain 100 percent performance constantly. Yet, what if the 5 percent includes servers with very critical data? How do you know if the 95 percent coverage covers the right data?
A 95 percent SLA performance can be entirely accurate for the agreement but useless to the company’s requirements. All the indicators are green, but the outcomes remain red.
The four pillars of a good SLA
This begs the question: what is a good SLA? How do you ensure the arrangement with your service provider will meet business requirements? Blaauw and his team at STS operate in the nuanced world of backups where not all data is the same and not all backups or recoveries have the same demands. Yet companies often sign SLAs that are surprisingly blunt and ineffective.
“The question that kept coming back to me is, ‘what really differentiates an SLA’? SLAs are pretty bland documents with straightforward stipulations, but they still fail to deliver. We considered this issue and came up with four elements that decide if an SLA is going to work or not,” says Blaauw.
Finance is the first element. Many companies make a mistake when they equate savings to value. A good SLA’s value isn’t measured by how much less one spends but how effectively the SLA gets value out of business systems. Does the SLA ensure the technologies deliver?
Compliance is as substantial. An SLA might stipulate excellent benchmarks but fail to prioritise nuanced requirements. Referring to the earlier example on data backups, 95% backups are not very compliant when the missing 5 percent contains crucial and sensitive information.
Technical ability is crucial. Too often, service providers agree on SLAs for technologies without having sufficient skills and experience in those systems. Service providers might have to engage with backup technologies that are incompatible with business systems, such as specific ERPs. But the customer already uses that backup software and the service provider doesn’t tell them they have a mismatch.
And then there is visibility: many SLAs don’t bring the mountain of reporting to the doorstep of their clients. If the SLA’s coverage is expressed through dozens of emails and routine reports, the customer is unlikely to study these often (as opposed to a customised dashboard). Visibility becomes a chore, and the SLA’s performance becomes challenging to measure accurately.
Tips to design the best SLA
An SLA’s purpose is to delegate responsibility to a skilled provider and benchmark performance to ensure companies get what they expect without wasting resources. It’s very easy to assume that because an SLA achieves its indicators, it’s delivering value.
To avoid that mistake and achieve the four pillars—finance, compliance, technical skill, and visibility—Blaauw recommends the following tips:
- Respect a service provider who says no or pushes back on specific areas. Developing an SLA cannot be wholly prescriptive by either party. It benefits from honest discussion. Providers agreeing to everything or customers prescribing everything will create poor SLAs.
- Vet the provider’s experience. How much work have they done and continue to do in their field? And do they invest in understanding the areas that impact their field? For example, does the backup provider employ a cloud expert who aligns their services with cloud environments?
- Include the provider in your change processes so they can adapt to new elements in your environment. What’s the point of an SLA to back up your servers if the provider doesn’t know you’ve added new servers?
- Work with providers who want to audit your environment and ensure you have a complete picture of your requirements. And hold onto providers that bring new ideas and suggestions to the table.
- Don’t treat SLAs as static. A five-year SLA agreement is really five one-year agreements. Evaluate and adjust the SLA to keep pace with change and innovation events.
“There’s an onus on the service provider to take a practical interest in the customer’s business, not just asking necessarily backup-related questions, but finding out about what’s on the roadmap and experimenting with new ideas,” says Blaauw. “A good SLA is not about handing something off. This is about bringing somebody in who pays attention.”