July 20, 2015

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:

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:

But traditional packaged software:

Thus, in most cases:

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:

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:

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

As for platform support:

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

Comments

6 Responses to “SaaS and traditional software from the same vendor?”

  1. Eric Seibert on July 21st, 2015 4:47 am

    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

  2. Curt Monash on July 21st, 2015 8:58 am

    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.

  3. clive boulton on August 9th, 2015 6:22 pm

    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.

  4. Notes on packaged applications (including SaaS) | DBMS 2 : DataBase Management System Services on October 7th, 2015 8:28 pm

    […] add that SaaS (Software As A Service)/on-premises tensions aren’t helping incumbent vendors […]

  5. Some checklists for making technical choices | DBMS 2 : DataBase Management System Services on February 16th, 2016 1:04 pm

    […] (If for resale) On-premises vs. SaaS. Or maybe not. […]

  6. Notes on the transition to the cloud | DBMS 2 : DataBase Management System Services on October 3rd, 2016 10:22 pm

    […] 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 […]

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.