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.

Jonathan Feldman, CIO, City of Asheville, NC

February 12, 2010

5 Min Read
InformationWeek logo in a gray background | InformationWeek

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

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


Read more about:

20102010

About the Author

Jonathan Feldman

CIO, City of Asheville, NC

Jonathan Feldman is Chief Information Officer for the City of Asheville, North Carolina, where his business background and work as an InformationWeek columnist have helped him to innovate in government through better practices in business technology, process, and human resources management. Asheville is a rapidly growing and popular city; it has been named a Fodor top travel destination, and is the site of many new breweries, including New Belgium's east coast expansion. During Jonathan's leadership, the City has been recognized nationally and internationally (including the International Economic Development Council New Media, Government Innovation Grant, and the GMIS Best Practices awards) for improving services to citizens and reducing expenses through new practices and technology.  He is active in the IT, startup and open data communities, was named a "Top 100 CIO to follow" by the Huffington Post, and is a co-author of Code For America's book, Beyond Transparency. Learn more about Jonathan at Feldman.org.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights