LinkedIn Twitter
Industry Analyst, Consultant and author, former programmer, systems analyst with 25 years experience. Spent three years in Europe as an industry analyst and as Correspondent for Information Week and other industry publications. Regularly consults with leading public and private enterprise software, database, and infrastructure companies. An award-winning columnist for leading IT and business magazines, Josh is widely quoted in the trade and business press and he blogs at Enterprise Matters.

11 responses to “Compatibility, The DEC Rainbow, and SaaS Multi-tenancy”

  1. Phil Wainewright

    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.

  2. Phil Wainewright

    A small slip in my reply – when I wrote “is it misleading customers” of course what I meant was “it *is* misleading customers”

  3. Naomi Bloom

    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.

  4. Joshua Greenbaum


    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.

  5. James Colgan

    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…)

  6. Single Tenant, Multitenant, Private and Public Clouds: Oh My! « SmoothSpan Blog

    […] of course Josh had to respond with a post that ends […]

  7. Single Tenant, Multitenant, Private and Public Clouds: Oh My!

    […] –  Josh Greenbaum’s assertion that Multitenancy is a Vendor, not a Customer Issue.  This post includes some choice observations like: […]

  8. David Bradshaw

    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.

    1. David Bradshaw

      PS I meant to say “big update” at the end of the first paragraph.

  9. Single Tenant, Multitenant, Private and Public Clouds: Oh My! » Welcome to

    […] –  Josh Greenbaum’s assertion that Multitenancy is a Vendor, not a Customer Issue.  This post includes some choice observations like: […]

  10. Single tenancy, the DEC Rainbow of SaaS « YallaGeeks

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