I am sitting in Workday’s 2010 Technology Summit hearing the pitch about the supremacy of multi-tenancy, and despite their best efforts, Workday’s rationales about this key piece of SaaS orthodoxy are coming down solidly on the vendor side of the equation, not the user side. While the benefits that multi-tenancy can provide are manifold for the vendor, these rationales don’t hold water on the user side.
That is not to say that customers can’t benefit from multi-tenancy. They can, but the effects of multi-tenancy for users are side-benefits, subordinate to the vendors’ benefits. This means, IMO, that a customer that looks at multi-tenancy as a key criteria for acquiring a new piece of functionality is basing their decision on factors that are not directly relevant to their TCO, all other factors being equal.
The “other factors” issue needs explaining. The reason vendors think multi-tenancy is so important is that it is the best way to guarantee a low cost platform for customers – today. The problem is that perspective is based on an early adopter view of the SaaS market that has depended on the initial successes of relatively few companies in a very nascent market.
Multi-tenancy promises to age gracelessly as this market matures – there’s a tremendous amount of innovation that is being thrown at the SaaS platform cost problem, from virtualization to in-memory databases to huge advances in hardware that guarantees that multi-tenancy will not stand the test of time as the sole guarantor of cost-effectiveness in SaaS platforms.
This is why I believe, from a customer standpoint, this multi-tenancy technological choice issue is secondary to the real question that customers should be thinking about: is the total package offered by SaaS vendor X – functionality, cost, TCO, lots of happy customers, etc. – competitive with the total package offered by SaaS vendor Y. Full stop.
While multi-tenancy might be one way in which vendor X competes, it’s an “Intel-inside” factor that is irrelevant to the customer’s ultimate decision. If vendor X can outcompete vendor Y without relying on multi-tenancy, then vendor X deserves to win. How the issue of tenancy works for the vendor should be of little nor no importance to the buyer – to me it’s like worrying about the quality of the rubber in my car’s tires. If I were driving a high-performance car on a closed race circuit, I might want to worry about the rubber in tires. Otherwise, the chemical composition of the tire is irrelevant compared to its cost and functionality.
This is the basis of my argument with Workday about the competitive differentiation they offer on the technology side, and it mirrors my problems with Netsuite’s positioning as well. Most of the main benefits of multi-tenancy – every customer is on the same version and is updated simultaneously, in particular – are vendor benefits that don’t intrinsically benefit customers directly. What benefits customers is the ability to have a low TCO and a painless upgrade process, none of which is the unique domain of multi-tenancy. It’s definitely possible for a single tenancy vendor and an applications hosting company to both offer low TCO and painless upgrades while eschewing multi-tenancy, assuming their technology and business models are up to it.
That latter point isn’t meant as a throw-away, and any company not offering multi-tenancy will have to prove that they are up to the competitive task. But nothing in multi-tenancy gives its proponents an unbeatable position, it’s merely one of many technological directions that were important in the early stages of the market but less and less important as the market matures.
Customers want predictable pricing, elastic infrastructures, and, of course, an IT department-free implementation. Multi-tenancy is just one way to do that, but it’s hardly the only way today. And tomorrow, if the history of innovation is any indication of where the SaaS market is headed, multi-tenancy will be an also-ran, and we’ll be arguing about the new orthodoxy. Whatever that may turn out to be.
Filed under: Uncategorized |
Enterprise Matters 
I’ve long believed precisely what you’ve written above, but felt as though saying it, or even whispering it out loud might somehow vex my family or result in me forced to wear a scarlet letter for the rest of my days. As a provider of a SaaS based supply chain solution for S&OP and Supply Chain Management, I have only been asked by prospective customers if we were multi-tenant on a handful of occasions, and each time, it was because the they saw it as an “anti-feature”. The side effects of multi-tenancy, in some cases, would drive demerit points (e.g. perceived security risks having private data co-mingling with other customer data in the same process space, lack of control over performance, among other things).
I might add that some applications are not well suited to multi-tenancy, as I learned at this years Salesforce.com conference. Applications built for frequent recalculations of complex analytics on massive data sets were “not a good match for the force.com platform”. Yes, I can see that.
All that said, I can see how some SaaS-Apps might have a value proposition such that optimizing the cost of delivery is the only way to be competitive and maintain reasonable business performance. In the end, customers have to see the ROI, and it’s the vendor’s job to deliver it under a viable business model.
“Applications built for frequent recalculations of complex analytics on massive data sets were ‘not a good match for the force.com platform'”… This has nothing to do with multi-tenancy and everything to do with what force.com was built for or rather was *not* built for.
Although multi-tenancy is not the only architectural requirement for technical and operational success, one should ask why a vendor is not trying taking advantage of the obvious benefits and efficiencies?
Ali – are you suggesting that multi-tenancy is an “architectural requirement” for technical and operational success?
Yes I suspect force.com was designed more so transactional oriented applications rather than analytics intensive ones – good point.
The point I am making above is that multi-tenancy can have negative side-effects to the customer you’re serving as well as benefits. The experiences I’ve had in the field with mega corps and their supply chain needs thus far has led me to believe that multi-tenancy is less of a benefit to them than would be consistency of speed, and data security. Satisfying your customers needs is one good reason not to compromise your solution for what is “mostly” a vendor benefit and efficiency.
BTW – we have, and continue to study improvements in the SaaS delivery model led by inputs from some of the worlds greatest technology and A&D companies in the world. One thing is for sure -t here is still boat loads to learn!
Hallelujah Josh, I’ve been arguing this for years but SaaS “purists” are like Tea Partiers…you can’t sway them with any kind of rational argument that conflicts with their myopic world view.
Josh,
I don’t take as extreme of a view as you do. Is this solely a vendor issue, I would respectfully say no. I really feel that this is a customer issue and a vendor issue. Am I saying multi-tenancy is the only way to go? No. But customers should know the tradeoffs by not having multitenancy. Customers need to know how a vendor’s architectural decisions could impact:
Future pricing models
Business flexibility
Business Technology value
If a vendor can deliver multi-tenancy, it most likely can deliver on any range in the cloud spectrum from on-premises, hosting, multi-instance, and multi-tenancy.
The only vendors who make this argument, do not have multi-tenancy and realize that they need it. But in the meantime, we see a lot of denigration of those who have built multi-tenancy as those same vendors rush to build for it. A bit hypocritical in my mind.
Here’s a way to look at the tradeoffs and benefits:
http://blog.softwareinsider.org/2010/03/22/tuesdays-tip-understanding-the-many-flavors-of-cloud-computing-and-saas/
Cheers
R “Ray” Wang
Founder, Software Insider
I agree with Ray – there are pros and cons to multi-tenancy, and customers need to decide where to apply their preference for a given value proposition. Being a Salesforce.com user, I’m glad they’re multi-tenant, and am paying appropriately for the service I expect. Not all applications, or to be more specific, not all applications for specific markets fit the multi-tenant mold easily.
Customers may value speed of analytic computations first and foremost, or data security (perceived or otherwise) and would not accept the overhead of multi-tenancy if the result was poorer performance. In the end, a single-tenant SaaS application does not mean it’s “bad” or “impure” if it is delivering expected value for an expected price.
Ps: Ray’s blog post linked above is just about the deepest dialog on the subject I’ve read.
Thanks Ray for your thoughts. I agree that multi-tenancy has many advantages, but it’s not the only criteria for judging SaaS success from either a customer or a vendor perspective. And there are definitely SaaS services that can benefit from a single tenant model: extended supply chain or logistics management services, or anything that is delivering value-add in the form of an online business network, don’t need a multi-tenant model, IMO.
Multi-tenancy is only one of many delivery models, and in fact many proponents of multi-tenancy can’t offer on-premise solutions, something I think is an important option for customer choice. Which in the end is really what I’m advocating for here.
Fully agree re: choice, this has always been my problem with SaaS-only approaches. I’ll disagree about on-premise as I believe advances in virtualization will eventually kill on-premise deployments for all but the most strategic and/or security-required apps (e.g., money laundering/fraud detection, terrorism stuff). In Ray’s nomenclature, “multi-instance server virtualized” is a solid middle ground between the two models. There are no potential co-mingling of multiple data/instances or forced upgrades as multi-tenancy typically dictates. And there is the cost benefit managed infrastructure.
I’m sorry Ray and John Rhymer (via) Twitter, I agree with Josh. I see multi-tenancy “aging gracelessly” as Josh says. It is yet another example of managing from scarcity. Squeezing more cycles out of existing hardware with all the attendant downside (for customers).
Neil Raden
Hired Brains
Actually, clients will need a wide range of deployment models, a.k.a. choice (on-premises, hosted, multi-instance, multi-tenant). unfortunately, economics may keep that option away from many clients. If you look at the funding for most startups they are multi-tenant SaaS, no sql database, doc based approaches. Not sure what that means right now, but finding enterprise apps resources for development will become harder and harder in the older models.
R
This is an interesting discussion about how vendor enterprise architecture in the cloud may or may not be important to clients. In the cloud, no one knows what architecture you have. (Variation of no one knows that you are a dog on the Internet.)
There has been a lot written about enterprise architectures and vendors are quick to promote architectural advantages. You are right here because the further we get away from TCO & functionality – where the “rubber hits the road” for clients, the more we get into almost metaphysical discussions of “potential” TCO & functionality. Effective architecture is seen as future proofing but it is a third order benefit. (Second order benefit is feature sets you don’t need now, but possibly might need.)
Vendors can get a little too enamoured with the architectural trend of the day. This noise can distract us from what is really happening in the industry:
1) Most enterprise software solutions, regardless of how deployed, have dated technology surrounded by a web veil. This has a TCO implication for on-premisis hosting and increases cloud vendor costs to support. Multi-tenancy is but one of these vendor problems that can result in cost transfer to clients.
2)Most enterprise software was not designed to deploy via the cloud. The value chain from vendor to client has required the integrator as intermediarry to customize. Workday, NetSuite and Salesforce ought to be talking more about how the initial and on-going customization costs are reduced or eliminated through their architecture. Again, TCO as you have pointed out.
3)The choices that Ray has pointed out means that clients can deploy in many different ways. This is where the effect of open source becomes and important consideration if only for on-premises.
4)Web 2.0 has hit the design of transactional software. This was highlighted in many of the tweets from the Workday analyst session, primarily from Ray. This integration of collaboration and content requires design at the technology platform because bolting on a Twitter feed is not Enterprise 2.0.
Many of my points are also third order benefits to clients. Except for one special category of client: government hosted shared services. This is the scenario where a government organization hosts multiple departments, agencies, ministries, municipal governments etc. External cloud services are not applicable for most governments for financial (security reasons) and human resources (privacy reasons) data. Centralized agencies in governments that provide hosting services need to be concerned about the software architecture because it affects the government TCO – which, effectively, is citizen TCO.
Of course, the difficulty with many government hosted shared services is that traditional enterprise software, not designed for this deployment model, is often used.
Doug Hadden
FreeBalance
[…] Enterprise Irregular Josh Greenbaum and I rarely see eye-to-eye on SaaS and his assertion that multi-tenancy is a vendor, not a customer, issue — a supporting tweet called it the ‘Intel Inside’ of SaaS — elicited this […]
[…] Enterprise Irregular Josh Greenbaum and I rarely see eye-to-eye on SaaS and his assertion that multi-tenancy is a vendor, not a customer, issue â a supporting tweet called it the ‘Intel Inside’ of SaaS â elicited this counter-tweet from […]
[…] Enterprise Irregular Phil Wainright has commented on my recent post regarding multi-tenancy with a well-considered rebuttal that I believe deserves its own rebuttal in […]
Josh
Good Post!. Agree with your analysis on Multi-tenancy being ONE of the ways to implement successful SaaS offering but not the only way. Definitely should not be for a big consideration for the customer.
Ray, to your point of customers having to know the architecture – currently having Multi-tenancy is being routinely listed as one of the risks customer assumes i.e, that of co-mingling of data with that of their competition. I routinely had to defend Multi-tenancy against all such concerns in my prior job. I guess in the last part of your comment you are agreeing that – Vendors – definitely would like to go Multi-tenant (and are racing to get there) but not sure it is at the behest of their customers.
Most of you proposing the Multi-tenancy here are just talking about TCO as the benefit. But if you look at the rate at which Cloud Computing is bringing down the cost of infrastructure, going forward, the argument will be less of TCO. So what else are the benefits of Multi-Tenancy to the Customer?
One of the key drivers, for SaaS vendors, to go with Multi-Tenancy, besides economies of scale/TCO, is the potential pot of gold that gets accumulated with aggregate data across tenants. Conventional thought has been the data resides in a single db across tenant-owned-slices you could aggregate them and roll them up to create analytical models. Generating patterns, identifying trends and insights to drive high value analytics (descriptive & predictive) is going to be the future of Information Management. But that is now possible with massively parallel NoSQL technologies (Hadoop, MapReduce) even if data were to reside in multiple datastores.
[…] Josh Greenbaum’s assertion that Multitenancy is a Vendor, not a Customer Issue. This post includes some choice observations […]
[…] There was a spirited discussion of the end-user benefits of SaaS (for more information, see here, here, here, and here). I actually have a little sympathy for Josh […]
[…] the multitenancy debate rages on over on the Enterprise Irregulars site thanks to an initial post from Josh Greenbaum. I’m with Phil W. Here are my thoughts on the importance of […]
[…] now, it may look as though the choice between multi-tenancy and single-tenancy is something that matters only to the vendor. In truth, multi-tenancy matters even more to buyers, because it’s what makes the difference […]
[…] now, it may look as though the choice between multi-tenancy and single-tenancy is something that matters only to the vendor. In truth, multi-tenancy matters even more to buyers, because it’s what makes the difference […]
[…] so much on Multi-tenancy definition, pitches, spin (see more on that here, here, here, here), I decided blog about […]
Good post and comments, I agree with your view. I was tickled to see this throwaway “it’s an “Intel-inside” factor that is irrelevant to the customer’s ultimate decision” as I’m endlessly amazed by how irrelevant Intel Intel Inside is yet it has to be one of the greatest marketing/PR success stories in history.
You’ve no doubt heard Ma and Pa at the discount store quizzing the young sales guy about whether the object of their desire has Intel inside!!!!
So it’s not actually irrelevant, it’s irrelevant in fact but not in emotion where Intel have totally succeeded. Bizarre.
[…] is to a PC. Josh Greenbaum, from Enterprise Matters, disagrees completely, and says it’s really just a vendor issue. Meanwhile, Oracle’s Larry Ellison is trying to change the definition of cloud computing to suit […]
[…] proudly wear multi-tenancy as a badge of honor, rather than espousing the argument that it’s a side-issue that’s irrelevant to customers. But in their eagerness to put a check mark in the box, I do find that some vendors are inclined to […]
[…] now proudly wear multi-tenancy as a badge of honor, rather than espousing the argument that it’s a side-issue that’s irrelevant to customers. But in their eagerness to put a check mark in the box, I do find that some vendors are inclined to […]
[…] now proudly wear multi-tenancy as a badge of honor, rather than espousing the argument that it’s a side-issue that’s irrelevant to customers. But in their eagerness to put a check mark in the box, I do find that some vendors are inclined to […]
[…] or multi-tenancy was an issue for Software-as-a-Service (SaaS) applications. On the one side was Josh Greenbaum who argued that the type of tenancy should not matter to SaaS users; on the other was Phil […]