[post by Dominick Dequarto]

When I was a data center manager, the questions for every application were:

1. How critical is the application’s availability?
2. How critical is application’s data?

There were layers of complexity, to be sure, but from those two questions, I would dole out resources to address both of those items for each application or dataset, according to the application’s criticality to the business.

Nonetheless, it was relatively simple.  I would use my best technical judgment to assure that the needs were met in accordance with the resources provided, and assure myself that because I had hire, fire, and motivational authority, I could assure that the plans were carried out.  I was assured at the corporate level that my employees were trustworthy, and because I worked largely in the federal business, I had security clearances for my employees on top of that.

So now there’s a sea change to the cloud model. Whether it’s public, private, a mix, or a hybrid, the game has changed.

But what, exactly, has changed?

Certainly not the two primary questions regarding application and data availability – those still should be first and foremost in my mind.  That’s not to say that I can’t NOT care about an application, of course.  Maybe there’s a necessary app, but doesn’t have much impact on my business, I’m not going to spend a lot of resources supporting it (there’s a term for that – it’s a craplication).

Things have changed.  Now we’re “hosting” or using “software as a service” or “leveraging the cloud.”

However you say it, things have changed – even for craplications.  Those SharePoint sites or messaging applications you’re hosting may have employee social security numbers,  or maybe company intellectual property you don’t know about.  Or maybe it’s tied into payroll in a way that people don’t get paid if SharePoint isn’t up…

These are the things of nightmares, right?

To my thinking you need to consider three more items when considering the Cloud:

• What is the impact of data spillage?
  • How do I determine whether my data is even being compromised?
  • How much would I need to compensate my customers in the event of a public compromise?
  • How much would I need to compensate my employees in the event of a public compromise?
  • What is the value of the intellectual property I could lose, and how do I even go about measuring the impact?
• Without the ability to hire, fire, and motivate, how do I ensure timely response to service or data availability issues?
• How will I manage point to point serviceability issues outside of my Cloud Provider’s commitment for service?

This is all very interesting cocktail conversation (among those of us who are used to dull cocktail conversations).  But for the IT manager, who’s going from managing people to managing Service Level Agreements (SLAs), what does it mean?

The not-so-scary fact is that all the IT manager has to work with is the SLA with his or her cloud provider.  It’s scary in that we can no longer put specific people on the hot seat.  But it’s not so scary in the sense that we can:

(a)    Negotiate terms before the contract is executed

(b)    Enumerate those terms to the business owners

Namely, we can cover our collective asses.  For example, we can say “Yes, we can spend $10 less per mailbox per month, but these are the financial penalties we need to protect ourselves from.”  We can also say that “this is how we can mitigate those risks and costs and thereby reduce the cost of protection.”

The first step is to educate yourself on the particulars of the SLA.  Any provider not willing to provide you with a boilerplate or “default” SLA is not worth speaking to.  In Microsoft’s case, the BPOS SLA is out there and easy to read, even for those without a J.D.

The next step is to apply what you know about the application you’re thinking about moving to the cloud to the appropriate SLA.

• What are the physical boundaries of my SLA?

Often acknowledged, but for a moment think outside the box.  So your Cloud Provider is touting 5 9’s uptime, you’re extremely comfortable and happier than a lark, but what are the real boundaries of that SLA?   Does it include accountability and serviceability to your organizations front door?    Most likely not.  Point here is do not discount the weakest link in the chain.   Get to know your ISP intimately and what their SLA means to your business, understand their technology as well as which networks you have to traverse in order to get to your Cloud Providers front door.  Be sure to close the gap on accountability from your organizations front door to, and into, your Cloud provider’s home.

• How critical is the application’s availability?

What metrics are measured?  Is it just web access to mail, or is ActiveSync, MAPI, and BES part of the SLA (and can I define different levels of service for those)?  What is the cost to my business if email is out for 24 or 48 hours?  What is the cost to my provider?  Can I apply any leverage?

• How critical is application’s data?

What is the cost to my business if the provider loses the data in my users’ mailboxes/sharepoint sites/data farm?  What is the cost to my provider?  Can I apply any leverage?

• How do I assure the security of my data?

How do I determine whether my organization’s data is exposed to potential hostile parties?  What is the company’s cost if I determine that’s the case?  Is it dependent on the type of data (customer proprietary, employee proprietary, or company proprietary)?  What is the cost to the provider?  Can I apply any leverage?

I guess the answer to the question regarding “What am I giving up?” is resoundingly “Leverage,” and to some extent, “Security.”  Security is probably the easiest to address, but both can be mitigated with attention to the service level agreement that you negotiate.

My advice is to go into it with your eyes wide open.

- Dominick