There are many items to consider before deciding to adopt a SaaS approach to your IT operation. Marcia Gulesian, a software developer, project manager, CTO, CIO, and author of numerous feature articles on IT, has captured the salient points in her article SaaS: Financial, Legal & Negotiation Issues. As the title to her article suggests, the financial implications should be addressed first. Gulesian has a very descriptive section on the differences between buying the software application and leasing it. She discusses the differences of owning an asset and its tax advantages of the deductibility of depreciation as opposed to the leasing option. There is a brief explanation of cash flows between the two alternatives, finding your opportunity cost, and making your determination on the comparison of the present values of the cash flows from the cost of owning versus the cash flows from the cost of leasing. Before we go too far afield, my readers can attest to the fact that I always try to define our terms before delving into the nuances that the subject line suggests.
Wikipedia’s definition of SaaS is very complete yet succinct:
“Short for Software as a Service, SaaS is a software delivery method that provides access to software and its functions remotely as a Web-based service. SaaS allows organizations to access business functionality at a cost typically less than paying for licensed applications since SaaS pricing is based on a monthly fee. Also, because the software is hosted remotely, users don't need to invest in additional hardware. SaaS removes the need for organizations to handle the installation, set-up and often daily upkeep and maintenance. Software as a Service may also be referred to as simply hosted applications.”
I also have a posting in this blog, which I must admit has become quite popular based on the number of hits registered to it, entitled SaaS is the Future. In it I discuss how a Managed Service Provider (“MSP”) can help software developers get their product to the market faster since the infrastructure barriers and capital expenditures are significantly lessened. In another posting about Unified Communications I have quoted Mat Taylor, a senior software architect with British Telecom, regarding the benefits of SaaS:
"The ability to get things done faster, get workers more engaged in a business scenario, provide better customer service, are all big productivity wins that benefit the bottom line"
In light of the above discussion surrounding “lower total cost of ownership and quicker time-to-value”, Gulesian cautions us that the other factors to include in the financial calculation is the maintenance and support fees that come with ownership as compared to the SaaS fees which includes these items.
SO WHAT DO I INCLUDE IN THE SAAS CONTRACT?
Gulesian points out three areas that must be addressed in the contract:
· Integration with your non-SaaS systems
· Loss of control of data
· Dependence on the provider for security
The CIO and his or her team are the main players to address the integration issue. Although the next two points also require the IT organization’s participation and input, these are matters that must be addressed upfront in the agreement itself.
Risk of loss of your data is paramount. In the event that the SaaS provider is unable to provide the support anticipated, it is essential that you have access to the applications as well as your proprietary data. Inability of the provider to provide support may happen for a myriad of reasons such as bankruptcy of the provider or a real or threatened patent infringement claim and subsequent injunction. The preferred approach to protect against such loss is to insist that the provider place its code into an ESCROW account. Language can be drafted which will instruct the trustee of the escrow ( an independent and trusted third party) to release the code to the beneficiary (i.e. you) upon the happening of certain events which are defined in the escrow language in your SaaS agreement. One shortcoming to this occurrence is the downtime that may be involved in getting your systems up and running, but this is a necessary protection that you must include in your contract.
Transition assistance is another item to consider. In the future you may wish to change the SaaS application currently in use. Language should be included to require the provider’s assistance in developing the data migration strategies and the procedures to be followed so you can move your data to another application.
Since the SaaS model is economical by nature (see Wikipedia definition above), traditional discounting expectations are not available. Pricing is based on users or seats. The more users subscribed, the more likely the cost per user can be discounted. So plan accordingly and try to build in volume discounting per blocks of users.
Other items Gulesian notes for inclusion in the agreement are:
· Service Level Agreements (SLAs) regarding
§ Availability
§ Response times
§ Notifications of outages
· Regulatory compliance
· Data integrity
· Data Privacy
· Frequency of backups
· Disaster Recovery
Gulesian’s article hits the main points and I highly recommend it to my readers.
fastest growing part of their business is middleware.
