Multi-Tenancy (MT) is a hot topic these days: you will rarely see an RFI/RFP document that will not include a question on whether the proposed solution provides is multi-tenant and, ofcourse, this is always the case when the RFI/RFP is issued by a Service or Cloud Provider.
The concept of MT is considered to be a well-understood concept: basically it refers to the ability of asoftware solution to allow a single instance to serve multiple client organizations (or tenants). However, there are many subtleties in this concept when you dig into it and take into account the complexity of an Enterprise solution. When further analyzed, MT reveals to be more shades-of-gray, than a black-and-white concept – where the black represents the complete absence of any multi-tenancy capability, the white full multi-tenancy capabilities, and thegrays “some level” of multi-tenancy capabilities, as we will explain here below.
The starting point is analyzing the different roles involved in an Enterprise management solution that the concept of multi-tenancy can refer to. In order to make our discussion general, instead of considering a specific product, we’ll consider a generic solution that we assume provides end user (possibly tenant users) the ability to access a webinterface to generate new content (e.g. a request order, capacity model, chargeback report, etc) or just to visualize (OOTB or custom) views containing contents that have been created by themselves or by another tenant user. We also assume that this solution will allow administrators to assign visibilityand ability to create, schedule and possibly distribute contents, for example based on a Role-Based Access Control (RBAC) security model. Even in this simple solution, MT has several interesting shades.
First of all, the administration role will be either “monolithic” or allow tenant-level administrators to manage their (tenant) users and to specify RBAC’s. Moreover, the assignment of managed systems tothe appropriate tenant could be based on a manual mechanism – managed by either the overall administrator or by each tenant administrator for their domain of competence, or better on an automated mechanism – either based on a multi-tenant CMDB, where the managed systems are automatically characterized as belonging toa specific tenant, or on several single-tenant CMDBs.
All these different options make quite a difference in terms of the required effort and management complexity, depending upon whether you are managing 50 tenants with 500 systems per tenant, in environment where few managed systems are added or removed over time – as could be the case for an internal (or Type I) Service Provider where tenants are internal organizations of a single company. Or in the case where you are managing 500 tenants in a dynamic environment with around 5000 managed systems – as it more likely the case for anexternal (or Type III) Service Provider.
When you consider the end-user role, even more shades appear. For example, you need to consider whether users will have the ability to access and have visibility of their own managed systems for OTTB views only, or for customized views as well and whether multi-tenancy willbe enforced by the underlining presentation layer, or whether it needs to be implemented at the application level, for every custom view.
In conclusion, my suggestion is that next time you prepare (or answer) a RFP where MT is a requirement, makesure that you explicitly clarify which level of multi-tenancy you are reallyrequesting (or addressing, respectively). This will help you to ensure that youare able to get or deliver the level of multi-tenancy for the specific contextat hand.
In an upcoming blog I plan to describe my proposed taxonomy on multi-tenancy. Since this is a hot topic, I’m pretty sure that my proposal will elicit additional blogs on the topic.