“Cause I’m Slim Shady, yes I’m the real Shady
All you other Slim Shadys are just imitating
So won’t the real Slim Shady please stand up,
please stand up, please stand up?”
- Eminem
Recently, there has been an amusing back and forth debate around what constitutes ‘real’ SaaS (Software as a Service). One side believes that if a solution is not multi-tenant, then it is not truly SaaS and is simply warmed-over on-premise software that is hosted. While the other side believes multi-tenancy does not matter provided you have a ‘modern application architecture’ (whatever that means).
This debate is silly.
It’s as pointless as debating: Who is more patriotic? Democrats or Republicans? Or who is more Californian? NorCal or SoCal? (each of these questions has a right answer by the way)
While multi-tenancy matters a lot in some situations (more on this in a minute), for someone to appoint themselves the arbiter for defining what is truly SaaS is self-serving at best (and delusional at worst).
Just like I do not necessarily know (or care) which production system is used by automotive manufacturers to produce my car, customers shouldn’t care about their SaaS providers internal operations and delivery methods.
Instead, they should care about the output/results (look for my upcoming blog post: ‘Do Your Customers Buy Toasters or Toast?’).
The Toyota Production System (TPS), enabled the company to eliminate waste, improve vehicle quality, increase model changeover/variety, etc. (all of which matter a lot as an end consumer), but I could not tell you how TPS compared to the mass production system pioneered by Henry Ford (actually, I can having been a design engineer at Ford for several years but that is beside the point).
Similarly, SaaS delivers certain benefits in terms of time-to-value, op-ex vs cap-ex, elasticity, seamless upgrades, etc., but I do not necessarily know if my solution vendor is employing multi-tenancy, continuous delivery, open source, or other tricks of the trade. (after all, I primarily care about the quality and value of the service I am paying for!)
So when does multi-tenancy matter?
In a fairly-defined market with predictable use cases and usage patterns (e.g., Salesforce Automation, Service Management, Procurement, Asset Management, Expense Reporting, etc.), multi-tenancy enables solution providers to realize a higher degree of efficiency. In these markets, if you are licensing infrastructure (e.g., databases) from a large software vendor (e.g., Oracle) and are not leveraging economies of scale (via multi-tenancy and other techniques), then you will find yourself at a distinct cost and market disadvantage and will be forced to either change or exit (as other automotive manufacturers were eventually forced to do with the introduction of TPS).
For new SaaS use cases that are compute intensive, highly variable/unknown in terms of usage patterns, targeted towards the late majority, and require high degrees of customization/configuration (e.g., production scheduling, supply chain planning, etc.), efficiency is not necessarily the name of the game. In these cases, customers’ may be willing to pay a premium for processing elasticity to handle their variable resource demands along with an assurance of data isolation given that concerns around cloud security probably remain (at least initially until widespread adoption and predictable usage patterns emerge).
Where to from here?
This debate around multi-tenancy is a slippery slope and serves no one (other than the two sides each of whom have their own interests at heart).
Does multi-tenancy mean resources are shared at the application level or does it only count if it is all the way down to the database level? What about use cases where it makes sense to share application resources but maintain data isolation (or vice versa)? What about newer SaaS applications such as Workday and Tidemark which have significantly different architectures than Salesforce (which has undergone a couple of rounds of re-architecting in its 14 years)? Are these solutions more ‘SaaS-y’ because they were able to leverage the lessons learned from those that preceded them? Do we really want to go here?
Instead of posturing around what constitutes ‘real’ SaaS (or not), software vendors would better serve their prospective customers by focusing instead on the inherent benefits of their solution and delivery model (a great example of this is Coupa which provides its customers with intelligence around their procurement metrics relative to other Coupa customers).
Do others find this debate silly and meaningless? Let me know what you think.
