Nice catch! The answer to your question is more subtle than I made it sound, mainly because I wanted to keep the original post short, or because I’m lazy. Your pick!

Anyway, the main reason has to do with the fact that a multi-tenant model forces the vendor to implement the layers of abstraction that will allow users to customize the shell of the application without having to change its kernel. With a single-tenant model, each instance of the application could be customized in very different ways, and it would be fine until the vendor has to make an ugrade of the application. Without a clean separation between kernel and shell, customization will be difficult to carry forward.

Another significant issue has to do with the way single-tenant applications are architected. In some cases, deploying two instances of the same application onto the same server is not possible, because of possible conflicts when accessing system-level resources. Not being able to host multiple customers on the same physical machine makes it much more expensive for the vendor to deliver the application to customers that have a limited number of users. The average Salesforce.com customers has 19 users, therefore being able to serve multiple customers from the same physical server is an imperative for serving such customers in a cost-effective manner.

Granted, you could work around this problem by using virtualization technologies such as VMware, but you would lose the economy of scale that would result for sharing some resources across intances, such as the meta-data repository for standard objects and some resource databases that might be used by the application (a lookup database for zip codes for example).

There are many other issues that would be worth mentioning, but I will let the experts pick it up from there, or write about it in a more detailed post later on.

I hope this helps!

Thank you so much for the introduction to BPX. I wanted to write a post on it, but it’s even better that you did it yourself. I really like the idea and wish you the best in your efforts to build a community of Process Analysts.

I hope it does. Another option would be to use Compiere. Both Salesforce.com and Compiere have been built to take advantage of the Oracle database, therefore deploying instances of Compiere onto Salesforce.com’s infrastructure should not be too difficult. Compiere’s user interface would have to be re-written to a large extent, but it might be the cheapest way for Salesforce.com to get where it needs to be, in the shortest amount of time.

No big announcements since it’s in sneak-preview mode, but it got great feedback during SAPPHIRE from small groups of ASUG members and 1:1 discussions, to the point where 2,699 people joined (it’s free) during the first five days. It’s at bpx.sap.com and will build-out during the summer to be launched in September at the SAP TechEd event.

Full disclosure: I’m on the SAP team helping to drive it, and would enjoy getting feedback (use the Business Process Expert forums on the site itself) on what interested members of the community would like to see in the built-out version.