SLA: MIA

One of the most common concerns regarding cloud computing is the potential for downtime—time the system isn't available for use. This is a critical issue for line-of-business apps, since every minute of downtime is a minute that some important business function can't be performed. Key business apps include taking orders, interacting with customers, managing work processes, and so on. Certainly ERP systems would fall into this category, as would vertical applications for many industries; for example, computerized machining software for a manufacturing firm, or software monitoring sensors in industries like oil and gas, power plants, and so on.

Faced with the importance of application availability, many respond to the potential use of cloud-based applications with caution or even horror. This concern is further exacerbated by the fact that some cloud providers don't offer SLAs and some offer inadequate SLAs (in terms of guaranteed uptime.)

Underlying all of these expressed concerns is the suspicion that one cannot really trust cloud providers to keep systems up and running; one might almost call it a limbic apprehension at depending upon an outside organization for key business continuity. And, to be fair, cloud providers have suffered outages. Salesforce endured several in recent years, and Amazon also has had one or two not so long ago.

Put this way, it's understandable that organizations might describe the concern regarding this all-important meeting of critical business systems with cloud provider reliability as an SLA issue.

Is that the best way to comprehend the issue, or even to characterize it, though?

If one looks at the use of SLAs in other contexts, they are sometimes part of commitments within companies—when, say, the marketing department has IT implement a new system, IT guarantees a certain level of availability. More commonly, though, SLAs are part of outsource agreements, where a company selects an external provider like EDS to operate its IT systems.

And certainly, there's lots of attention on SLAs in that arena. A Google search on "outsource SLA" turns up pages of "best practices," institutes ready to assist in drafting contracts containing SLAs, advice articles on the key principles of SLAs—a panoply of assistance in creating air-tight SLA requirements. A Google search for "outsource SLA success," unfortunately turns up nary a link. So one might assume that an SLA doesn't necessarily assist in obtaining high quality uptime, but provides the basis for conflict negotiation when things don't go well—something like a pre-nuptial agreement.