The Greatest Risk to the Success of Cloud SaaS

CloudSaaS 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 underestimating 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.

Dan Twing is President and COO at Enterprise Management Associates. Dan oversees development and execution of strategic market research, consulting engagements for IT organizations and software vendors, and directs product development and marketing efforts. Formerly CEO of NetDelivery, a VC backed application software company, and Vice President of Financial Products for EDS' Electronic Commerce unit, Dan has over 25 years of IT industry experience in many facets of IT operations, development, product management, and marketing.
Follow Dan on Twitter: @dtwing

Kudos for you for recognizing that ” SaaS done right requires […] a culture of service and end user support, and software architecture ready to handle multi-tenant implementation”. That’s been our experience at Plex Systems, developer of Plex Online SaaS Enterprise Resource Planning (ERP) solutions for manufacturers.

Virtually every software company in the market today is offering some type of hosted ERP service and calling it SaaS. The problem is that the vendors don’t achieve internal efficiencies of true-multi-tenancy (note that even integrations need to comply with multi-tenancy). When you have an internally efficient SaaS model you can drop the long release cycles, you can work closer with customers to bring their enhancements into core and save them from paying for upgrades and migrations. The service culture is just as important. We did not collect a big chunk of cash up front. It takes years to recover our costs and if we don’t keep the product current, if we do not meet their needs, we will lose their business and their revenue stream.

Thanks for the kudos and thanks for pointing out that integrations should also comply with multi-tenancy.

It is an interesting dynamic that true SaaS has minimal up front costs and keeping the product fresh, the availability and response times in line, and providing good service is what provides the stickiness for customers. Too many licensed software companies rely on exit costs from large investments, long startups, and many customizations creating a huge exit barrier to keep customers around and paying maintenance fees.