SaaS Grows Up
Editor's Note: Learn more about effective SOA Governance in ebizQ's upcoming SOA Governance Virtual Conference.
Have you considered SaaS from a standpoint of legal and business
practicalities? 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 points that
require consideration and also changes many aspects of the buying cycle
compared to the purchase of installed on premise software. In this
article we will take a look at several of these aspects including:
- Service Level Agreements
- Escrow
- Business Continuity
- Relationship with IT
- Privacy
Service Level Agreements
It seems natural to define the terms of service, and with that to
also define expectations of service availability. In some cases,
customers seek to codify these expectations into service level
agreements with penalties in place for non-conformance.
It is difficult however, to agree to the terms of a penalty clause
that constitute proportional compensation for loss of service absorbed
as a business risk by the vendor.
It is misleading to compare the practice of penalty clauses in large
outsourcing contracts, since their vastly larger scope and size enables
realistic penalties to be absorbed. Also, there is typically a bonus
structure which offsets the penalty structure upon over-performance.
SaaS contracts may be only $20-50 per user per month, and this simply
does not provide sufficient margin to hedge against a reasonable
penalty clause.
The best approach is to review the vendors’ track record of
availability. Also, the customer should always have a back-up plan to
migrate to an alternate vendor or solution, should the service provided
not be acceptable.
Escrow
It is common for enterprise software purchases to include an
agreement to place source code in escrow, released only in the event of
the vendor discontinuing operations. The purpose is to prevent a
customer being orphaned if a vendor meets its demise.
Even in the enterprise software space, while common, these Escrow
accounts have a number of problems. From the vendor’s
perspective, they are in effect writing an insurance policy for 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.
1