Enterprises are attracted to the simplicity of SaaS offerings, which offload practically everything to the vendor, including compute, storage and networking.
This cloud computing model leaves enterprises to simply consume the product. But with such a heavy dependency on the vendor, enterprises need to make sure the service-level agreement (SLA) meets their needs.
Enterprises need to look into these key areas: uptime, support, customization abilities, security and compliance. Review these SLA best practices for SaaS offerings.
Uptime and support
Uptime is one of the most important aspects of a SaaS SLA, since even a small amount of downtime can negatively impact a business. Many of today’s leading SaaS vendors offer 99.5% to 99.9% uptime — with some caveats around planned maintenance in specified time windows. Some buyers feel these levels are too low, though the actual percentage often comes in higher than what was promised.
“Many top SaaS vendors, like Salesforce, publish their uptime on a public site or in a status dashboard in the app and consistently achieve far better uptime than the promise,” said Liz Herbert, analyst at Forrester.
Enterprises should be realistic about SaaS SLAs and “not waste time hammering on things that are highly unlikely, if not impossible,” Herbert said.
SaaS is designed to be multi-tenant and standardized — a concept that extends to its SLAs, too. Most vendors offer multiple tiers of support, with basic support included in the subscription. There also are premium options, but those tiers may not be as essential as they would be with a private, on-premises offering that requires more individual support. For example, if a SaaS tool stops working properly, it typically does so for all users. The vendor will be aware of the issue and work to fix it systemwide, so customers don’t necessarily have to alert their vendor the same way they would with a private service, Herbert said.
And if something does go wrong, it’s usually slow performance rather than unavailability. In that case, enterprises need to be able to prove it’s the vendor’s fault, not their own end users’ internet connection. In practice, a one-second outage can be serious if it terminates in-progress customer sessions and causes data loss, no matter how little. However, a five-second delay with perfect recovery may only be a minor annoyance and not an SLA violation.
“It’s a common mistake for procurement [teams] to treat SaaS like infrastructure hosting and argue about SLAs and penalties,” said Duncan Jones, vice president and principal analyst at Forrester. But the SaaS vendor agreement doesn’t involve the actual delivery, so enterprises shouldn’t expect to receive a service credit or refunds if their availability expectations aren’t met for reasons that fall outside the vendors’ purview.
Many enterprises question whether or not to customize SaaS offerings or how much customization to perform. SaaS products are typically designed to fit most use cases, and enterprises can deploy them right out of the box with little configuration. In some cases, enterprises can choose to tier SaaS products. For example, an educational institution may provide students with a basic version of Gmail but give faculty and researchers the same product with more capabilities, said Greg Schulz, senior advisory analyst at StorageIO.
When you look at a SaaS product, you need to consider what best practices it includes, as well as configuration options, Jones said. If you decide to add customizations — if the offering enables it — the SaaS product will require more configurations, and those must be applied to future updates.
“A fundamental [aspect] of SaaS configuration is that all such changes must carry over from version to version, unlike on-premises customization, which you have to redo every time you upgrade,” he said.
Additionally, SaaS vendors now offer platforms that are both flexible and extensible. For example, SAP provided advanced customization capabilities for SuccessFactors, its HR management service, through its SAP Cloud Platform. Enterprises should evaluate such platform options and weigh the costs, language support and customization abilities against a single SaaS offering. However, many of these choices often aren’t included as part of a SaaS SLA.
Security and compliance
Depending on your industry or specific enterprise requirements, you need to be careful about what data resides in a SaaS application. These requirements need to be part of the SLA, said Ed Featherston, technologist at Cloud Technology Partners, a consulting organization.
Enterprises should include audit and reporting requirements as well to validate that the SaaS app meets security and compliance standards. For example, if the data that resides in the SaaS app needs to meet Health Insurance Portability and Accountability Act compliance regulations, it is the enterprise, not the vendor, that is responsible for violations. Enterprises are always responsible for their own data.