SaaS - Multitenancy Debates

There has been a really interesting discussion started by Phil Wainwright on Why Multitenancy Matters for SaaS companies...the latest post with a response from the Intacct CTO, Aaron Harris, is very enlightening. Harris points out that many of these decisions on infrastructure are made both on the technical merits but also with a strong emphasis on the impact to the economics of the SaaS model. It is worth a read.

Phil in his earlier post walks through the various back-end definitions of what a SaaS multitenant solution could look like. If you look at the 15 SaaS portfolio companies of Hummer Winblad you can see that we have a pretty strong religion on the approach that is best...this includes Intacct, Omniture and Aria Systems. The approach outlined by Harris - few instances of the back end and every customer on the same instance of the code - is the one where we see the best patterns for success.

There was also a post by the constant instigator, our own Dave Rosenberg, CEO of Mulesource (one of our portfolio companies and a regular ZDNet blogger). He argues that customers dont care. At the risk of setting off a fiery debate with Dave I will respectfully add some thoughts...that customers care because of the derivative effects of good backend choices.

Why customers DO care...

Market Leadership

Market leadership in a category can be a derivative of the efficiency of the SaaS providers organization. If you read the response provided by Harris on their multitenancy choices it boils down to economics. With a lean and mean back end infrastructure the SaaS provider has less administrators, less mixed hardware, less outages, etc and an overall lower cost to provide the service - do the customers care?

I would argue they do - most companies want to partner with the best companies in their category. The derivative reasons are a safer vendor choice, less risk of having to change later, often better pricing and usually a stronger product development capability.

Support

There is often a temptation for SaaS companies to bend to large customers who want separate notification and processes for upgrading code. If you play out this scenario for the SaaS provider you end up in a situation quickly where a few customers don't want the upgrade, or delay it by six months, or advocate for a different feature mix...and the small decision to allow different upgrade paths blossoms into a large subset of code versions across customers a few years out. I believe the saying is that if you let the nose of the camel in the tent and it wont be long before he is sitting beside you.

If you play out the scenario, every support call starts with the old software model question "what version are you running" and "was it Bob who knew how to deal with this"? This slows down support, diverts development resources to support and slows down the innovation at the company. Not good.


I don't expect all customers will start asking all these questions about how a SaaS company manages their back end infrastructure during the sales process...but I do expect them to make choices based on market leadership, support time, pricing, product development, etc.