SaaS and traditional software from the same vendor?
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.)
- On-premises customers want to know they have a path to the cloud.
- Off-premises customers want the possibility of leaving their SaaS vendor’s servers.
- SaaS can be great for testing, learning or otherwise adopting software that will eventually be operated in-house.
- Marketing and sales efforts for SaaS and packaged versions can be synergistic.
- The basic value proposition, competitive differentiation, etc. should be the same, irrespective of delivery details.
- In some cases, SaaS can be the lower cost/lower commitment option, while packaged product can be the high end or upsell.
- An ideal sales force has both inside/low-end and bag-carrying/high-end components.
But the “how” of combining SaaS and traditional software is harder. Let’s review why.
Why it is hard for one vendor to succeed at both packaged software and SaaS?
SaaS and packaged software have quite different development priorities and processes. SaaS vendors deliver and support software that:
- Runs on a single technology stack.
- Is run only at one or a small number of physical locations.
- Is run only in one or a small number of historical versions.
- May be upgraded multiple times per month.
- Can be assumed to be operated by employees of the SaaS company.
- Needs, for customer acquisition and retention reasons, to be very easy for users to learn.
But traditional packaged software:
- Runs on technology the customer provides and supports, at the location of the customer’s choice.
- Runs in whichever versions customers have not yet upgraded from.
- Should — to preserve the sanity of all concerned — have only have a few releases per year.
- Is likely to be operated by less knowledgeable or focused staff than a SaaS vendor enjoys.
- Can sometimes afford more of an end-user learning curve than SaaS.
Thus, in most cases:
- Traditional software creates greater support and compatibility burdens than SaaS does.
- SaaS and on-premises software have very different release cycles.
- 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.
That last point is key. The primary SaaS offering can be standard, in the usual way. But the secondary business — on-premises software — is inherently services-heavy. Fortunately, packaged software and professional services can be successfully combined.
And with that I’ll just stop and reiterate my conclusion:
It may be advisable to offer both SaaS and services-heavy packaged software as two options for substantially the same product line.
Related link
- Point #4 of my VC overlord post is relevant — and Point #3 even more so. 🙂
Comments
6 Responses to “SaaS and traditional software from the same vendor?”
Leave a Reply
Curt:
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).
Thank you for posting, will use it as a guide.
Best Regards,
Eric
Thanks, Eric!
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.
Perhaps of we can learn from Android / iPhone appstore distribution. Engineer multiple stage gate distributions with the platform for different licence models…
Internal test
Internal deployment
Partners
IT admins
Direct to customers
3rd party app developers.
Coda. I can’t see how Salesforce.com gets to double revenue from $5B to $10B w/o engineering for SaaS online and SaaS on-premises from the same development.
[…] add that SaaS (Software As A Service)/on-premises tensions aren’t helping incumbent vendors […]
[…] (If for resale) On-premises vs. SaaS. Or maybe not. […]
[…] 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 […]