A key 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 i.e. 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’ need. 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 basic 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 organisation wants to use Azure cloud services, it first create an account on azure.com. This account is called a tenant in the terminology of Azure. The company 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 data specific to the company 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 software.

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 exist within the same company with no clear demarcation around them, perhaps not even clear awareness among the employees of their distinct nature. Illustration of multiple competing, overlapping and evolving business models inside the same enterprise.

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 as complex enterprise as a company for which the above is a good characterisation. 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

In a global retail conglomerate, the business models could include:

• discount supermarkets up to 10.000 distinct products and a huge store locations network
• high-end supermarkets with up to 20.000 distinct products and a medium-sized store locations network
• hypermarkets with up to 100.000 distinct products and a smaller store locations network

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:

• Compartmentalisation: 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.
• Organisation: Organise 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.

Compartmentalisation

Compartmentalisation 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 compartmentalisation I can think of is the factorisation of a composite number like 105 into the factors 3*5*7. Of course, this is a gross simplification and will not 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.

Seeing compartments as demarcations of value streams (business models)

The next image depicts 9 compartments, each holding a distinct business model symbolised by some kind of abstract machine (grey box). The business models are different, yet similar.

Seeing compartments as distinct business models

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 summarise 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 provide 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 compartmentalisation

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 compartmentalisation, 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.

Organising 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.

Thinking about your system landscape as consisting of a number of logical slices corresponding to each tenant (compartment) of your business.

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 compartmentalisation 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 organised.

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 organising factor in your enterprise and software architecture

Getting this right can be crucial to your digital transformation program.