Breaking down what's in your cloud SLA
A comprehensive collection of articles, videos and more, hand-picked by our editors
Let's explore what makes a company cloud-ready. A cost-benefit analysis confirmed the cloud is a good option. An internal investigation has determined which pieces of infrastructure and business applications will move to the cloud. There's been a comparison of the features and pricing structures potential service providers offer. It's time for the company to get started.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Has something been overlooked? The answer is a resounding "yes!"
What's missing is a discussion of the service-level agreement (SLA), the cloud contract a project manager will need to sign in order to seal the deal. This is often missed under the misguided assumption that it'll be the same regardless of which partner a company chooses, or the misconception that conversations held about system performance and uptime fill that particular bill. But it won't, and they don't, and the negative impact on meeting an enterprise's compliance requirements can be significant.
Under the radar and potentially troublesome
There are two big reasons SLAs fly under the radar: No one anticipates trouble when they sign a deal -- if they did, they wouldn't sign -- and everything usually goes according to plan. In this way, SLAs are much like insurance policies, which are similarly critical to protecting your interests but typically enjoy a higher corporate profile.
There are two huge differences between the two:
- Insurance policies cover physical assets (buildings, equipment, human beings, etc.) while SLAs cover virtual ones (records, data, documents, etc.).
- An insurance carrier carefully inventories and appraises the value of the covered assets, and a cloud provider doesn't.
Taken together, these mean that any issues that do arise can be much messier to resolve and remediate, and if the conversation isn't held at the start of the relationship, the potential exists for there to be trouble down the road.
Read the cloud contract and ask the questions
The key to avoiding an unhappy outcome is to ensure your SLAs support the same compliance regulations your organization is subject to.
The key to avoiding an unhappy outcome is to ensure your SLAs support the same compliance regulations your organization is subject to. No doubt this sounds obvious, but consider the way you sign up for Salesforce.com, Office 365 and similar offerings. Do you take the time to read the service agreement before you click "yes" and enter your credit card number? My guess is that you don't, and the result is that you're working in the cloud at the pleasure of the provider.
Consider the following questions:
- Are there circumstances under which the cloud provider can access your information? Can they delete it?
- Does the provider regularly archive your data? If so, how often? Where is the archive stored?
- Are the terms one-size-fits-all or are there differences per country or industry?
- What happens if a breach occurs? Who's responsible? What are the limits of liability?
- What happens to your data if the provider goes out of business?
These questions may not loom large when it comes to personal use, but they are huge when it comes to your business. They speak to hot-button issues like privacy, security, retention and other aspects of governance. And while most providers have solid-sounding answers, they may not align with your own compliance mandates or be detailed enough to qualify.
A strong SLA will leave businesses with a cloud solution that provides the proper financial return, interoperates with the rest of company infrastructure and contractually satisfies compliance needs. If the SLA does not provide these benefits, it's time to start the dialogue!
Steve Weissman asks:
Has your company adequately discussed the cloud provider's SLA agreement?
0 ResponsesJoin the Discussion