As more and more businesses turn to cloud services to replace on-premises applications, they must also negotiate service level agreements (SLAs) with cloud providers. Doing that job well requires that software architects and developers understand exactly what they need in terms of quality assurance (QA) testing, uptime and other core business functionality.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
But frequently, experts say, SLA negotiations tend to focus more on price and less on function and enforcement. QA, in particular, gets short shrift.
"All too often, they haven't thought about which things are really meaningful ... especially in test coverage," said Matt Johnson, chief marketing officer of Southborough, Mass.-based testing provider uTest. That misstep is particularly common in smaller businesses with less in-house development experience and fewer staffers.
Getting core business needs covered in SLAs for Software as a Service is especially important as many businesses new to cloud services adopt public-cloud applications. According to research by Gartner Inc., 71% of enterprises surveyed had been using SaaS for less than three years, but Gartner expected adoption to remain strong. In addition, 77% of enterprises using SaaS plan to increase their spending in that area, said Charles Eschinger, a Gartner research vice president. The SaaS market is expected to reach $28 billion by 2015, he added.
'Must-have' components for SLAs
Service-level agreements are legal documents, but if the company on the other side fails to live up to it, are they actually going to pay up?
chief marketing officer, uTest
In SLA negotiations, companies also need to know whether their SLAs are going to be enforceable based on who they're negotiating with and their location, uTest's Johnson said. "In a lot of outsourcing cases or offshoring cases, you need to know who's across the table from you," he said. "SLAs are a legal document, but if the company on the other side fails to live up to it, are they actually going to pay up? Are you allowed to breach the contract, or is it a fluffy document that makes the lawyers feel good?"
In most cases, companies should try to get the same type of SLAs that they would seek from any other software vendor, hosted or not, said Jed Mullins, a New York City-based technology licensing attorney. "I have had clients who are SaaS providers, and their SLAs are what they are. They don't really vary," he said.
That said, a basic SLA should include uptime guarantees, removing scheduled downtime from that calculation along with credits, which are the biggest remedy SaaS providers and software vendors are willing to provide, Mullins said. "Anecdotally, the credits tend to not be that much. The system would really have to be down for a long time and meet the definitions of downtime, not scheduled downtime but downtime counted against uptime to receive credits," he added. Mullins also incorporates language into SLAs to capture ongoing or persistent issues.
Considering potential Internet and cloud failures
Overlooking the network availability can be a risk to companies, because if the network isn't available, the application certainly won't be, said Tom Nolle, president of Voorhees, N.J.-based consultancy CIMI Corp. "The general rule is, if the Internet rate of failure is some value, [for instance,] X, then it's not going to do you very much good to try to improve the cloud application availability beyond that point," he said.
The main difference between Internet failure and cloud failure is that the former may be frequent but transient, but the latter could last a long time – and it is the kind of failure that companies worry about, Nolle said. "That's where escalation comes in," he added. But companies that try to include an SLA provision that absolutely guarantees a low failure rate may find that the cloud service would be more expensive than creating their own data center, he added.
"The goal [in escalation] should be to create an embarrassment factor," Nolle said. Most managers don't want senior management to know about failures, so in an SLA, provisions for escalation can include a statement about how far up the corporate food chain will go if the issue isn't resolved in a specified amount of time. "Escalation is a reasonable substitute for financial penalties that will get you want you want most of the time without exposing you to significantly higher prices," he said.
Finally, the SLA should include an expectation that the SaaS provider will take some proactive action toward mitigating potential outages. "In almost all cases where problems were occurring with cloud-delivered services, there was a period of as much as several hours of visible degradation," Nolle said. The SLA should include provisions for remediation processes, such as reporting to a field technician, when either the service provider or the company begins to notice degradation, he said.
The worst things that companies can do in SLA negotiations are failing to learn the commonly accepted terms used in some agreements and trying to incorporate a provision for "consequential damages" so that the service provider is liable for business losses, Nolle said. In reality, "nobody’s going to accept consequential damages. As a result, if you attempt to put them in, you're going to advertise to the other party that you're an amateur."