Tackling digital transformations with multi-tenancy solutions
Many people are familiar with the concept of multi-tenancy through SaaS platforms such as Salesforce, Office 365, and Azure. Few people seem to recognize the potential of a multi-tenancy architecture within a complex enterprise and the significant impact it can have on digital transformation programs.
A huge part of building a successful enterprise solution is the cost of building the software, rolling it out and maintaining it.
If the solution is to support different business units that has different needs when it comes to e.g. work-flow, branding, and integration, the complexity increases many folds. If the solution is not built correctly from the start, you end up with slow progress and high cost. Ultimately, you end up risking have to branch out code to support different units needs.
Introducing multi tenancy into the solution is a way to tackle complexity and cost challenges. However, multi tenancy also need to be used and build correctly.
The concept of tenants
In ordinary life, a tenant is someone renting an apartment. In the software industry, a tenant is someone using a compartment of a digital platform.
If an organization like Lego wants to use Azure cloud services, they first create a Lego account on azure.com. This account is called a tenant in the terminology of Azure. Lego would be considered a tenant of the Azure platform. The tenant is a kind of top-level account under which we can find all other Lego-related data on Azure such as user accounts, resource groups, databases, virtual machines and so forth. The tenant is like a master account.
In this article we will see how tenants can also be used to represent business units in your enterprise.
The key challenge in complex enterprises
In many complex enterprises, the key challenge is an implication of the fact that within the same enterprise, we have multiple competing, overlapping and evolving business models.
The business models are sometimes called brands in the lingo of the enterprise itself, and sometimes these brands are subsidiary companies. Other times the business models exists within the same company with no clear demarcation around them, perhaps not even clear awareness among the employees of their distinct nature.
I asked an AI engine to generate an image illustrating the idea of “multiple competing, overlapping and evolving business models”. Clearly, no static image can really depict such dynamics.
Here is another attempt to illustrate the same idea.
Imagine a business in 2021 with two business models, red and blue, each having their own distinct ways of delivering value to customers, called the value stream. Around 2022 the red business model grows to have some overlap with the blue business model. In 2023 a third more prevalent business model (yellow) come into play borrowing some parts of both the red and blue value stream.
Complex enterprises defined
For the remainder of this article, I will define a complex enterprise as a company having multiple competing, overlapping and evolving business models.
The origin of complex enterprises is often mergers and acquisitions. Each acquisition will add either a new business model to the enterprise or a variation of an existing business model.
Another origin is expansion to other countries, where local laws and legislations tend to degenerate the value streams into multiple different value streams.
A third origin is innovation within a company, driven by competition in the market.
Some examples of complex enterprises
In a global staffing and recruiting company, the business models could include:
- staffing of blue collar workers in Latin America
- staffing of doctors to hospitals in Africa
- global headhunting of C-level staff
- outplacement in US
- staffing of agile software teams in Europe
In a global retail conglomerate, the business models could include:
- discount supermarkets up to 10.000 distinct products and 500+ locations nation-wide
- high-end supermarkets with up to 20.000 distinct products and 100+ locations nation-wide
- hypermarkets with up to 100.000 distinct products and a few locations nation-wide
Tackling complex enterprises
Now that we have a shared understanding of what makes up a complex enterprise, we can ask the question of how to tackle the enterprise in terms of software architecture and solutions.
Considering how challenging it can be to provide well-functioning software solutions for even a single non-trivial business model, we can understand why it often feels like mission impossible when dealing with a complex enterprise with multiple competing, overlapping and evolving business models.
All complex problem-solving starts with some variation of the ancient strategy of divide-and-conquer. We will apply the same technique using the following recipe:
- Compartmentalization: Partition the entire set of business models (value streams) and variations hereof into a number of distinct categories of business models — we will call them business compartments or simply compartments.
- Identification: Give each compartment a solid name, description and an ID. Now it has identity.
- Organization: Organize everything around the structure provided by the compartments.
This will be your very own multi-tenancy structure specially crafted to grow software platforms for your enterprise. The compartments ARE the tenants.
Let us go over each of the three steps in this recipe.
Compartmentalization
Compartmentalization is the process by which we decompose the entire enterprise into compartments. The first thing we need is to grow an intuitive understanding of what makes up good compartments.
The intuition of good compartments
The simplest analogy of compartmentalization I can think of is the factorization of a composite number like 105 into the factors 3*5*7. Of course, this is a gross simplification and won’t help us much in seeing clearly.
To build the intuition, let us rather start with some abstract images.
The first image depicts compartments as demarcations of value streams (business models). Each compartment evolves over time. Each compartment is different from all others, yet they share many similarities.
The next image depicts 9 compartments, each holding a distinct business model symbolized by some kind of abstract machine (grey box). The business models are different, yet similar.
This image should remind us about the following structural characteristics of compartments:
- Compartments are separated. If something is part of one compartment, that thing cannot also be part of another compartment.
- Compartments constitutes the whole. When you put together all the compartments, you get the entire enterprise. There can be nothing outside the compartments.
In a single sentence we can summarize it by saying that the compartments are Mutually Exclusive and Collectively Exhaustive, sometimes referred to as the MECE principle. Every value stream, every business process, every profit and loss must be uniquely associated with one and only one compartment.
Next, let us get an image of how the compartments are composed to make up the whole of the enterprise. Think of business compartments as a backbone of your enterprise. The backbone must be solid and flexible at the same time. It must be able to adopt and stretch yet be resilient and never break.
What separation means
As said, compartments provides separation and this is a two-edged sword.
On one side, it implies a positive effect of agility, as it allows us to freely evolve the business model of a single compartment without influencing the business models of other compartments.
On the other side, separation implies negative silo-effects, leading to degeneration and duplication in various forms.
The positive effect of agility is clearly a competitive advantage. Every business strives for agility, and agility is probably the strongest differentiating factor among all.
To avoid the negative effects of degeneration and duplication, we need to find effective ways to reuse across compartments. What does “reuse” exactly mean in this context? It is a bit hard to explain without getting dragged down in technical details about software development, implementation and deployment, but here are two typical examples:
- Infrastructure can be shared and used to run software solutions across multiple compartments
- Global master data can be shared between compartments
Practical guidelines for compartmentalization
From the previous sections you should have some abstract understanding of what the compartments are and an understanding of the trade-offs implied.
What follows is some practical guidelines that may guide you in your business.
- If you have multiple business units, then these are good candidates for compartments.
- If you are merging another company into your own, then probably the business model of the other company should be associated with its own compartment, unless the other company is very much alike your own company.
- If you have multiple brands, perhaps multiple subsidiaries, these could be your compartments.
- If you operate in multiple countries, then the compartments may per country. For instance, if you have 3 brands in 9 countries, you may have 27 compartments.
Identification of the compartments
Once you have created the compartmentalization, we need to give them identification.
You likely have different kinds of lingo around them. You may speak in loose terms around this and that category of business models.
Because the compartments represent the abstract idea of a category of business models, they tend to be hard to grasp by many people. Also, because they often have many similarities people tend to mix them up.
For these reasons we need a strong way of explaining and reinforcing the definition and boundary around each compartment. You should have a clear narrative around each of the compartments that is clearly stated and documented.
Next we give each compartment a unique name and ID. The name and ID should be considered as permanent as the name of the company or as the domain name of the company website. If you change these things later on, you will have an ocean of changes coming along.
Organizing everything around the compartments
Now that we have the compartments together with names and IDs, we can use it to structure everything else. We refer to the compartments as tenants and the entire set of compartments is referred to as the tenancy structure.
One example of a tenancy structure for a global recruitment and workforce management company could be:
- Tenant ID 140, Name: Staffing Latin America, Description: staffing of blue collar workers in Latin America
- Tenant ID 141, Name: Staffing North America, Description: staffing of blue collar workers in North America
- Tenant ID 142, Name: Doctors Africa, Description: staffing of doctors to hospitals in Africa
- Tenant ID 143, Name: Doctors Indonesia, Description: staffing of doctors to hospitals in Indonesia
- etc. etc.
Based on this we can use the tenant IDs or names in:
- DNS setup
- firewall openings
- server names
- database names
- keys used to lookup data
- logging of errors
- financial reporting
- identifiers of rules in rule engines
- keys in feature toggles
- rules in API gateways and other kinds of traffic routing
- configuration of commercial off-the-shelf software products (COTS)
- configuration of SaaS solutions
The end result is that the entire system landscape is logically sliced so that each tenant (compartment) has a slice on its own. This is a very powerful mental model and the ultimate divide-and-conquer strategy for complex enterprises.
The idea of a sliced system landscape is illustrated on the following image.
Conclusions
We have established the notion of a complex enterprise as a business with multiple competing, overlapping and evolving business models.
Next we introduced the notion of a compartment as a category of business models. We explained how the process of compartmentalization must yield a set of compartments following the MECE principle — Mutually Exclusive and Collectively Exhaustive. We also explained the importance of giving the compartments permanent names and IDs.
Finally we learned that we should think of the compartments as tenants giving us the tenancy-structure on which everything else can be structured and organized.
In this way we have arrived at one of the most fundamental principles of enterprise and software architecture for complex enterprises:
The tenancy structure should be the primary organizing factor in your enterprise and software architecture
Getting this right can be crucial to your digital transformation program.
This article is also published here:
https://sprintingretail.com/blog/tackling-digital-transformations-with-multi-tenancy-solutions/
