It is extremely difficult to succeed with SaaS (Software as a Service) and packaged software in the same company. There were a few vendors who seemed to pull it off in the 1970s and 1980s, generally industry-specific application suite vendors. But it’s hard to think of more recent examples — unless you have more confidence than I do in what behemoth software vendors say about their SaaS/”cloud” businesses.

Despite the cautionary evidence, I’m going to argue that SaaS and software can and often should be combined. The “should” part is pretty obvious, with reasons that start:

Some customers are clearly better off with SaaS. (E.g., for simplicity.)

Some customers are clearly better off with on-premises software. (E.g., to protect data privacy.)

SaaS should be easier for end-users than most traditional software, but …

… traditional software should be easier to administer than SaaS.

Further — although this is one difference that I think has at times been overemphasized — SaaS vendors would prefer to operate truly multi-tenant versions of their software, while enterprises less often have that need.

How this hard thing could be done

Most of the major problems with combining SaaS and packaged software efforts can be summarized in two words — defocused development. Even if the features are substantially identical, SaaS is developed on different schedules and for different platform stacks than packaged software is.

So can we design an approach to minimize that problem? I think yes. In simplest terms, I suggest:

A main development organization focused almost purely on SaaS.

A separate unit adapting the SaaS code for on-premises customers, with changes to the SaaS offering being concentrated in three aspects:

Release cadence.

Platform support.

Administration features, which are returned to the SaaS group for its own optional use.

Certain restrictions would need to be placed on the main development unit. Above all, because the SaaS version will be continually “thrown over the wall” to the sibling packaged-product group, code must be modular and documentation must be useful. The standard excuses — valid or otherwise — for compromising on these virtues cannot be tolerated.

There is one other potentially annoying gotcha. Hopefully, the SaaS group uses third-party products and lots of them; that’s commonly better than reinventing the wheel. But in this plan they need to use ones that are also available for third-party/OEM kinds of licensing.

My thoughts on release cadence start:

There should be a simple, predictable release cycle:

N releases per year, for N approximately = 4.

Strong efforts to adhere to a predictable release schedule.

A reasonable expectation is that what’s shipped and supported for on-premises use is 6-9 months behind what’s running on the SaaS service. 3-6 months would be harder to achieve.

The effect would be that on-premises software would lag SaaS features to a predictable and bounded extent.

As for platform support:

You have to stand ready to install and support whatever is needed. (E.g., in the conversation that triggered this post, the list started with Hadoop, Spark, and Tachyon.)

You have to adapt to customers’ own reasonably-current installations of needed components (but help them upgrade if they’re way out of date).

Writing connectors is OK. Outright porting from your main stack to another may be unwise.

Yes, this is all likely to involve significant professional services, at least to start with, because different customers will require different degrees of adaptation.

Comments

Very timely article for us. A number of early clients needed to run on-premise behind the firewall. So we added a packaged version that communicates with the cloud version if desired. The client can decide where to process the data (cloud or on-premise).

It occurs to me that I missed a nuance — the cloud service probably shouldn’t force users to upgrade to a later version than whatever is available on-premises. Otherwise movement and compatibility between on-premises and the cloud could be problematic.

Well — either that, or else you can’t truthfully market the possibility of easy movement back and forth between the two delivery modes.

[…] SaaS versions of a product. Release cycles and platform support are different in the two cases. But there’s no reason a large traditional application vendor couldn’t pull it off, and the largest are already more or less claiming to. Soon, this will feel like a market necessity […]