Cloud // Software as a Service
News
2/11/2010
03:24 PM
Connect Directly
LinkedIn
Twitter
RSS
E-Mail
50%
50%

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.

InformationWeek Green - Feb. 15, 2010 InformationWeek Green
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

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


Comment  | 
Print  | 
More Insights
8 Steps to Modern Service Management
8 Steps to Modern Service Management
ITSM as we know it is dead. SaaS helped kill it, and CIOs should be thankful. Hereís what comes next.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest September 18, 2014
Enterprise social network success starts and ends with integration. Here's how to finally make collaboration click.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.