- Image via Wikipedia
Fellow 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 turn. Here it is:
As someone old enough to remember the DEC Rainbow and other also-rans, I enjoyed the trip down memory lane. However, at the risk of further disrupting Phil’s dentition, I think he was actually agreeing with me, albeit unintentionally, when he discussed Wintel compatibility and multi-tenancy in the same light. I think this is the perfect analogy for what I’m trying to say: single tenant vendors can be compatible with the promises of multi-tenancy in terms of updates, pricing, support, etc. even if they stick with their single tenant model, much like any vendor could build to the Wintel spec, and run Windows, without having to duplicate the IBM PC. Today’s Mac OS provides a nice example of Wintel compatibility, proving that it’s unnecessary to buy a Windows machine in order to run Windows. This is the model for my version of the multi-tenancy versus single-tenancy debate: Like Apple and the Mac’s Windows emulation, I believe single tenancy vendors can simulate the benefits of multi-tenancy without being multi-tenant, and thereby legitimately call themselves SaaS vendors without adhering to SaaS dogma.
Importantly, I think the pricing and services pressure of the multi-tenant vendors will force single-tenant vendors to make their offerings as compatible as possible. But as long as they are compatible with the promises of multi-tenancy, they don’t need to actually be multi-tenant to compete in the market. This is what opened up the PC market to vendors other than IBM, and it is what promises the best possible choices and opportunities for customer. How the vendors arrive at these best possible choices and opportunities shouldn’t matter to the customer, as long as customers get the price and performance they want.
(Cross-posted @ Enterprise Matters)
Josh, I think you are confusing the words “compete with” and “compatible with”.
And the example of Wintel compatibility on today’s Mac OS is a red herring. It took many years for the Wintel spec to be well understood – and for all the inconsistencies to be ironed out. Also it required Apple to make some pretty fundamental adjustments to its own architecture before it became reliable.
If vendors want to believe they can compete with multi-tenancy without being mulit-tenant, that’s their own concern. But is it misleading customers to claim that they are SaaS vendors.
Still, it’s an interesting marketing slogan you propose: “A SaaS vendor without the SaaS dogma”. Maybe DEC would have been more successful had they opted for something similar back in the day: “An IBM compatible without the IBM compatibility dogma.” History would surely have been rewritten.
A small slip in my reply – when I wrote “is it misleading customers” of course what I meant was “it *is* misleading customers”
Josh, This gets nuttier and nuttier. I can well understand that those vendors who have only single tenant software (as a result of their long history and giant installed bases) may approximate, move in the direction of, work hard at getting the maximum possible benefits of truly multi-tenant SaaS by subscribing and hosting their software with the maximum possible operational efficiencies. But approximating, moving in the direction of, etc. isn’t the same as being there to start with. Also, it’s not at all clear to me how single tenant vendors (1) support inheritance across and within tenants at the same cost/pain/error rates as true SaaS vendors (as in supporting zillions of payroll tenants with a single effective-dated set of the relevant meta data for income tax calculations (and please note that, in my world of HRM, much of the functionality is regulated and, therefore, benefits mightily from this type of inheritance), (2) support aggregation across tenants at the same cost/pain/error rates as true SaaS vendors (e.g. to produce benchmarks and/or to support pool data, like applicant data, with the permission of all concerned, and (3) crowdsource how their software is being used in order to identify the most needed new/different capabilities. I know that, if you write enough code, all is possible, but why on earth would you go down that single tenant path when writing new applications except for those few situations when single tenancy is really the right path. When I’m working with a legacy code base vendor, which I do all the time, I’m helping them to reap the maximum possible from the code they’ve got while funding the most rapid possible reinvention of themselves for a SaaSy world. So I get the marketing pitch about virtualization, privacy/security, and more. But in terms of the future, surely you’re not advising vendors — like the Workdays, Ultimates, SuccessFactors, Meta4, etc. — to build new single tenant products.
Naomi,
I don’t think it’s nutty to say that consumers of technology need not concern themselves with the technical aspects of how their vendors deliver solutions, as long as the solutions are competitive in total cost and functionality. What I do think is nutty is asking consumers to make their choices based on issues that I believe are vendor-related, not consumer-related. We obviously differ on this issue.
I am not advising vendors to go single tenant, I’m advising them to err on the side of customer choice. That includes offering on-premise versions of the their SaaS software, another breach of the SaaS orthodoxy, I’m sure. The bottom line IMO is that all the benefits of multi-tenancy should be part of a SaaS offering, but that multi-tenancy shouldn’t be the only way to offer those benefits.
A fascinating display of ping-pong! I must admit that early on I was much of a multi-tenant purist – the mathematics is too tantalizing. And if you’re just starting out developing a cool app – that’s definitely the way to go. Both Phil and Naomi state advantages of multi-tenant architectures that no one can argue with, it’s better all around. But unfortunately, business is not that clean cut. The purist approach of “multi-tenant or die” appears to ignore the impact of the transition for an existing ISV with all its legacy code, infrastructure, and revenue streams to deal with. And let’s not forget shareholders and the BoD! There needs to be a middle ground that can provide some of the advantages of the Cloud without re-writing a company’s balance sheet overnight. Keep in mind that for a consumer to gain value from a vendors software, that vendor still needs to exist and be financially viable.
Never has a dogmatic or purist approach to any new technology been relevant over the long haul. (Ask all those folks that thought the 68000 architecture running OS-9 was the “better solution”….it was! But who cared? Wintel won.) Look over your teller’s shoulder at Bank of America and you’ll see a DOS client running virtualized on WindowsXP connected to a mainframe…and it’s 2010! Traditional ISV’s are vulnerable to upstart SaaS vendors, and a single-tenant approach is a way to strengthen their position and provide added value to their customers. Will it immunize them against these competitors? No. Is it the ideal solution for everyone? No. Will it work? Yes. And that’s all we really care about. Having said all that, it’s only through these debates that the overall course that we’re on as an industry is improved and enhanced. Let the ping-pong continue! (I guess I need to post this over on Phil’s blog now right…)
[...] of course Josh had to respond with a post that ends [...]
[...] - Josh Greenbaum’s assertion that Multitenancy is a Vendor, not a Customer Issue. This post includes some choice observations like: [...]
I agree with James that there is a problem for many vendors to adapt their products to multi-tenancy. But for launching a new product (whether a completely new product or “bgi” update to an existing product, there is less and less reason to single tenanted.
You might say that multi-tenancy has no benefit to the customers, and in a very narrow sense, this is correct. You can get all the same benefits from single tenancy given the resources. But this does make things so expensive for the vendor, that the vendor cannot cost-effectively sell the service.
A real example is SAP’s Business ByDesign, which was initially written as single (or limited) tenancy with 1-2 user organizations per server blade. This proved far too expensive for SAP to maintain, and they ended up doing a re-write (and by the way fulfilling “Bradshaw’s Law” that it takes around two years to re-write a single-tenanted application into multi-tenancy).
Multi-tenancy many not be the only way to achieve these benefits, but it is the only way that has been demonstrated to work time and time again. SAP had the courage to go back and re-work their service – other vendors who try to offer large scale with single tenants will almost certainly have to do the same.
PS I meant to say “big update” at the end of the first paragraph.
[...] - Josh Greenbaum’s assertion that Multitenancy is a Vendor, not a Customer Issue. This post includes some choice observations like: [...]
[...] [added 03:07am Aug 27th]: Josh has responded to this post, and I’ve added a comment in reply to his post. Josh raises the intriguing [...]