The real return to multi-tenancy is not just the returns of scale in terms of hardware, but of talent. Maintaining one instance for one customer is typically about the same amount of work as maintaining one instance that serves 100. Given that skilled DBAs, sysadmins, etc. remain costly, this can easily rival or exceed the cost of the hardware they maintain.

It is true that safely/reliably operating the 100-client instance will require more sophisticated operating practices, as the stakes for the vendor in case of a catastrophic failure increase. However, the returns to scale mentioned above more than cover the cost of this, while the improved architecture/operating practices are a benefit to all clients.

It is also true that single-instance (or traditional on-premise) models do in principle offer a marginally-improved level of initial customizability. However, my experience in both on-premise and multi-tenancy worlds leads me to believe that this advantage is not sustainable. Clients with one-off customizations either end up forking out large amounts to maintain the system, or find themselves falling rapidly behind the upgrade curve.

A related article I wrote a while back that your readers may find interesting: http://www.canidiumblog.com/2008/09/off-premise-solutions-lower-eim-spm-entry-bar/

If you can’t break it down technically, and furthermore, justify a particular preference for a particular purpose, you shouldn’t even be having this conversation. Otherwise, all you are saying is, “I think some kind of multi-tennant SaaS solution is best, but I really have no empirical or analytical basis for saying why.”

In discussions about the value of technology, the technology details really do matter.

We’ve created a longer response to your post on our blog as well, appropriately entitled, “A Half-SaaSed Approach Doesn’t Cut It.“

As for the value being passed onto the customer, just cause the cost of running might be cheaper for the vendor does that mean they have to pass the reduction onto the customer? Part of the ROI for a customer in a SaaS offering is ability to get new features etc without the whole upgrade process. This means the TOC is lower.

The next dangerous bit is the whole cloud discussion that vendors are starting to have. I have seen several vendor pre-sales consultants promoting their “utility based SaaS in the cloud solution”. The poor HR buyers have little chance of getting to the bottom of what they are really getting.

As the MS article (geared to developers to help build SaaS apps using MS technology) noted; different SaaS approaches typically appeal to different types of buyers/consumers. They use hotmail as one example of a Level 4 SaaS app. That’s fine. But it’s just a single-user email app.

When your SaaS app requires integration with outside applications such as Outlook, or other databases, or other applications, or other Web sites, job boards, etc.; things start getting complicated. Add in more user and corporate requirements for multi-level data security, workflow process control and other factors and you may find that the Level 4 SaaS app may not be appropriate to your needs.

In the final analysis, a Level 4 multi-tenant SaaS app may be perfectly adequate for a relatively small number of users with fairly simple needs. When the number of users and the complexity of their needs increases, a Level 3 or even a Level 2 SaaS deployment approach is quite probably the better solution over the long haul.

I’ve an article on the subject here: http://www.pointwing.com/Technical_-_SaaS_Software_as_a_Service_for_Staffing_and_Recruiting_Software_-_Part_1.asp

As to how vendors take advantage of cost savings, whether they return that to the customer (which I believe is more common than not) or simply offer a more robust environment, both relate to customer satisfaction and retention. Do customers want a low price at the expense of stability and service offering? Also, what is the cost of doing business with a vendor that has to spend time and dollars dealing with operational inefficiencies in lieu of better product development or quality control?

It’s true that this detail is less about business drivers and more about technology, but in the end, a sound technology platform with well-rounded processes removes a business hurdle related to vendor capability and trust. Who wants to do business with a partner that says “pay no attention to how we do that…”?

Are we saying that only non strategic software should be deployed in a SaaS model where the technology itself is not viewed as a differentiator since all level 4 customers are on the same technology train?

I believe the level 2 /3 models provide for a higher degree of customer control over feature functionality and therefore a better use of the technology for strategic differentiation from their competition.

The focus should always be on what is best for the customer and what do they want, not what is easiest to maintain or what benefits the service provider the most.

Also important is that some HR functions requires customization on a per customer basis. This imposes another level of complexity to shared resources solutions.