So you've heard how this great new thing called cloud computing provides benefits such as rapid deployment, flexible scalability and low start-up cost. Sounds like a no-brainer, and you should sign up without further ado, right? Sadly, it's not so simple.
Cloud computing serves as an umbrella term (no pun intended) encompassing software as a service, infrastructure as a service and platform as a service. The common thread here is "service," so one of the key issues to consider is the level of service that will be required to meet your needs.
The contract between a client organization and a cloud provider is the place to codify service-level agreements (SLA), including specific parameters and definitions for each element of the service provided, and remedies for when SLAs aren't met. Aspects of cloud services where SLAs might come into play include:
* Service availability
* Performance and response time
* Error correction time
* Latency
Let's do a deeper dive on service availability by way of example. Many cloud suppliers provide a 99.9% uptime SLA. That suggests that downtime for the service would be no more than 0.72 hours a month. That doesn't sound too bad, right?
Unfortunately, multiple factors come into play that can further increase total downtime. For example, what if your Internet connection goes down? You won't be able to access your cloud service, so availability is reduced, but the cloud provider isn't responsible.
You'd think something like service downtime would be fairly straightforward, but a quick review of some standard cloud contracts might change your mind. These contracts often define "downtime" so as to exclude any time that service is unavailable due to maintenance that was scheduled or announced in advance. Calculation of downtime might be restricted to a minimum number of consecutive minutes or a minimum percentage error rate. Downtime could be measured by spreading it over a specified time period such as a week or a month. Such clauses can collectively result in a fairly narrow definition of total downtime.
And pay attention to that scheduled downtime before you sign. If it conflicts with, say, your critical month-end processing, you could be in for a world of trouble.
SLA Remedies
Contracts should state specific remedies, such as corrections or penalties, for when SLAs aren't met. Corrections codify what steps a cloud provider must take to prevent a future failure to meet an SLA. Penalties often take the form of a financial credit, so it's important to codify when and how a credit will be provided.
A financial penalty could equal the pro-rated payment for any day's service where the SLA isn't met, or a set percentage based upon how far below the minimum SLA the service drops. Often, the client must proactively notify the supplier of a missed SLA in order to trigger the penalty, putting the burden on the client to monitor such activity. Penalties may be paid during the current cycle, or as a credit against your next renewal or purchase.
The goal of such penalties is not to get credits but to motivate the supplier to provide the required level of service. Other ways to motivate appropriate performance include reputational penalties (a full-page ad in The New York Times announcing missed service levels can be a strong motivator) and rewards for exceeding service levels.
Cloud computing is a new and evolving market, so don't be shy about telling your supplier what you need. The more clients that express the same needs, the more likely those needs will be commonly addressed.
We're all in this together, so be sure to let me know if I can help.
Thomas Trappler has extensive experience leading enterprisewide IT sourcing and vendor management initiatives and negotiations focused on cost savings and risk mitigation, with an emphasis on cloud computing contracts and software licensing agreements. Contact him at ThomasTrappler@gmail.com.