In Part 1, I was talking about using the public cloud, with appropriate business-level SLAs, for business-critical processing. As usual, however, the devil will be in the detail and cloud services suppliers like Amazon are unlikely to want to offer business-level SLAs. And, today, it's even difficult to get a real handle on comparing different cloud services. Amazon EC2 offers a degree of resilience, apparently; but recent outages suggest that this wasn't always as effective as some of its customers needed or expected—"resilience" isn't just a tick-box thing, you need to be able to evaluate its practical effectiveness in your particular circumstances and test your own implementation of any resilience features.

Now, Barbara Korte (Global Sales Executive, Tivoli Service Management, IBM Software Group) pointed out to me at PCTY that today's analytics should help us to estimate the business-level cost and value delivered of one cloud implementation relative to another in lots of areas (including, but not limited to, resilience). I also think that initiatives similar to Cloud Commons and the Service Management Index could soon help us to compare service levels meaningfully (i.e., in a vendor-independent way). This means answering questions such as "what does 'resilience' from this provider really mean; and does it offer more effective resilience, in my specific circumstances, than my current cloud service; and is this worth paying more for...".

I think we'll eventually see the rise of a new breed of cloud-oriented SI that will let us buy public cloud services with business-level SLAs and proven (testable) resilience, including fail-over from one provider to another if needed. This won't be as cheap as buying cloud from the source, but it will offer the guaranteed performance and resilience appropriate to business-critical automation—if you choose to pay for the appropriate SLAs.

Whether, for example, your data lives anywhere in the world, or in Europe or in a part of the cloud physically locked to a server inside your building (as some regulations might require), is simply a matter of buying successively more expensive SLAs. Compliance, at the business level, is then a matter of pointing at a legally enforceable contractual obligation. The SI will use the analytics and technology that vendors like IBM are producing to manage business-level cloud SLAs across different vendor technologies (and Korte emphasises that IBM, at least, is devoted to open-systems standards, which will make this much easier for the SI).

I asked Paul Hinton of solicitors Kemp Little LLP about the feasibility of managing compliance in terms of contractual obligations and he warns that, "many cloud providers will only offer the cloud on their own standard terms and so, unless you are willing to negotiate and pay for a particular form of "cloud", you may have to select the standardised version that best fits your requirements". Nevertheless, Hinton says, "the best way of ensuring your own particular business standards are met is by accurately reflecting them in all relevant contracts, including upstream with your service and downstream with data providers (e.g. customers)—to ensure that everyone is aware of how their data will be treated".

Of course, as Hinton goes on to point out: "The hard work will have to be done up front by each business in: (i) deciding what data can be put into a cloud; (ii) deciding whether the data needs treatment or extra protection (e.g. masking) before being put into the cloud; and (iii) assessing and negotiating with the particular cloud provider to ensure the standards offered meet their particular business needs and compliance obligations".

Although these business-level SLAs will probably cost more than technical SLAs, the high-maturity companies basing their business on them will still get all the advantages of agile cost-effective provisioning and (most important) de-provisioning, and vendor-independence that cloud computing promises. They will pay for their "gold standard" SLAs with the profits from more and better-governed business processes and the ability to manage their business risk more productively.

I think the real promise of cloud computing is a change in mind-set from technology to "business outcomes" built on entirely abstracted services. And this will, as an aside, have a fundamental impact on the conventional IT group. Perhaps this is not the place to go into details on this, but I see a decline in the importance of "systems development", for most general businesses, and an increase in the importance of "services orchestration" by operations groups that can manage delivery. This implies a change in focus from developers or programmers to operations gurus, who actually make technology deliver on its original promises—and, as Korte pointed out to me after PCTY, perhaps it is significant that Danny Sabbah has moved from heading up Rational (all about Development) to heading up Tivoli (all about Operations)—hear his thoughts about integrating Rational and Tivoli (from 2010) here.