That works out well for the cloud providers, but not for their customers.
Worse, many cloud providers’ SLAs are “cupcakes,” extremely weak and nearly worthless. In some cases, it can take a catastrophic outage of immense proportions for any remedies to be invoked (and the remedies aren’t so great either!).
You probably can’t negotiate changes to every cloud SLA, but you should at a minimum understand each SLA’s potential impact on your business. To assess the strength of your cloud SLAs and their inherent risks, compare them to these SLA elements:
1. Acceptable performance. This item specifies the minimum level of service that must be provided, and it answers the question, “What do we want from the provider for this particular service” It flows from and is directly related to the customer’s objectives under the contract. In the cloud, many SLAs are expressed in terms of availability. For example, a SaaS provider may commit to an application availability of 99.5%.
2. Measurement period. This helps refine the time frames associated with the acceptable performance; it answers the question, “When do we want the acceptable performance” To continue the example used above, the provider may restrict the application availability to 99.5% of the time between the hours of 8:00 a.m. and 8:00 p.m. (in a specific time zone), Monday through Friday.
3. Exclusions and exemptions. In this section, the SLA lists the conditions or times when the provider does not have to meet the SLA’s acceptable performance. Since this section excuses the provider from performing, the list should be specific and limited. To continue building on the previous example, the SaaS provider may require an exclusion or exemption from meeting the acceptable performance during the measurement period for scheduled maintenance periods, because of equipment failure that’s not within the control of the provider, and when the customer uses the application in a manner inconsistent with the product documentation. This section tends to be the most egregious portion of the SLA — proceed with caution.
4. Data source. This component answers the question, “Where is the information coming from that will be used to measure the provider’s compliance” In many situations, a customer may have to rely on the cloud provider to provide the information; however, increasingly, there are third parties that can help the customer with this. In a perfect world, the data should be auditable by the customer to verify the data’s accuracy, reliability and validity.
5. Reporting period. We call this the “bite size.” It refers to the length of time that the customer will evaluate the provider’s SLA compliance. The reporting period answers the question, “How often will you determine if the vendor provided the acceptable performance for the measurement period” The reporting period component is a macro view of the time frame associated with the SLA. Our previous illustration can provide some context: The provider stated that the application would be available 99.5% of the time between 8:00 a.m. and 8:00 p.m., Monday through Friday (with some exclusions and exemptions); the addition of “measured quarterly” gives us the bite size.
6. Calculation. Many customers get themselves into trouble with this “how” element. The more specific you are, the better. Define the calculation with words and an equation with mathematical symbols. Ask for an example, and don’t forget to run the numbers. You might be alarmed at the reality of the calculation, especially if it doesn’t match up with what the provider told you.
7. Consequences. Lastly, the customer needs to know the answer to the question, “What if…” There are three possible outcomes, or “what ifs,” when dealing with an SLA: 1) the provider failed to meet the SLA, 2) the provider met the SLA, or 3) the provider exceeded the SLA.
If the provider fails to meet the SLA (Situation 1), the customer is harmed in some way and is entitled to be made whole in the world of contracts. It is often difficult for a customer to quantify the exact amount of harm suffered. As a result, cloud contracts typically contain a clause providing for credits in this situation. However, most providers are not willing to be at risk for their fees unless something catastrophic happens. This means that the customer bears most if not all of the risk. To assess the worth of the credit, you must understand how you will be impacted by an outage of various durations. If the provider meets the SLA (Situation 2), the provider receives the contracted payment; there is no other impact. If the provider exceeds the SLA (Situation 3), providers sometimes channel their inner “good for the goose, good for the gander” and ask for “reciprocity.” They want to be rewarded for exceeding the SLA, since they are punished for failing to meet it. A provider should only be rewarded if the SLA being significantly exceeded provides the customer with an additional benefit. Oftentimes, this is not the case. In our application availability example, consider the following: the difference between 99.6% availability and 99.5% availability as outlined above yields a difference of only 46.8 minutes of additional availability during the 91-day reporting period. What is that additional availability worth to you It’s hard to justify a reward for exceeding the SLA if there is no meaningful benefit.
Understanding these 7 SLA elements will help you evaluate the risk associated with your cloud contract. Since cloud providers attempt to limit your ability to negotiate SLAs, you must maximize your leverage and be creative to negotiate meaningful changes. The providers must put their fees at risk and have some skin in the game; otherwise, you keep all of the risk and the provider has no real incentive to provide the services outlined in your cloud agreement.
Phil Bode is the owner of Italex, LLC, an IT procurement consulting and training company; he can reached at phil@italexllc.com. Steven Jeffery is a senior consultant, IT; he can be reached at info@psmadvantage.com.
They are co-authors of the upcoming book Supplier (Vendor) Management – Going Beyond Strategic Sourcing to Gain Real, Sustainable Competitive Advantage, from which this article is adapted.