Alfresco has long supported Multi Tenancy in their enterprise and community ECM releases. Multi Tenancy allows you to logically separate the repository by tenants. Each tenant is assigned and mantained by a specific domain at login. Some thoughts based on recent client experiences in maintaining and planning an upgraded of a client using a Multi Tenant setup.
The most important thing to note about MT in Alfresco is that there are a few features that have not been implemented and some of these may invalidate the use of MT for your organization. To see the latest status of MT’s features you can reference the official docs. As of this post the current features not supported in a MT setup are listed here.
In terms of the logical repository separation you do get some nice features. When creating a tenant you can specify the storage location for a tenants content store. This can be a different location or volume from the standard alfresco content store. If you do not specify a separate location all of the content will be stored together in one content store. When a user logs in with their specific domain the Alfresco API and services are all insulated and can only see their tenants specific content store. Organizations sensitive to security mixups based on standard folder/file security might be in favor of this setup if they can separate large chunks of their organization into separate tenants. You also have the ability to export and import tenants on the fly. However when moving tenants, the Alfresco application version must remain the same.
If you are still using the Alfresco Explorer interface you have some interesting customization options. Alfresco MT supports custom dynamic models and web client updates. This means you can dynamically add a custom model and interface customizations on the fly for a specific tenant. For example, TSG has created a tenant, loaded a custom content model, and customized the advanced search interface all without rebooting the Alfresco application server.
If you are utliziing the Alfresco Share interface you are unfortunately a bit more limited. You can still load dynamic models via the alfresco interface however there is currently no method for scoping share interface customizations to a specific tenant. There does however exist a feature request for this exact functionality here.
If you aren’t as concerned about custom models and interface updates on a per tenant basis the standard classpath deployment works as well. This means that any custom model or interface updates on the classpath are available to all tenants without any extra configuration.
With Alfresco focusing heavily on its Alfresco Cloud offering, it is almost certain that Alfresco engineering has been focused further enhancing Multi Tenancy features, especially within Alfresco Share, to ensure scalability and customizations going forward. We can assume these changes will evenually be incorporated into future Alfresco Enterprise and Communtity releases.