Can a Traditional On-Premise Product Morph to Multi-Tenant SaaS?

I have worked with enterprise software products that were either single tenant on-premise or were multi-tenant SaaS services. There is no doubt in my mind that while many of us who have been in the industry 20+ year have worked with on-premise products, we became very comfortable with how to define, build, test, release, market, apply professional services, support and end-of-life these products. We all know of the positives and the negatives of enterprise software installed at a customer site. We are all very aware of the move over the past 5–8 years toward enterprise software being delivered as a service, across multiple customers. If you were to start a company today, there is no way you would build a traditional on-premise application.

Pros and Cons of Ejecting the On-Premise Product Model

In exchange for the nirvana of a multi-tenant SaaS product, you would trade in a number of sacred cows:

• Large up-front license payment in exchange for monthly subscriptions
• An easy model to motivate your field sales organization
• Very profitable professional services revenue stream including benefits of customization of the software for a specific customer’s need
• Simple data privacy story

In exchange you gain: (these are examples, not a complete list)

• No Proof of Concept (POC) time delays or costs in the sales process
• Lower customer cost of ownership through amortizing platform and upgrade time and costs
• Application scale–out to completely utilize underlying hardware
• Ability of customers to use OPEX instead of CAPEX for funding

The Big Debate at On-Premise Software Shops

This debate has been going on at traditional product companies for quite a few years now. I have been involved in many of these conversations and it reads like this. We have this great on-premise product with 10 years of investment (sunk cost) into all these 3000 features and 5000 test cases It’s a great product. We have thousands of customers and we know where they keep their spare change. There is so much more we can do with this product, but you know after 10 years we are getting tired of people asking us when we will offer the product as a SaaS services, so we should kick off an effort to figure out how to SaaS-ify our great product. Projects get kicked off and the product managers try to figure out what key SaaS capabilities are needed. Is this a time to pare down some of those 3000 features? What do we leave behind? The other camp in PM says why don’t we just create a service where each customer is on their own instance and we have a SaaS management plane (much like a cloud management platform, of course we want to build it ourselves). Still other PMs with a technical architectural focus think we can take the current product and over time SaaS-ify elements of it, meeting the true customer need over time. Still others — the enlightened few — believe it is time to completely start over and build a modern stateless scale-out microservices based application. The business leaders keep turning up the pressure for the SaaS version of the future. The engineering and PM team ground out in analysis paralysis. Aha, let’s do a quick pilot. Let’s get our best 20 people and build something fast.

If you are not laughing your behind off yet, you should be, as I and many of friends at other companies have heard all of this in multiple companies.

What is the Right Answer?

I am a pragmatist. I generally prefer evolution and synthesis over a great big idea. But in this case, much to my own surprise, my advice is that it is time for a radical change for the product team. If you double and triple click into the on-premise software factory and go to market and support models, an insidious malaise can afflict the patient. The technology stagnates. The factory tooling and processes stagnate. The people stagnate. Okay, I agree that I am being dramatic when I say this, but elements of that stagnation are visible in most teams. The whole DevOps trend is one of the ways the modern approach addresses this. The way to do this is to take 5–10 people from engineering, one PM, one marketing person and an operations person and with a six month goal with iterations every 3 weeks, build a new product in a SaaS model. This will mean changes in the technology stack, the requirements process, the backlog, the processes, how we market the product and how we operationalize the product. The feature set is small, and is not just a subset of the original product. It takes on new features and capabilities that were so deep in the backlog (this needs a new persistence layer, this one needs a new UI, that one will only work when the salespeople stop doing this and that…) that they can now be the differentiating feature of the product.

Organizational Challenges

I don’t have a 2000 word blog on exactly how to get there, but there are some obvious challenges the product and business leaders need to address up front. I will just point out some of the more interesting ones from the point of view of organizational dynamics.

• Who is the lead architect and what is the governance of those design choices and tradeoffs?
• What SaaS product feature needs to be there on day one? Who decides?
• Will we let the operational lead person get what they need baked into the product architecture?
• Who gets to work on the bright new shiny thing? Who is laden with the legacy and will they leave if we split the team?

No simple answers for sure, but much to discuss at the next Product Leadership Team meeting.

Originally published at fromchemistrytoclouds.com on August 2, 2016.