If It’s Not Multitenant, It’s Not Really SaaS

“It is important to differentiate SaaS from hosting or application management or application outsourcing. Because the SaaS/on-demand market is ‘hot’, many suppliers are rebranding their hosting or application management or application outsourcing capabilities as SaaS/on-demand. The core proposition behind SaaS/on-demand is the delivery of multi-tenant service from a remote location over an internet protocol (IP) network via a subscription-based outsourcing contract.”

If your hardware and software appliance is hosted in an infrastructure as a service (IaaS) environment like Amazon EC2 , can you call it software-as-a-service (SaaS)? If it’s single tenant, the answer should be no. Why? Well let’s look at what Salesforce has to say on their website about their multitenant kernal:

“Nearly 60,000 customers run on a massively shared infrastructure, which creates economies of scale not possible with single-tenant applications, whether they’re hosted on premises or with an ASP. “

“In a multitenant environment, you can quickly, easily, and cost-effectively create development, test, staging, training, and production environments with just a few clicks.”

“As the application load grows, the provider has to spend more time and money adding infrastructure and less time focusing on delivering new applications.”

“In our multitenant, cloud-based service, the development team can see which capabilities customers are using, both in real time and historically.”

“By discovering how those customers use the application, we can then turn these lessons into best practices for the community. “

Here are a few questions to ask to be sure that your so-called SaaS vendor is truly delivering a multitenant solution and not just trying to re-invent themselves as ABAA (anything but an appliance):

Charles, you have to look at this both from the producer (ISV) and the consumer (customer) perspective.

Having worked for a SaaS vendor that wasn’t multitenant, I can tell you first hand about the high costs to serve (which by the way was passed on to the customer in terms of pricing), difficult upgrades, and slower release cycles.

I started a discussion on this very topic in the SaaS group on LinkedIn http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=122612&discussionID=8431611&sik=1257776099870&trk=ug_qa_q&goback=%2Eana_122612_1257776099870_3_1 and got 44 responses. This is certainly a great debate. At InteQ, we could not agree more with the fact that SaaS = Multi-Tenant. Our application was built in this model in order to ensure that as our client list grew, we could still handle upgrades, enhancements, etc. due to the fact that the application was shared but the data is not. I believe that vendors who created their SaaS offerings in any model other than a multi-tenant are going to reach a glass ceiling. Instead of simply expanding the infrastructure to support a growing client list accessing the application, these vendors will have to expand their workforce to track which clients are on which version, upgrade each client one at a time, etc. Toting thousand of upgrades a year is a clear indication that the vendor is not running a multi-tenant SaaS.

I think it all comes down to the business model. Multi-tenant enables vendors to build a viable, long-term business and the resulting business viability (or lack thereof) should be a chief customer consideration.

If you can’t offer your service at competitive prices (too many boxes/overhead with customer-specific releases), or you can’t iterate your product quickly, someone will come along and build a better mousetrap. It’s software Darwinism. Even more important from the vendor’s point of view, if your architecture can’t scale cost-effectively to hundreds of thousands or millions of users, then why are you in business in the first place?

I agree with initial comment from Charles.
The debate of multi-tenant or not should not concern customers, and for sure not be part of SaaS definition. The SaaS definition should focus first on the characteristics of the service offered to customer:
– Quick environment creation
– Transparent upgrades for customer
– …

Multi-tenant architecture is probably more appropriate to offer these services (at least to control operations costs) but it should only be an internal architecture topic on SaaS provider side.

SaaS can be single or multi-tenant. Within multi tenancy there are several variations as well (shared schema versus separate schema for instance). There are terrible multi tenant implementations that are really just as bad as hosted solutions. I’ve also seen great single tenant solutions which meet all of your criteria (except multi tenancy). All of them are “saas” to the customer. Why? Because of the way they are purchased and consumed (not the base architecture).

I wrote the counter-point to this in my blog – SaaS has nothing to do with MT — that only applies to hosted apps. What you call SaaS (and hopefully your view got updated since 2009) is no more than hosted and the only who benefits from that architecture is the vendor – there is no benefit to the user, in spite of what vendors say about cheaper/better performance. the opposite is true — performance blows in MT vs ST.

We have had the same debate within our executive team for about 2 years. On the one hand, we offer our software for free but charge when people consume a lot of bandwidth. It could be said also that the charges are not only for bandwidth but for the use of the software as well. So are we SaaS or somewhere in between? http://www,jumpto.com