A Checklist for SaaS Vendor Accountability

InfoManagement Direct, October 10, 2008

Joe Ruck

There has been a lot of talk about software as a service (SaaS) recently, and companies seem keen to jump on the SaaS bandwagon for good reason: it’s a subscription based service, so if it doesn’t meet your needs or expectations, you can simply cancel the service. However, there is more to consider when selecting a SaaS solution than simply trading in your traditional enterprise software. Users have to consider SaaS from a legal and business practicality standpoint because by using a SaaS solution, you effectively outsource part of your IT and, in some cases, business processes, which were previously managed internally. This raises a number of considerations and also changes many aspects of the buying cycle compared to the purchase of installed, on-premise software.

In this article we will explore several of these considerations in detail:  escrow, service level agreements (SLAs), business continuity, privacy and relationship with IT.

Escrow

Enterprise software purchases often include an agreement to place source code in escrow - to be released if the vendor discontinues operations. The purpose is to protect a customer in the event that a vendor meets its demise.

Even in the enterprise software space, these escrow accounts have a number of problems. From the vendor’s perspective, they are in effect writing an insurance policy that by definition the vendor will not see enforced. The more serious problem is that, until the vendor is insolvent and the source code is released, a customer has no way of knowing if every important portion of the code has been included and is up to date.

Additionally, while escrow covers a vendor going belly up, it does not cover the more likely scenario that a vendor withdraws a product from the market or discontinues support. Still, given the relatively low cost of escrow and the common acceptance of it, a customer might rightly conclude it’s worth having.

All of the previous comments are applicable in principle to SaaS vendors, but there are also important additions that effectively nullify the value of escrow in any realistic scenario.

With on-premise software, if the vendor disappears, the system may continue to run undisturbed for many years on the customer’s site. Once the system has been in use for a while, the number of new bugs discovered tends to zero. With a running system in house, the customer can examine the escrowed source code at their leisure, fix any problem and compile a corrected version.

With a SaaS system, the system goes away the day the vendor does. There is no option to continue running while you get the escrow code and review it. In any SaaS business, a large portion of the value is related to the actual operation of the service. The customer has no responsibility for the servers, upgrades, integration or maintenance. In other words, once the escrow clause is exercised, the customer will be the recipient of the software application, but nothing else. Not only will the software have to be installed, first an infrastructure needs to be put in place. It is difficult to see that this would be desirable when a data migration to another vendor is the alternative.

Also, while the SaaS system looks very much like any other application to the customer, the vendor has a very different perspective as they will be running an operation geared to support many hundreds or thousands of customers.

As you may imagine, this is a significant investment and requires a lot of sophisticated software. As a general rule of thumb, for every line of code you access as a customer, there is an equivalent amount of code acting to manage the multitenancy environment. This systems management and support code is typically very closely coupled and leads to the obvious question, is this included in the source escrow? Also, what about installation instructions? Even with full access to the code, it would simply not be possible to create your own installation of a service like Salesforce.com without an enormous effort and specialized knowledge that is almost certainly not in escrow.

Take Away: With SaaS, there is no value in escrow.

Service Level Agreements

Most companies want to define the terms of service of a SaaS agreement and to also define expectations of service availability. In some cases, customers formalize these expectations into SLAswith penalties in place for nonconformance.

Customers find it difficult, however, to agree to the terms of a penalty clause that constitutes proportional compensation for loss of service absorbed as a business risk by the vendor.

Page 1 of 3.