Cloud SaaS can be a cost effective and fast way to buy and start using software (see my top ten reasons to do SaaS). However, while cloud SaaS can be great when done right, it can be painful to use when done wrong. With the increasing interest, adequate bandwidth for delivery, and a marketplace ready to try SaaS applications, many traditional software companies are considering a SaaS option. The greatest risk to the success of SaaS is poorly done SaaS ruining the market by disappointing early adopters and creating a bad reputation for SaaS. I am concerned that traditional software companies, rushing in to a SaaS delivery model and under estimating what is required to do SaaS right, are the most likely to do SaaS poorly.
The greatest SaaS successes have been created to be SaaS from the ground up. The software was good, but the implementation as a service was also good. SaaS done right requires a lot more than great software. It requires a culture of service and end user support, and software architecture ready to handle multi-tenant implementation. This is why the early SaaS successes have come from companies with the sole mission of being a SaaS company. The software is designed from the ground up to be SaaS, and the company is organized to service end users and on-board and bill them easily.
Consider the demands on the software in a SaaS mode. The software must be architected to support multiple different groups of users. This can be done by running multiple instances of the software, or it can be done by architecting the software for multi-tenancy where many customers run on one install but have clear separation of their data and options to customize their specific configuration. While either mode can achieve the users’ goals, multiple instances can be an operational nightmare. Patching and upgrading all these instances, monitoring their performance, etc. can overwhelm operations. The effect on the user can be poor availability and poor performance.
Consider the demands on the operations in a SaaS mode. New companies need to be able to sign up and new users need to be added over time. The system needs to be self provisioning and allow users to self add and self help. Billing needs to be easy and likely credit card based. It should feel like a service and not like licensed software run somewhere in the cloud.
Consider the demands on the sales and support teams. Users are selecting SaaS for its easy startup. It’s not easy to make it easy. Extended support hours, call center technical and sales staff, online chat and email for sales and support are all required. Users will bring a myriad of desktop and mobile hardware, operating systems and versions, endless variations of potentially conflicting software. An organization built for end user support and a culture of customer service are critical to do this well.
Now consider a traditional software company with a successful application. They are organized to design and release great software. They are good at selling the value of their software, issuing patches and updates, and billing by seats, CPUs, etc. by invoice. They know how to support technical buyers, but are not structured to support end users. They see the trend toward SaaS, some customers and prospects may be asking about the option to do SaaS, and they covet the new revenue stream. But are they prepared to do it right?
Great software made for traditional licensing does not always successfully make the transition to SaaS. Sometimes this is because of the architecture of the software – it was designed for use by one group of users and not as a service for many different groups of users. Other times it can be a result of the software company, successful at making licensed software, but ill prepared to think like a services company. SaaS is a completely different mindset from licensed software. Companies that rush in without considering the architectural and cultural changes needed to do SaaS will struggle, users of these poorly conceived implementations will be frustrated, and SaaS will get a black eye in the minds of disappointed users.
Product managers need to be wary of being pulled across these lines. Buyers of licensed software or SaaS need to consider the roots of the product and how they intend to use it. If the vendor is a licensed software company in its DNA, they may not be optimized for delivering SaaS.
I am not suggesting licensed software companies should never do SaaS. I think they should and I think it can be done successfully. But it must be taken as a very serious new strategic direction. This can mean a wholly owned subsidiary, a separate division, or at least a separate team with its own budget, goals, and senior management. With separate staffing and hiring SaaS professionals, it can help in setting up a corporate culture of a service business, and thinking about the packaged software as an input to building the service business. From the perspective of the licensed software team, the SaaS team is a major client. The SaaS team can have a significant and special relationship with the product team for the packaged software and can make its own extensions and customizations. But to be successful as a services company, they need to be free from the demands of the packaged software side of the business. The same team cannot serve both masters (licensed software and SaaS) at the same time. The SaaS team must have the resources and freedom to set their own priorities and build their service business.
Traditional software companies that take the move to SaaS too casually will fail at SaaS. Enough such failures could put the entire SaaS model at risk. Users will naturally take a “burn me once, shame on you, burn me twice, shame on me” approach to SaaS. Licensed software companies need to wade into this new pond carefully or they risk polluting it.
