Tenant Specific Content
Okay the next issue to be aware of is about how actually the content is stored. So let’s for the sake of simplicity assume the content is a “News Article” with fields like Headline, Byline and Body.
A very good article on issues related to multi tenant data architecture is here. This article explains data architecture in terms of databases, schemas and tables. The same architecture principles will also apply to a more generic CMS repository which may not be based on a database. The CMS can store the same content for multiple tenants in multiple ways. It can either have a completely independent repository for each tenant. It can also use the same repository for all the tenants but with some kind of logical partitioning. I think Alfresco uses this mechanism. And finally, it can use the same repository for all the tenants without any partitioning. In this case, Tenant -> Article ownership is identified by some other mechanism. A possible way is to have a field like tenant id (along with Headline, Byline and Body) that identifies the tenant.
Each of these mechanisms have their advantages, disadvantages and associated costs. There is a trade off between security and costs.
Administration
Apart from tenant specific administration (or Federated admin), the application needs to provide capabilities like:
- Provisioning
- Billing and Metering
- Management, Monitoring and Reporting
So some kind of delegated administration and centralized management application is required that enables assigning administrators for individual portals (or applications) and then Monitoring (and managing) these individual portals.
There are also issues related to Tenant Specific Security. More about that later…
RSS