SaaS (Software-as-a-Service) and all the other aaS’s seem to have exploded in the last couple of years. In my previous post, The CIO is Dead! Long Live the CIO, I briefly touched on the confluence of changes impacting the CIO and the IT Department. One of those trends is SaaS. Do you have SaaS applications in your environment? Have you embraced the changes SaaS brings? Exactly what are the changes SaaS brings?
First, let’s define SaaS. Gartner defines it as: as software that is owned, delivered and managed remotely by one or more providers. The provider delivers software based on one set of common code and data definitions that is consumed in a one-to-many model by all contracted customers at anytime on a pay-for-use basis or as a subscription based on use metrics. I think that states it very well. In short, it is multi-tenant software, that is usually billed on a PUPM basis, per-user-per-month.
What is not SaaS is traditional on-premise software that is now provided in a hosted in environment and billed on the PUPM basis. We were recently involved in a software selection process and had narrowed down the applications to three finalists. In the final presentations, I asked about their SaaS offering. “Oh yes, we have a SaaS, in fact, we offer on-prem, hosted and SaaS.” So I asked them to explain the difference, is it a single code base, is it multi-tenant? What it boiled down to was a piece of paper. The only difference in the three offerings was the contract and how much they charged for the usage. In fact, they charged more for their “SaaS” offering than their hosted version, even though they were identical offerings. Sounds like “cloud-washing” to me.
The SaaS model brings about many changes, but I would like to focus on just a few: the risk (contract), the financial, and the support. In the various SaaS contracts I have negotiated, I have found some common “issues” to be addressed. Some of these are common to contracts for other delivery methods but are accentuated in a SaaS model.
- Service Levels - It almost never fails, the first pass of the contract is either silent on SLAs, sometimes to the extent that the provider never has to make the application available, yet you still have to pay, or there is some wording like “we will deliver the application in accordance with the documentation” or they link to some website that defines the SLAs with no version control. In either case, they can be changed at any time without notification. All SLAs must defined and incorporated explicitly in the agreement.
- Payment and Disputes - This is another common issue, the provider reserves the right to revoke access to the system for non-payment period. You never want to get in a position where the provider can legally hold your data and therefore your business hostage. We like to negotiate in “good faith dispute” language that prevents them from revoking access if we have a dispute. We will include arbitration language to help settle the dispute after a specified time period (typically 120 days or more) of trying to otherwise resolve the dispute.
- Data - Be careful with this one. Be sure the agreement spells out who owns the data (YOU do), who can use the data (ONLY you), who is responsible for backups, disaster recovery and providing copies of the data (you should always have access to make copies of your data, and they should make backups and have a solid DR plan). Access to the data gets tricky at termination of the agreement as well, or in the event the firm goes under. Be sure to get language in the agreement that spells out how you will get your data in these instances and specifies destruction of the data at termination. Before moving on, another aspect of this that has bitten us, be sure you have language in the agreement that gives you immediate termination rights (and access to your data) in the event the provider gets purchased, especially if they get purchased by a competitor to your firm (yes this DID happen to us).
- Liability, warranties, and indemnification - Almost all providers that I have dealt with want to absolve themselves of any liability if they get breached and your data gets stolen. Read this language carefully and try to get the firm to assume the risk if they do not adequately protect your data. If they are not willing...walk away.
The financial impacts of the SaaS model can be difficult to maneuver. By using a subscription based service you are essentially moving costs from a Capital Item to an Operating Expense. As you go down this path, be sure your CFO and your Board understand this and are comfortable with the change. Some vendors are trying to resolve this through “cloud credits” and other types of agreements. I think the jury is still out whether those will help with this or not.
Another aspect of financial impacts could have actually been placed in the contract section as well. Because the SaaS model is typically a subscription based agreement based on some unit of measure (typically users, or employees) one of the advantages of this model is scalability. You, in theory, are only paying for what you use. Be wary, however, that most agreements allow you to scale up, but severely limit your ability to scale down, if they allow it all.
The final area we will explore in this post is support of SaaS-based applications. It is probably obvious, but using SaaS applications moves most of the support from your internal IT resources to the vendor. Your team will be limited in the amount of support they can provide. This is a change management effort not only with your end-users, but also with your staff. Your end-users will have to understand the limitations and be satisfied with the service levels negotiated and the amount of flexibility they have in the application. Your end-users should have a seat at the table in the selection and negotiation, so the fully understand the implications of using this delivery model. As much as possible, the support should align with your current support model. For example, if you provide support 24x7, does the vendor provide the same hours of support? Can anyone call support, or does it have to go through named support leads? In our case, our Tier I support is outsourced, so we have to be sure a 3rd party can initiate a support request on our behalf. Do you, Mr. or Ms. CIO have direct access to a senior level person that you can reach out to in an emergency?
As with many of the changes in IT, the SaaS model may also threaten your team. This may include your support team who is losing some element of control, but also your systems team who no longer maintains the servers for the application. Again, change management is key. Communicate, communicate, communicate the reason for adopting a SaaS approach to some of your application, reassure them of their role, and let them know, while their responsibilities may be different there may be opportunity to expand their role.
These are just a few of the many changes and impacts the introduction of the SaaS delivery model can have on IT. I would love to hear about some of the impacts you have seen or some of your thoughts on those I have shared. In the next post, we will explore how adopting this model impacts the relationship of the CIO to the rest of the business.
If anything you read here or in other posts strikes a chord, I would love to hear from you. Leave a comment
Jeffrey Ton is the SVP of Corporate Connectivity and Chief Information Officer for Goodwill Industries, providing vision and leadership in the continued development and implementation of the enterprise-wide information technology portfolio, including applications, infrastructure, security and telecommunications.
Find him on LinkedIn.
Follow him on Twitter (@jtongici)
Add him to your circles on Google+
Check out his previous posts and discussions