“Multitenancy” refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants)” – This is the definition of multitenancy from Wikipedia. Here the term tenant refers to “client  organizations”. When there are multiple client organizations of different nature accessing the software what constitutes a tenant can get complicated. Let us try to objectively define a tenant.

Tenant is a virtual partition within the software which controls the following

  • Customizations
  • Data access
  • Data ownership
  • Licensing

Hence any organization, department or any logical entity that requires these control need to be considered as tenants. Most often only the organizations that purchase the software need this control and hence it is enough to have a flat tenant structure.

Tenant Hierarchy

In few cases there might be a requirement to control the above parameters at a sub entity level within a tenant and hence the sub entity is created as a tenant

In some other scenarios there might be a need for different kinds of organization accessing the software such as a resellers and organizations who have purchased the software. Here it is also necessary to access data across other tenants. This leads to the creation of multiple kinds of tenants and define the relationship between them based on which the above parameters can be controlled and data can flow throw the related tenants. The relationship could be parent child relationship where one tenant belongs to other tenants or could be other relation type based on the type of tenants.

General Challenges in such a tenant hierarchy are,

Data access across tenants

Transactional data needs to be accessed and managed across tenants which could be configured and controlled at an entity level by a tenant.

Configuration data inheritance

Configuration data needs to flow through tenants so that the tenants can automatically inherit the configuration data from the relationship chain above

Tenant isolation

Though data needs to be shared between tenants there should be clear data isolation boundary set at an entity level by the tenant beyond which data cannot cross.

Data sharing between tenants

Apart from data access there could be few data that are owned by multiple tenants which are related.

Tenant Fallback

When a relationship chain is broken there needs to be a provision to assign a different tenant.

All the above said functionality needs to be addressed at the framework level and should not depend on the developers to implement as otherwise it is highly error prone and highly time consuming from both development and testing. Failure to address the above features effectively would also lead to operational inefficiencies. Many multi-tenant frameworks support tenant hierarchy and has the following features to the address the challenges

Tenant relationship management: This has the ability to completely manage the relationship between tenants including the tenant fallback

Tenant scope: This has the ability to set the read, update and delete access of data at an entity level across tenants based on the relationship between the tenants. This access rights is flown across all the other features within the framework

Tenant Settings: Tenant settings are templatized and can be assigned to tenants easily. Who could control the tenant settings are again driven by tenant scope.

Configuration inheritance: This allows the configurations set at a parent level to be inherited automatically to the child tenants. If the child tenants need separate configuration they could copy the parent settings and override their configurations.

To get further details on Tenant Hierarchy and Frameworks supporting Tenant Hierarchy contact [email protected]

 

 

 

 

 

Latest posts by Jothi Rengarajan (see all)