Wikipedia defines Multi Tenancy as:

Multitenancy refers to the architectural principle, where a single instance of the software runs on a software-as-a-service (SaaS) vendor's servers, serving multiple client organizations (tenants). Multitenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations. With a multitenant architecture, a software application is designed to virtually partition its data and configuration so that each client organization works with a customized virtual application instance.

My definition of multi tenant includes a single instance service multiple tenants and multiple instances, one for each tenant. In fact, it would also include the idea of a product line as well. Or, like I like to think about it, perhaps it is product lines that are used in multi tenant scenarios.

Let us start from the beginning. We have a need for building an application that can handle several tenant. A typical example would be Invoicing System that we can sell to different clients. Note that I explicitly don't care in this scenario how the application is deployed. It may be at the client site, hosted in as multi instance or single instance. The only thing that is important in this scenario is that the application is the same for all tenants.

That is, they have no, or very little, customizations options. By customizations I don't mean having the ability to change the logo or the skin, but true customization. Changing the way the system behaves, extending the domain, adding more UI, adding more behavior, editing existing behavior, etc.

If you don't have customization, then you really have very little issue, you can take a standard application and deal with the tenants as purely infrastructure concern (yes, I know that you need a bit more control than that, but bear with me).

If you do need this customization behavior, then it doesn't matter what your deployment strategy is, the important issue is that you have to support multiple parallel customizations to your application, including the ability to extend the model and override the application behavior. And that is applicable for product lines as well as multi tenant applications.

As it turn out, there isn't a lot of actual challenge in making such an application once you have an IoC in place, you can trivially change services and model without any issues. The problems are with the extension strategy, customization management, tenant management and conventions emplacement and enforcements.

I am going to talk some more about this in the future, but that will go down into the gory details and will be a real zoo.