Getting to SLAs that are Meaningful

I stumbled into a blog thread yesterday that prompted me to add another SLA blog regarding the components and measurement of meaningful SLAs. Earlier this summer I posted two blogs on SLAs, a Part 1 and Part 2. SLAs could generate a multi chapter book. In the first one, I discussed the relevance of SLAs with your service and cloud providers and in the second one I discussed more about how to approach building meaningful SLAs. Today let’s talk about the components of relevant SLAs.

ITIL tells us a SLA is the Utility (service definition) + Warranty = Value. In simple terms, the Warranty should be composed of: Availability + Performance + Responsiveness.

* Is the Service Available when I need it?
* Is the Service Performing as I expect at this time?
* If it is not, I expect it to be back to this level, for this time in XX amount of time!

In these days of services and composite applications, SLAs have become more complex in aggregating the parts and pieces that participate in delivering a service. The Cloud and as-a-Service providers are gaining in popularity with business units – Why? Because they define and deliver a service and the business is frustrated with IT. Now I might suggest that your business counterparts may or may not be asking and receiving good Warranty’s or SLA commitments for the delivery of those services. Thus those services that escaped you may some day come back in house.

In the previous blog, I discussed identifying and categorizing services. I suggest keep it simple and straightforward.

* Revenue impacting, mission critical services required to be in business
* Quality of Service to external customers required to be in business
* Internal effectiveness – services required, but not seen by customers, to process the business
* Internal efficiencies – required internal services for productivity

Now I suggest defining the simple: Availability, Performance and Responsiveness expectations for each category and work to keep the services in each category as standard as possible. Thus, not all services are created equal and those in the Efficiency category do not require the same level of responsiveness as those in the first, regardless of a severity 1 incident. What is the priority, now comes into play.

Creating all services equal based purely on severity of incidents is what makes internal IT expensive and appear as a bottleneck to progress in the business and what makes external service providers look very attractive.

Now to answer the question in the title, which one matters. The Service is what matters and the incident responsiveness, performance and availability are objectives that comprise the overall service level. Monitoring all three of these objectives and driving toward real-time monitoring of the Service Health to avert service-impacting events is when the SLA gains relevance.

I view the ability to create an intelligent service model that monitors each of these three objectives as the must have starting place in today’s business environment. Those that then marry in business objectives regarding the value / volume of transactions processed are those that are performing true Service Management. Performance, Availability, Responsiveness and Business Transactions each indicate risk to the business of the affects of a service-impacting event and averting these events proactively in real-time will soon be the must have, versus nice to have.