Before buying a cloud computing service, you evaluate it, test it, see it in action, so you know what it's supposed to accomplish for you, right? Well, a description of that functionality belongs in the contract. You'd be amazed at how many contracts simply state the cloud service's name without specifying what that service is supposed to do.
That's inadequate. A well-formed contract will describe the results you expect the service to achieve for you. If your contract merely says that you are buying the XYZ cloud service, you will have no recourse if the vendor repositions that service so that it no longer offers all the functionality you thought you were paying for. The vendor's argument will be that you contracted for the XYZ cloud service, and the XYZ cloud service can be whatever the vendor says it is.
One commonly touted benefit of cloud computing is that the services automatically update so that you're always using the current version and functionality. It's great that your IT staff doesn't need to continually update and patch the software running on your in-house systems because the cloud vendor does it all for you. But you can't just assume that all updates will be to your benefit. Standard cloud-vendor contract clauses regarding updates usually say something very one-sided, such as:
"We may change, discontinue or deprecate any element of the service, or change or remove features or functionality of the service from time to time. We will notify you of any material change to or discontinuation of the service offerings."
That changed, discontinued or deprecated functionality could be something that you're counting on, and maybe even the sole reason that you acquired the service in the first place. To ensure that you don't lose the expected functionality, the cloud contract should include language regarding your rights to decline an update if possible, or at least requiring the vendor to provide a specific amount of notice prior to discontinuing or changing any functionality of its service. The notification period should be in line with the time that it would take your institution to move to another service provider if necessary. Without such clauses, a vendor could effectively force you to shift to a replacement service at a potentially higher cost than you had contracted to pay.
Additional, important elements of functionality that can be easily overlooked when negotiating a cloud contract include:
Technical Access Requirements
How will your users access the cloud computing services? Have you standardized upon a particular Web browser or mobile device? If so, you'll want to protect your investment in the cloud service by contractually obligating the vendor to ensure that these access channels will continue to work. And require a specific amount of advance notice about any changes.
Application Programming Interfaces (API)
Let's say you've adopted a cloud service but kept some of your infrastructure in-house. There's a good chance you expended quite a bit of effort integrating the cloud and legacy in-house systems, potentially incorporating vendor-provided APIs. What happens if the vendor decides to change direction or policy regarding APIs? If you've negotiated contract language requiring provision of the APIs, you should be in good shape. If not, you could end up being forced to change your existing integrations or worse, as some folks are now facing due to the recent changes Twitter has made regarding its APIs.
All elements essential to your effective use of a cloud service may not be included in the base price. For example, some vendors try to place a cap on how much data you can store, with additional fees for any overage. To mitigate this risk, negotiate to have a sufficient amount of storage included in your base fee. If limits remain on your storage, negotiate set pricing for any additional storage that may become necessary. And given the trend toward price decreases for storage, it can be prudent to negotiate for a cost-plus model for additional storage fees.
Technical support is something that we often take for granted with traditional software, but many cloud vendors offer little in the way of such support. If you expect to need technical support, then negotiate for the contract to specify:
* The level of support to be provided, including the skill, experience, geographic location and primary language of support personnel.
* Which of your users can access support.
* The days and hours that support is available.
* The process by which support is accessed (phone, email, etc.).
* Error notification and correction processes, including escalation processes, and time frames.
Interested in learning more about cloud computing risk mitigation via contract negotiation and vendor management? Then please sign up for my seminar Contracting for Cloud Computing Services, Oct. 29-30, 2012, in Washington, D.C. I look forward to seeing you there.
Thomas Trappler is director of software licensing at the University of California, Los Angeles, and a nationally recognized expert, consultant and published author in cloud computing risk mitigation via contract negotiation and vendor management. For more information, please visit thomastrappler.com.