The SLA's Burden on the EnterpriseThe SLA's Burden on the Enterprise
What businesses need to know and should watch for when signing a service-level agreement.
April 3, 2015
What businesses need to know and should watch for when signing a service-level agreement.
Moving to the cloud for UC is certainly in the news and blogs, and discussed often in white papers and webinars. It is not a bad idea, but is it a risk? The amount of risk is influenced by the Service Level Agreement (SLA) that is supported by the UC provider.
Moving to the cloud does have its benefits. It can be cheaper than an on-premises system. The enterprise needs less staff to manage cloud UC. Features can be offered to those enterprise users that need them rather than a one size fits all approach.
The enterprise is outsourcing UC function; therefore analyzing and understanding the SLA provisions are very important. Let's explore a number of factors that the enterprise should consider when contracting UC cloud services:
Read the Contract
Most CIOs are not legal experts. The contract (see Moving to the Cloud: The Contract) is written with the provider's view of what and how the services are offered. Read any accompanying documentation since the contract will most likely reference these other documents.
Listening to a presentation and signing the contract without sufficient contract review can be dangerous. I suggest you record the UC service presentation. This will provide credible information if the service delivery is not what the enterprise expected based on the presentation. I have also found that the presenter is more careful what is promised and what is omitted from the presentation when recorded.
When You Think the Availability SLA is Not Satisfied
If the enterprise believes that the availability SLA is not met, it should collect all the data required by the provider to apply for credit. When 99.9% is the provider's goal for availability, this translates into 8 hours and 46 minutes of downtime during one year of operation. This could be one long outage or many short ones. The SLA should also include the maximum length of time that an outage can exist in a month. Most SLAs will not specify a number. Ask your provider for their availability delivery for the last two years and how long each outage lasted. (Read "How Real is Cloud Data Center Sustainability?" for more information on cloud outages.) See the table below for a range of availability numbers.
Most enterprises do not know that there are a number of exclusions not counted in the SLA availability calculation:
Shut-down of the operating system
Loss of electrical power
Network and access loss
Time out for application software upgrades and fixes (can be 1–3 hours per month)
Preventative maintenance (hours per month)
When some servers must be shut down for new hardware installation
Complete server shutdown to install operating system changes or new releases
Change in VM location
Planned downtime
There may be more SLA exceptions, so look for them in the contract. You may actually experience closer to 99.5% availability when all the above conditions are included. This does not mean a cloud provider is delivering poor service. It does mean that there will be more outages than anticipated, and the enterprise cannot ask for financial credits for the excluded outages.
Meeting the Call Quality SLA
Call quality is measured using the Mean Opinion Score (MOS). MOS is numeric measure of listener satisfaction. The MOS ranges from 1.0 to 5.0 and is measured over the entire UC connection (a voice call) relating to voice quality. The provider SLA may not include the MOS. If it is included in the SLA, then 3.0 may be the specified MOS. This is a low MOS and will generate many user complaints. A MOS of 4.4 to 4.5 is what is typically experienced on the PSTN. A MOS of 3.7 to 3.8 is the quality of an average cell call. So an SLA specifying an MOS of 3.0 (which pretty easy to deliver) does not really mean much since most listeners will have some issues with this call quality.
If the contract does include an MOS delivery number, it should be closer to 4.0 rather than 3.0. I do not think there will many credits offered for calls delivering less than an MOS of 3.0. Do not look for credit for poor call quality.
Look for Different SLAs by Service
Another wrinkle with SLAs is that different parts of the service may offer different availability numbers. Voice calls may have a different SLA than voicemail. Email, IM, and chat may have a higher availability number than real-time services like voice and video communications
Further, the failure of one service may not be counted in the overall service SLA. The enterprise users could experience hours of voicemail downtime in one month. In the same month, there could be hours of downtime of video conferencing. Together they may exceed 9 hours (less than 99.9% availability) but since they are viewed as separate services, the provider can justifiably state that not a single service went down for 9 hours thereby excluding the combined outages from the 99.9% SLA requirement.
Other Considerations
A few other contract considerations are:
There may be a requirement that multiple VMs must be implemented for the SLA to be satisfied.
The migration time to move from a failing VM to an operating VM may not be included in downtime calculations.
It may be hard to prove that the failure is the provider's, not the enterprise or its users.
Watch for unilateral changes to the terms of service.
When beta testing a service, the SLA will probably not be supported.
Applying for Cloud Credit
The service provider may, at its discretion, automatically offer a credit. This has occasionally been the case, but it is much more likely that the enterprise IT staff has to collect data to apply for a credit.
For a claim, the IT staff has to collect and provide:
A detailed description of the failure
The length of time there was a service outage
Which locations were affected
How many users were affected
A description of the enterprise's attempts to resolve the failure
The claim for credit has a limited time window. Usually the claim must be submitted by the end of the month following the failure. You may then have to wait 45 days before you will be notified of the credit.
Is filling a claim worth the effort? Producing the claim is a distraction for the IT staff from their ongoing projects. The primary question is whether the IT staff labor for filing a claim more than offset by the credit received. To know the answer, the IT staff may have to complete the claim anyway to see if it is worth the effort. (See Getting Cloud Credit for an expanded discussion on cloud credit.)
Conclusions
Subscribing to cloud services is very popular. The enterprise moves from CAPEX to OPEX financing. New UC services are available. Someone else has to manage the UC service, not the enterprise staff. It is outsourcing to a cloud data center.
There have been many failures lasting hours in cloud services in the past few years. Impacted enterprises may have been given credits, but the credits will not cover an enterprise's internal costs, lost revenue, lost profits, and reputation. A good and fair contract can provide the C-level executives some assurance that subscribing to UC cloud services are worth pursuing. The enterprise staff has to perform their due diligence before agreeing to the contract provision covering the SLA.
