Multi-Tenant vs. Single-Tenant: SaaS Debate 1.0 Needs an Upgrade

There’s a debate raging again in the on-demand, software-as-a-service market that bears some curmudgeonly commentary. The essence of the debate — which I contend seriously needs to be upgraded to reflect the real future of SaaS –is whether multi-tenancy or single-tenancy is the true path to enlightenment in SaaS. My curmudgeonly comment is this: Neither methodology will matter in a few short years, because the SaaS market is set to evolve beyond delivering a “faster-better-cheaper” version of on-premise enterprise software into delivering significant value above and beyond anything that on-premise can deliver today. And once that evolution truly sets in (and the market’s DNA is recombining constantly in the service of this ideal) these tenancy debates — which are basically about the cost-structure of competing with on-premise solutions — will cede their primacy to debates about the premiums that SaaS 2.0 solution providers will be able to charge their customers. At which point the basic cost issues that are fueling the great Debate 1.0 will be off the table.

There are two basic characteristics about these SaaS 2.0 solutions that stand out. The first is that, by aggregating data, processes, connectivity, and stakeholders in the cloud, these solutions are able to provide functionality that was simply not possible in the on-premise world. Take landed cost estimates as an example. You can run a logistics application inside the firewall that will give you a landed cost estimate for your  widgets if you ask it, but as that application cannot possibly have access to the myriad data points in the real world of logistics (shipper costs, shipper performance, broker fees, customs costs and regulations, to mention but a few), it will return a number that is marginally useful at best.

Shift that same function to a SaaS 2.0 vendor like GT Nexus, and now you’re doing something you couldn’t do in the on-prem world: GT Nexus’ SaaS cloud acts as a clearinghouse for virtually every available data point from every possible stakeholder in the global logistics chain, normalizes those data, and makes them available to every eligible user or partner in the logistics supply chain.  GT Nexus handles the integration, updates, on-boarding, etc., and the customer reaps the benefit of a SaaS 2.0 service that couldn’t be replicated on premise at any price.

This model is repeated across the burgeoning SaaS 2.0 industry: E2open and Amitive have a similar function to play in the supply chain, collecting data and processes from all those “outside the firewall” partners and using the power of SaaS to provide a level of functionality and service well-above what on-premise ERP and SCM products can do. SmartTurn does this in the warehouse.  Panaya does this for the SAP upgrade market. Actio does this in the chemicals industry. The list keeps growing and growing.

The second reason why SaaS 2.0 stands out, and why the low-cost, cheaper-than-thou SaaS 1.0 debates will become increasingly irrelevant, is that SaaS 2.0 applications are a self-improving and self-appreciating asset for the customer, and not just for the vendor, the latter point being the essence of the value model of SaaS 1.0. This is an extremely important distinction, and one that bears consideration as we look to the‘s of the world for guidance as to the market’s future (which I believe would be a mistake.) A solution like any of the SaaS 2.0 examples above becomes more valuable to each individual customer as more customers sign up. Significantly more valuable. Because in every case the more customers are added, the more their industry knowledge, partnerships, connectors, and best practices become part of the common good that SaaS 2.0 can bring. If you’re in a trading or industry network environment like most of the examples above, your cost to add new partners, new customers and new best practices actually goes down over time as more and more companies in a given industrty are on-boarded and more of those companies’ technological challenges are met by the SaaS 2.0 environment,  and thereby become part of that vendors’ standard operating procedure. If you’re more in the services business, like Panaya, the more anomolies Panaya tackles in the customer base the more solving those problems become STOP as well.

And, just so we don’t miss the self-appreciating asset portion of this, as no SaaS 2.0 vendor charges more for self-improvement, a company’s investment in a SaaS 2.0 stands to provide greater ROI going forward, for no change in cost. If only all enterprise software worked this way.

So, I propose we move on to Debate 2.0: what is the value of SaaS 2.0, and how can more companies deliver this kind of functionality and get the market moving in a completely different and more interesting direction. Because I contend that SaaS 1.0 is going to become as interesting as debating the merits of one micro-processor over the other. There will be lots to talk about, but little that will be important to the buying decisions that end-users and customers have to make. To whit: why should I care if one commodity-level SaaS CRM vendor is multi-tenant versus single tenant as long as the SLAs and price meet my needs?

The answer is as relevant as Intel Inside is to running a desktop PC. As is the multi-tenancy versus single-tenancy debate. It’s interesting, but so 20th century. Sic transit gloria.

14 Responses

  1. […] for multi-tenancy instead of single tenancy on the public cloud.  Finally, Josh Greenbaum believes that the debate between single tenancy and multi-tenancy will ultimately be moot (though I have to […]

  2. […] It’s great perspective.  You can read Josh’s full blog entry here. […]

  3. Many interesting points, but I have to believe that the cost imperative of a multi-tenancy SaaS application will win the day when compared side-by-side with a single-tenant application. I agree that there may (will?)be applications that are better suited, for security and performance reasons, to a single-tenant model.

    If we are to look at history as a guide, when the PC and DOS/Windows were introduced, a key factor was the cost of both the hardware and software. Companies that could not match these costs, particularly the mini-computer market, disappeared.

  4. Very well made points. Seems to me that key words for SaaS going forward will be ‘collaboration’ and ‘community’, and this extends not just to providers of complementary data, but customers also. Think of the added value of the SaaS offering when customers come to rely on collaborating in the community for answers to their questions.

  5. […] tend to agree with another Enterprise Irregular, Josh Greenbaum,  who says the current debate may be interesting for early SaaS, which is basically a […]

  6. […] the more that stakeholders in a supply network sign on to the network. I’ve been a fan of this model of SaaS company for a while, as the self-improving, self-appreciating aspects of E2Open’s ELN provide a […]

  7. Josh,

    Really enjoyed the post. Where would you say a company like Compiere sits in all of this as an Open Source vendor of ERP? They have both an on-prem offering as well as a in the cloud offering (vis-a-vie Amazon).

  8. […] Posts Multi-Tenant vs. Single-Tenant: SaaS Debate 1.0 Needs an UpgradeOracle’s Fusion Applications Are Ready. And So Is the Go-to-Market Strategy. Now The Fun Can […]

  9. […] to cloud computing than deployment choice, or even hybrid on-prem/on-demand apps. As I’ve been writing a little obsessively, the cloud, particularly the Azure cloud, will reach its apogee as a platform […]

  10. […] the Gamification of the Enterprise BeginsMicrosoft Dynamics makes manufacturing a game, sort of….Multi-Tenant vs. Single-Tenant: SaaS Debate 1.0 Needs an UpgradeSAP Gets Transactional with In-Memory Database: Changing the Game for Oracle, IBM, and MicrosoftSAP […]

  11. […] real revolution of on-demand will be a combination of two factors: the first, which I’ve written about extensively in the past, will entail the development of new applications and services that simply could never be developed […]

  12. […] real revolution of on-demand will be a combination of two factors: the first, whichI’ve written about extensively in the past, will entail the development of new applications and services that simply could never be developed […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: