End-user SLAs: Guaranteeing ‘real’ service levels

In a prior life, I was an emergency medical technician, volunteering my time with the local fire department and ambulance service. “What,” you are probably asking yourself, “does this have to do with end-user service-level agreements and outsourcing?” Let me explain.

In medicine, when an EMT assesses a patient, the most critical “metrics” used to determine health are the “ABCs” – airway, breathing and circulation. In other words, is the patient able to breathe, actually breathing, and is their heart beating (do they have a pulse)? If the ABCs are patent, then the patient is “alive,” and the next step is to proceed with additional diagnoses to determine the “root cause” (also known as “presenting complaint”) of the problem (get my drift?). Interestingly, the very first litmus test of the ABCs is to assess if the patient is conscious – if the patient is conscious and speaking, then by definition, the ABCs are patent.

For outsourcers, the process of monitoring the health of “patients,” otherwise known as the mission-critical services that your users depend upon, has generally been upside-down from the medical methodology described above.

Instead of first checking the overall “consciousness” (availability and performance) of an application from the end-user perspective, outsourcers were forced to monitor the state of elemental systems (networks, servers, databases, etc.), primarily because these were the only metrics that were commonly available. Often, these monitors would report “all systems green,” even if end-users were unable to use applications. This is analogous to an EMT checking breathing and pulse rates in a patient, and if they fall within commonly acceptable limits, declaring the patient healthy (even if they are passed out in the street!). The key metric that I’m talking about is becoming known as  “quality of experience,” or QoE.

As one might expect, when service-level management (SLM) came into vogue a few years ago, outsourcers asked to guarantee service levels focused on “speeds and feeds” when defining SLAs. This led to the all too common situation in which applications were unavailable or under-performing, and yet the service provider was unaware that a problem even existed (until the phone rang, that is!). As one might expect, no SLAs were generally violated, since the speeds and feeds that SLAs were based upon still showed “green,” even though the end-user QoE was in a brown- or black-out state. Further, since the management tools only provided a partial view of the problem, root-cause analysis was difficult, time consuming and expensive.

A key technical challenge lies in the ability to capture the real user perspective without resorting to piecemeal methodologies.  To continue down the path of SLA management based solely on monitoring discrete application components – and not capturing what the real user actually sees – makes the troubleshooting process much more difficult than it needs to be.

Recently, I have detected an SLM sea change, coming from end-users who are now demanding more meaningful SLAs as well as customer-focused service providers that are supporting or planning to support this model. Many of the management vendors in the SLM space have also honed in on this trend and are adding these capabilities to their products.

This is a significant change in traditional methods used to create and guarantee SLAs, and I applaud this customer-centric movement. Fortunately, much of the work that has been done in support of generic SLM principles applies to the concept of end-user SLAs; the primary changes have to do with how QoE metrics are gathered and reported upon.

If you are involved in the end-user SLA movement, or if your company has embarked upon an initiative in this direction (either as a service provider or consumer), I would be very interested to hear your experiences and plans in this area. I would also be very interested to hear from management vendors that support or are planning on supporting this trend. You may contact me via e-mail at mehr@enterprisemanagement.com. I look forward to hearing from you, and if I get enough interesting data, I will publish an update in a future column.