(Warning: this is a long post. Only read it when sitting in a comfortable chair. Or a pool lounge, holding your CrunchPad.)
Two recent posts by Enterprise Social Software vendors Jive and Atlassian set up a huge debate amongst my fellow Enterprise Irregulars. Here’s the money-quote from Jive:
It’s not so long ago that it felt embarrassing to say the words “SaaS” and ” single-tenant” in the same sentence. For years, it’s been an industry mantra that it’s simply impossible to have a scalable SaaS business without multi-tenancy.
Multi-tenancy, the Holy Grail?
Yes, we’re talking about SaaS Religion. Jive CTOs Matt Tucker goes on explaining why Jive found single tenancy a better fit for their Enterprise customers. To which one of my fellow Enterprise Irregulars said (I am quoting from a private discussion group, hence will not use real names):
Color me sceptical. If you don’t have a multi-tenant architecture, you’re going to argue it isn’t necessary. That doesn’t make it right.
Oh, but they do… at least Atlassian tried multi-tenancy first:
We assumed (as was the default point of view at the time), that multi-tenancy was our only architectural alternative. We built Confluence Team Hosted in a multi-tenant fashion, and can share that re-architecting a traditional enterprise application for multi-tenancy was a ton of work…
Enterprise customers have different needs than small businesses and organizations. Especially around security. In recent times, security has been the single greatest concern for enterprise customers. No surprise then that a model which keeps the individual customer’s data completely separate from other customers, at both the application and database level, would be compelling here. Equally important to enterprise customers is the ability to integrate SaaS offerings with their behind the firewall apps, LDAP etc., as well as customize these applications with the same degree of flexibility they’ve historically had with their on-prem application..
Atlassian’s conclusion: using virtualization gives them the ability to emulate multi-tenancy from a cost and provisioning perspective without sacrificing anything in the way of customization, security, and control – so they moved to single-tenancy now.
Should You Care?
Are they right? Is there an absolute “right”? I don’t know… but I do know that it completely ticked off some of my EI friends, who believe multi-tenancy is the Holy Grail of SaaS. If it’s not multi-tenant, it’s not true SaaS. They brought very compelling technical arguments on why if you’re not truly multi-tenant, you’re cost structure goes awry, and with a higher cost base you won’t be able to offer a competitive service – case in point is SAP’s Business ByDesign: very promising, but so far a flop largely to architecture, tenancy related issues. So yes, the argument is convincing, I am willing to believe that true multi-tenancy is the most economical way of delivering SaaS. But does it really matter?
My problem with this entire religious debate is that it’s too vendor-centric: how to best build a pure-play SaaS business. But what do customers want? Do they really care about all this tenancy mess? Software is supposed to solve business problems, and what customers care about is the functional fit, innovation, IP embodied in the features it offers, not how it’s architected, and of course cost, security, availability. This is the business users’ thinking, while tenancy is strictly IT/ CIO issue only.
I tend to agree with another Enterprise Irregular, Josh Greenbaum, who says the current debate may be interesting for early SaaS, which is basically a web-based low-cost replacement for on-premise software, but it will lose relevancy as more innovative companies provide premium services, and will not be bound by the cost issue as much as by how much value-add they can provide:
Multi-tenancy vs. single tenancy is a cost issue. Cost is a commodity issue. Whereas, the (most interesting ) future of SaaS is not as a commodity play.
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.
Data Behind the Firewall: is this Still SaaS?
I’ll come back to Josh later, for now let’s stay with architecture / delivery issues a little longer. I asked the EI group about separating data and applications: if the apps are web-based but the customer data stays behind the firewall, is that still considered SaaS? And again, does it even matter what we call it? One concern I heard in response was latency.
Days after this discussion Zoho (exclusive sponsors of CloudAve) announced Zoho Office for Microsoft SharePoint, which essentially combines SaaS applications with on-site, behind the-firewall data management. No matter what we SaaS evangelists say, or what SLA’s, security and privacy guarantees the industry brings, the fact remains that resistance to allowing data outside the firewall is still strong at most large corporations. In Zoho’s hybrid model latency does not become an issue issue with office apps sending simple data back and forth. But this model would probably not work with more complex transactional systems where you have to update several databases while processing, not just in the end.
SaaS Apps Installed On-Premise… the End of the World?
So if you can’t separate the app from data, what’s next? Bring the entire application behind the firewall? For years I’ve heard unconfirmed rumours of a major SaaS player, in fact an industry icon having at least one major on-premise installation of their system, but it wasn’t until a few days ago I saw it in writing, by Bernard Lunn at ReadWriteWeb:
Anecdotally, even Salesforce.com, which is religious about being pure cloud, has deployed on-premise when the customer is big enough. But saying so ruins a good story.
Yes, it ruins a great story, it’s hard to gloat about the biggest SaaS implementation if in fact it’s not truly SaaS. But other than a possible transparency issue, I don’t see anything wrong with a SaaS provider offering on-premise installs for very large customers. This does not mean they should turn into traditional product or even hybrid companies: that would mean dealing with different versions, patches, upgrades, let alone support of customers on different platforms with their dependencies – running a product company has very different economics from a SaaS provider, and providing for both can be a real nightmare. But this is still an evolving market and SaaS providers need to cater for what customer demand is today, not what they envision it will be in a few years. Hence I think we will see more compromises down the road, be it data behind the firewall, on-premise installations,
vate clouds, appliances or other creative ways of meeting real customer demand.
Eventually with wider acceptance SaaS providers will need less and less of these compromises, and as they move up the value chain, the real differentiator becomes the value added services they can deliver, not what’s under the hood. To quote Josh Greenbaum again:
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?
We’ll get beck on the subject of what Josh calls SaaS 2.0 soon…
Update: What a co-incidence, fellow Enterprise Irregular Jason Corsello posted his related thoughts today: Is Your Vendor Really Operating “In the Cloud”? The 3 Most Important Questions to Understand About SaaS
Update #2: another Enterprise Irregular and renown SaaS authority Phile Wainwright chimes in: Pod-Scale vs Warehouse-Scale Computing, pointing out the contrast between Oracle’s pod-approach vs. Google building the absolutely efficient industrial power infrastructure of the future. Well, let’s see:
the future. In the meantime they get kicked out of enterprise accounts
for not budging to *current* customer pressure re. data behind the
firewall..etc. It’s all OK,Google Apps are a small droplet in the bucket,
they can afford losing those deals.
In the meantime who can blame Oracle for doing the “wrong thing” while picking up that lousy $750M revenue?