In our last post we discussed the positive shift in the Cloud Computing discourse towards actionable steps rather than philosophical diatribes on definitions. And to support that discussion we offered the following list of things not to do:

1. Not understanding the business value
2. Assuming server virtualization is enough
3. Not understanding service dependencies
4. Leveraging traditional monitoring
5. Not understanding internal/external costs

In this installment we are going to focus on the first mistake - failing to understand the business impact of leveraging a Cloud delivery model for a given application or service.

What are you trying to do?
The first step when evaluating a Cloud delivery option is to define the service: is it new or are you considering porting an existing service? Both options have their advantages and disadvantages. If new, there is a lower financial bar to justify a Cloud model (no legacy infrastructure to write off), but there's also the downside of having no historical perspective on consumption trends to aid in evaluating financial considerations or performance. We'll discuss both financial and performance considerations in a future blog, so for now let's continue and assume we are talking about a new service.

Is Cloud a better option than traditional approaches?
The next step is to clearly articulate why you are looking at Cloud, and for many IT executives this may require a dose of painful honesty. Are you looking at Cloud because:

• Your business requires a highly scalable solution?
• Your data center is out of capacity?
• You expect this to be a short-lived service?
• You need to collaborate with a business partner on neutral territory?
• Your business has capital constraints?

If so, those are all good reasons to consider a Cloud option. However, if you are looking at Cloud because it takes weeks/months to get a new server in production, or your Operations team has no credibility maintaining a highly available service, or your internal cost allocation models are atrocious...well, perhaps there are some in-house improvements you should be prioritizing before exploring Cloud.

Just because you can doesn't mean you should!
A painful lesson learned early (and for some of us, often) in life is that just because you have the ability to do something doesn't necessarily mean it's a good idea. Look no further than the disastrous results many firms had in the early days of e-business when they exposed legacy internal applications to the Internet for evidence of this axiom. As you contemplate moving applications/services to the Cloud (particularly public services), you need to answer these questions:

• Does this application consume or generate data with jurisdictional requirements (i.e., data cannot be stored outside of a specific geography)?
• What will happen if there is a security breach/data loss? Will your company face fines or a public relations nightmare due to an expose on the front page of the Wall Street Journal?
• If this service runs poorly, what part of your business value chain is exposed? Are there critical systems that rely on it?
• What happens if the application/service doesn't run at all? Would you be dead in the water, or are there alternatives that allow the business to continue functioning?

The last bullet warrants further explanation, as many IT professionals experienced with outsourcing/hosting relationships may point to contracts with strict SLAs as their answer. Penalties are well and good, but what happens to your business if this service cannot run? Although Cloud Computing is still in its infancy, there are already numerous examples of failures that no SLA can guard against: bankruptcy (and/or going out of business); change of ownership (something that is inevitably going to happen more frequently as the market matures); or even government investigations (if a government agency has a search and seizure warrant to investigate a company using the same Cloud provider as you, it's highly unlikely that they will take the time to sort out the bad from the good - they will take everything). The lesson here is that SLAs are not enough - you must have a contingency plan to restore the application/service/data on another provider or internally or accept the risk of this service being unavailable for an extended period of time.

There are tremendous benefits to embracing Cloud services (public or private). We hope that this piece does not discourage anyone from pursuing this goal, but rather generates a candid dialogue about the business value of the service in question.

In our next blog we'll explore the next segment on our list - holistic virtualization.

• Cloud Computing: What NOT to Do
• Virtualization Does Not a Cloud Make