In a recent article, "Cloud Providers Ready to Strike With Nuclear Option", Simon Phipps stated that issues related to cloud service level agreements (SLAs) are "under acknowledged and overdue for attention". If you are not already convinced of this, ask yourself the following question: "When is the last time you read one of the click through services agreements you are presented with when acquiring a personal cloud (or other) service?"
Come on, be honest. I won't tell anyone. If you are like most people, you have probably reached the point where you've spent so much time reading through agreements, and you've read so many of them, they are all beginning to look the same. (Many of them probably are the same.) And since it is just you and I having a confidential conversation you can tell me whether you have ever read any of them. Unless you are someone who deals with SLAs for a living, I would bet Andi Mann's lunch that you have not read one in a very long time.
Now, if you think those agreements are complex, imagine how complex SLAs related to large volume, high cost business services can be. And what is not in those agreements may be way more important than what is.
What do the terms "continuity" and "recovery" mean? What constitutes a breach? How long should it take to restore service? What options do you have if it is taking too long? Can you go somewhere else? Who gets to decide whether you can exit? How is "too long" defined? Can you have your data back? In what form and format? When can you have it? How will it be delivered? And what happens to your data, software, and systems if the provider becomes insolvent or subject to prosecution? What happens to your data if you don't pay your provider? Who owns your information and your systems then? Can your provider shut you down and/or permanently delete your data if you withhold payment? If you are thinking that is not a possibility... could it happen in the event you are having a dispute related to billing or service?
The Truth is Out There
Certainly these are worst case scenarios. But does that mean they are not worth thinking about? As I mentioned in my 2013 cloud computing predictions, cloud computing is beginning to mature. This year SLAs should be at the forefront, and if providers are preparing to strike with a nuclear option we might be in for a bit of an SLA cold war.
We need to bring the discipline and maturity that we already have in mainframe and distributed computing environments to cloud computing SLAs. To some extent that is the good news. Much of the discipline and best practice we need either already exists, or at least provides a running start. And it's not all about the SLA details. Though it may be obvious, it must be stated: your choice of service provider is critical. There are many very good ones. There are also more than a few not so good ones.
So, I strongly encourage you to consider Simon's advice, and add:
Choose a provider you can trust. Look for people you trust in key positions. Ask people in your network about their successful and unsuccessful relationships. Learn how the providers behaved when things went wrong. (They are all great when things are going well.) Learn how the provider responded when their customer was wrong or made a mistake. The last two will likely tell you much more than what is in their service agreement.
Know what you want. It is important to perform that second order thinking ahead of time.
Know what you need. It may be different than what you want.
Know what is in the service agreement. You might be surprised by the level of knowledge some people have regarding their service agreements. This is especially important when agreements are being inked by people with less negotiating experience (e.g.: they are not contract lawyers or procurement professionals). That is more likely to be the case in small and medium sized business. And if you have access to lawyers and procurement professionals, do not assume they will understand the operational nuances of the agreement.
Know how to engage. It is not only about the negotiation and the remedies. Someone needs to be familiar with how to identify a breach or issue, and how to engage the provider for assistance. Know what to do both in cases where the provider has an issue, as well as those cases where the customer has caused a problem.
Have an exit strategy. More than that, understand what would cause you to execute it. How long can something be down (or slow...) before it impacts your business? How long will it take to implement even a temporary exit? How will the provider help? How can you return to the provider's service (should you decide to) once the problem has been resolved? Who gets to decide whether you return?
Do not assume they will think of everything. In a previous article I mentioned a TED Talk in which Noreena Hertz discusses research that discovered that people shut down the independent decision-making part of their brain when they believed they were in the presence of experts. Your provider may think of everything, but do not assume that they will. It all goes back to, know what you need.
"Fallout Shelter" photo courtesy of stock.xchng
This blog is cross-posted at Pragmatic Cloud.You can follow @GeorgeDWatt on Twitter.