Multitenancy: Methods, Areas, And Approaches
nd3000/Shutterstock.com

The Different Methods, The Distinctive Areas, And The Approaches To Multitenancy

Multitenancy enables you to respond to your organization's needs and still use one central Learning Management System. Following are the existing approaches and areas of application, but we’ll start with exploring multitenancy’s different methods.

eBook Release: Multitenancy With Totara And Moodle
eBook Release
Multitenancy With Totara And Moodle
Learn about multitenancy, which allows different groups or organizations to use the same infrastructure, applications, or databases in a central Learning Management System.

The Different Methods Of Multitenancy

1. Category Tenants

You separate your users into categories, and in those categories, you can distinguish course creators who have the freedom to manage their own users, within the courses they have created. This method provides privacy to each tenant.

2. Hierarchy Tenants

This method utilizes the organizational hierarchies that are available within Totara. You can place users into one of the multiple organizations and categories that you have. This method offers privacy in reporting at the course level, as it distributes reports site-wide, but only for your own users.

3. Federated, Or Distributed

In this method, users have separate sites. This method is sometimes necessary when there are higher levels of configuration required for each tenant, and where tenants are managing their own users.

3 Areas Of Multitenancy

There are 3 distinct areas of multitenancy that are important to consider:

  1. User and Course Management
  2. Admin and Code Management
    (involves settings, modules, codes)
  3. Miscellaneous Management
    (involves themes, reporting, and backup)

There are a few important things to consider when thinking about user and course management. Ask yourself the following questions: Will each tenant require its own administrator to manage their users? Where will courses be managed from – either centrally (by the organization) or locally (by the tenant)? Will users from different tenants need to enroll in any of the same courses? Must usernames be different for each tenant, or is it possible to have multiples of the same username. Does there need to be a limit on the number of users each tenant has? Should users from different tenants see and communicate with one another, or should they remain separate? The answers to these questions will determine which type of multitenancy set-up you will need.

With admin and code management, the first thing to think about is how administration will be managed. If you have a centrally managed administration setting, all items will be managed by the super administrator. If you have a locally managed administration setting, items are managed by the local, that is the tenant administrator. If you have an inherited managed administration setting, values are centrally set (by the central administrator) but can be modified and altered by the local admin. Consider what your needs and requirements are, and select your management style accordingly.

A key feature of Moodle is module and code management, which provides the ability to source code. The problem here is that even the slightest changes to the core standard system will highly increase the amount of maintenance required when it comes time to update. With an already sensitive system, it further complicates things when multiple tenants are added to the equation. In order to make things go smoothly, the decision of what modifications are to be made (including the extent of modification) should be done first. Here are a few questions to ask yourself: Will there be modules, third-party plugins, and/or modifications in coding? What will the alterations be, and to what extent will they be made? Consider these questions and make the necessary modifications before going into multitenancy.

The last aspect to consider is miscellaneous management. Consider which of these features (if any) will be required for your tenancy. Much like with code management, with each of these components, the complexity is amplified when it comes to multitenancy. The three features we will discuss are branding, reporting, and backups.

Each tenant will have its own requirements for branding, which includes details like company colors and logos. There are two things to consider here. First, does each tenant require branding to be present initially on the login page, or once they have already logged in? Second, will the home-page need to be specific to each tenant, or can it be generic? These are modifications that need to be thought through first.

Lambda’s Custom Themes

Reporting is necessary in any eLearning system, and there are a few requirements people commonly have. These include the ability for cross-tenant reporting, as well as a solid separation of reports so that tenants cannot see each others' reports.

Learn About Zoola Analytics

Backups are an essential component of security and there are two major questions to think about. First, will each tenant be in charge of their own backup setup, or will this be centrally managed? Second, where will backups be stored?

All of these features will affect what type of multitenancy setup approach you take, and what components of multitenancy you decide to take on.

3 Approaches To Multitenancy

Now let’s go over the 3 approaches to multitenancy. They are monolithic, distributed, and federated. The approach you choose will entirely depend on what your needs are.

The monolithic approach is the simplest of the three options. Here you can create a focused theme for each category that can only be viewed once a user has verified their identity with a login and password. It is also possible to create and support categories for tenants, as well as subcategories and sub-sub-categories.

The benefits here are centralized management of courses and users, reporting offered across the site, centralized backups for courses. The downside is that there is not much power at a local level. No administration settings or modules available locally and source codes cannot be changed locally. As well, this approach does not allow much privacy for tenants, and it places the management of the LMS on the Central Administrator.

With the distributed approach, there is an individual LMS instance, with a single code base. With this approach, there cannot be any modifications at a local level, and all default module settings must be the same.

The benefits of the distributed approach are that there is a single codebase, it provides a greater deal of privacy to tenants, it provides individual themes to separate tenants, allows organizational frameworks for each tenant, and localized reporting for different organizational frameworks. The shortcomings of the distributed approach are that modules are central, course backups are located centrally, and course and user management are shared between central and local sites.

Lastly, we have the federated approach, which fills the gaps that are present in the first two approaches. The weak points of the first two approaches are that each of the tenants within one setup must run configuration of the LMS that are identical, which can be a deal breaker, as it simply does not work for some organizations.

The federated approach fills this gap for users who need to have individual systems for tenants. This approach allows tenants to manage their own Moodle instances, with the capability to operate different modules and source code for the different tenants. The benefits of the federated approach are that full tenant privacy is possible, individual, separate themes for each tenant is possible, and that modules, administration settings, and source code changes can be managed locally. The downside is that user management, course management, and course backups cannot be managed centrally, and there is no centralized reporting across tenants since reporting is localized to maintain privacy.

If you want to learn more about multitenancy, download the eBook Multitenancy With Totara And Moodle.

Close