Virtually every time a vendor gives me a briefing on their product or service they always smile and say “Jim, our product/service helps IT organizations meet their SLAs”. A lot of times I really struggle to understand how that product or service has any bearing on an SLA. Given how the term “SLA” is used and abused by vendors and industry analysts it makes me wonder: Do SLAs have any meaning and if they do, do SLAs really matter?
I want to start by distinguishing two types of SLA: the external SLAs that IT organizations get from a service provider, and the internal SLAs that IT organizations provide to their users. IT organizations have historically received a Service Level Agreement (SLA) from their network service providers. These SLAs are explicit in the sense that they involve a written document that establishes a set of objectives for the availability and performance of a network service. These SLAs also establish penalties to be paid by the service provider if the objectives for the service aren’t met. In most cases, the objectives are not very stringent and the penalties are modest.
In the last couple of years IT organizations have begun to obtain explicit SLAs from cloud providers such as Amazon. The Amazon Web Services (AWS) customer agreement states that AWS will use commercially reasonable efforts to make Amazon EC2 and Amazon EBS each available with a Monthly Uptime Percentage of at least 99.95%. If the availability is below that goal but above 99.90% the user of the service receives a 10% credit off their next month’s bill. If it falls below 99.90%, no matter how far below, the user receives a 30% credit off their next month’s bill. To me that reads like back to the future: objectives that are not very stringent and penalties that are at best modest.
So what about SLAs like this? Do they provide any real value? I do occasionally come across an IT organization that places a lot of value in them. The more common opinion I come across is that SLAs like this are better than nothing, but not by very much.
Starting roughly three or four years ago I began to notice a trend whereby IT organizations began to offer to their users an explicit SLA for a handful of key applications. When I asked IT professionals if it was difficult to determine which applications got an SLA the unanimous feedback was no. As one IT professional put it, “We know what we get beaten up about.”
Up to this point in the blog I have been discussing explicit SLAs. However, long before IT organizations started to offer explicit SLAs to their users there were implicit SLAs. Whereas explicit SLAs involve a written document that, at a minimum, lays out objectives for performance and availability, implicit SLAs are not written down. Implicit SLAs are based on the undocumented expectations of the users of the applications and services. If I were still running network organizations I would rather be evaluated based on explicit SLAs that I had a role in crafting than on the user base’s subjective opinions.
Whether they are implicit or explicit, historically the biggest challenge with internal SLAs has been implementing the tools and processes to ensure that the goals of the SLA are achieved. This task is complicated in the current environment by the fact that the typical IT infrastructure is a complex combination of devices including switches, routers, firewalls, WAN optimization controllers, intrusion detection systems, and intrusion protection systems. The ongoing adoption of mobility, virtualization, and cloud computing will only further complicate this task.
I recently participated in a Webinar that had roughly 150 participants. The system that we used for the Webinar allowed us to ask questions of the audience. One question that I asked them was “To which extent can you ensure the SLA of your applications — monitor, optimize and manage it?” The most common answer (45% or the respondents) was “Moderate — I can sometimes ensure and control my application SLA.” Under 5% of the respondents indicated that they can always ensure and control their application SLA.
So, similar to the question about SLAs from service providers: Do internal SLAs provide any real value? My answer has two parts: “Yes” and “But”. The “yes” component of my answer is based on the fact that when I talk to senior IT managers about the value of internal SLAs virtually all of them tell me that offering these SLAs has significantly improved the relationship between the IT organization and the company’s business unit managers. The “but” component of my answer is that managing these SLAs is very complex and getting more complex. As an industry we need to get better at this or else that improved relationship between an IT organization and the company’s business unit managers may disappear.