How To Protect Your Company In The Cloud
A well-crafted service-level agreement and exit strategy are essential as you engage with cloud computing providers.
Download the entire Feb. 15, 2010 issue of InformationWeek, distributed in an all-digital format as part of our Green Initiative
(Registration required.)
We will plant a tree
for each of the first 5,000 downloads.
Business executives are reading about cloud computing and asking when their companies are going to get on board. CIOs must do three things to respond to those requests and to help business units take advantage of cloud computing without putting them at undue risk.
First, don't be dismissive of the cloud. Business units will simply bypass IT if it doesn't provide guidance. Second, advise business leaders on cloud risks and risk-mitigation strategies. Third, when the decision to use a cloud service is made, establish realistic and balanced service-level agreements.
Establishing an SLA is just one aspect of protecting your organization. What's needed is a step-by-step assessment-to-implementation process, helping business managers balance risk, fiscal impact, and flexibility. If the decision for a given IT service goes in favor of a cloud approach--software as a service, platform as a service, infrastructure as a service--you need to figure out how to proceed and what to do if and when things go wrong. That's the core of not only an SLA, but of good governance.
Getting the answers to the following questions will help you determine if cloud computing makes sense, evaluate providers, determine if you need an SLA, and, if so, how to craft a strong agreement.
1. What's the use case? Why are cloud services being considered?
Say you need to develop quickly a specialized, temporary application for a boat dealership, one that scales up and then, just as quickly, gets decommissioned. That's a great use case for cloud computing. There's little capital expense needed and, with the right service provider, the app can be deployed effectively. But not every use case is appropriate for cloud computing's current level of maturity. Something that can be quickly accomplished using your internal IT infrastructure might not make sense to push out to the cloud.
2. What are the risks and benefits?
If you're going to live in the clouds, bring a parachute. In addition to evaluating the benefits, be realistic about worst-case scenarios, such as if the application isn't available, performance bogs down, or there's a security breach.
It's useful to classify these scenarios by their relative probability, as well as by their impact on the business. For example, an enterprise application that many are reluctant to provision into a cloud environment is ERP, where there's a high impact of failure regardless of the probability of failure, which is never zero.
3. Is a negotiated SLA needed? If so, what penalties are appropriate?
Think about why SLAs are necessary. It's because you're protecting something that someone else manages, and you want your service provider to have skin in the game. You know that the provider faces higher costs to offer availability guarantees, costs that could show up in the vendor's bottom line. They've got to account for that somehow, so as you turn the dial up on SLA penalties, the cloud service is going to get more expensive.
The point is that there's a natural tension between low-cost cloud computing and high SLA penalties. The risk premium that any provider must add to its business model--and thus to your pricing--is in direct proportion to financial penalties that the provider would be forced to pay out in the event of an SLA violation. There's a similar natural tension from the provider's perspective between high-availability and low-cost operations.
SLAs are all about recourse and what you can do to protect yourself when bad things happen with your cloud service provider, but SLAs aren't the only recourse. Switching service providers or using internal resources are other possibilities. So if your app dev team is using the cloud to build a testing lab quickly, and that testing could easily be rescheduled in the event of an outage, you probably don't need a tightly negotiated SLA. Many providers offer a baseline SLA with service credits, which might be fine for this application. But if a service failure would harm your business significantly, your use case probably isn't a good match for today's cloud offerings.
To read the rest of the article,
Download the Feb. 15, 2010 issue of InformationWeek
Download Our Cloud Contracts Report
Get our complete report on how to craft service-level agreements that protect your company as you tap into cloud services, Download Our Cloud Contracts Report
What you'll find:
An in-depth action plan for devising cloud SLAs that are appropriate for your company's cloud computing use case
Questions that CIOs should consider as they evaluate cloud metrics and other factors
Additional research from InformationWeek Analytics.
Download this Analytics Report: $99 for a Limited Time
About the Author
You May Also Like