Are We Lagging In SLAs?

Nearly 80% of the cloud service providers I have spoken with during the past six months have told me that they either have a set of very generic and general SLAs (service level agreements) in place for their customers or that they don't have any formally stated SLAs for customers at all, although they have internal operational standards that they strive to meet. On the other side of this equation, businesses engaging cloud services have also reported that, by and large, they simply sign and accept the contracts that the cloud service providers present to them, and go by whatever SLA representations the vendors make within the context of the contract. This begs the questions of whether SLA definition and adoption is lagging cloud services adoption—and whether it is OK if it does.

On the risk side of this discussion, when you begin to outsource applications to the cloud, your expectation is that you will receive the same service levels from these applications—for less. Normally, a service level expectation is in the form of uptime, throughput and the level of responsiveness the vendor promises. But there are also "untapped" areas of both the service provider’s contract and what’s not in the contract that sites should consider discussing with their cloud services providers before entering into an arrangement for services. This is why SLAs remain a relatively untapped area of cloud due diligence that mores sites can benefit from focusing on—especially if they are considering outsourcing mission-critical business applications to the cloud.

SLA areas likely to be missing or unclearly defined include:

Project Leadership

Who provides the ongoing leadership on the cloud service side and on the business side? Having the right project coordination between the two entities is as important as making sure that the cloud service is up, running and delivering value—yet sites usually miss this. What often happens is the cloud services provider puts its best person on the installation and cutover team for the service. Once the company is safely in the cloud service provider’s client fold, the client is notified by the cloud services provider that there will be a new project lead—and that new lead turns out to be not nearly as effective as the first lead.

Ongoing project and work coordination with the cloud services provider is a critical element of service delivery. If the day-to-day requests and projects aren’t getting completed and communicated effectively by the project leads, the viability of the entire cloud service is put at risk. An SLA can solve this issue before any contract is signed if the business insists that service levels will be measured in terms of project performance and responsiveness as well as overall service uptime and performance. The business should also stipulate that it reserves the right to interview and approve any new project manager from the cloud services provider before the provider unilaterally assigns one.

Security and Governance

Nearly every cloud services provider contract contains generic information on security and governance, but the real question for a would-be client is whether the level of security and governance that the cloud services provider intends to provide will meet the company internal standards. If this area is unclear from the standard language of the contract, the business should plan on sitting down with the cloud services provider to discuss company expectations in security and governance, and then draft this into an SLA.

Information Sharing

Cloud services providers, like other third-party vendors, routinely form business alliances with other companies--and they may be inclined to share your information with these business partners. Often, this can be to a company’s advantage, because it learns of other complementary services that it can benefit from. On the other hand, the company itself might want to be the one to decide who gets its information. This is a topic that should be clearly defined upfront in the SLAs.

Deconversion

Companies should understand their exit as well as their entry points into contracts with cloud services providers. This is a difficult psychological hurdle for many businesses. After all, when you are about to sign a contract with a cloud services provider that you have high expectations for, no one wants to dampen the occasion by considering that there might also be a time in the future when the two of you might need to go your own ways.

Unfortunately, these things do happen. If they do, then deconverting your applications from one vendor and trying to migrate them to another can prove to be extremely difficult. The reason is that your existing vendor is not likely to take the loss of a client easily. Deconversion projects can take a long time to complete, and they can be fraught with setbacks. This is what makes it important to address a set of SLAs for deconversion with your cloud services provider (should it ever become necessary) before signing any agreement. If you ever have to deconvert, you will thank yourself for doing this. "I never thought we would ever leave this vendor," one CIO of a financial institution shared with me recently. "But then, I didn’t know that they were going to be acquired by this other company that we had already determined we didn’t want to do business with."

SLA Reviews and Revisitations

SLAs should be living: documents, because your business and IT constantly change. This is one reason why sites contemplating contractual agreements with cloud services providers that include SLAs should also make it clear to vendors at the beginning that the SLAs will be measured and discussed in review meetings that occur quarterly, monthly, biannually or annually (whatever best fits the situation). At those times, SLAs may be modified and agreed to based upon changes in business conditions. Most vendors are receptive to this as long as the changes are within reason. The other benefit to ongoing SLA reviews is that it keeps everyone focused on continuous results.