Principles for multi-brand platforms

Many of the companies I've talked to over the years share a common challenge. They have multiple brands and they long for faster innovation and cutting costs. Often the two go hand in hand. They want to cut costs in order to free up resources for faster innovation.

Their idea for achieving this is often spelled a multi-brand platform. If they could consolidate all of their brands on the same platform the costs for system maintenance would decrease and they could spend development efforts on building features that can be used by all of their brands. Sometimes they also dream about being able to sell their platform to other companies in the same business.

However, when I ask what they mean by a "platform" in more detail the answers tend to be pretty vague. Typical answers include:

• The costs should be lower than they are today

• We should be able to innovate more quickly, for all brands

• Migrating an existing brand or adding a new brand should be easy

Those answers are all sensible desires that describe business goals but they don't really describe the vision for what the platform should be. That leaves a lot of ambiguity to those who should actually build the platform. Oftentimes multiple teams will be involved and that ambiguity leaves so much open for interpretation that it's highly likely that they will work toward different goals.

A set of common principles is needed.

I believe that those principles can be learned from platform providers or Software-as-a-Service companies. Such companies are forced to design their system for a couple of things: multi-tenancy and easy provisioning.

Multi-tenancy

In its simplest form multi-tenancy means that the platform should be able to handle multiple brands. However, in order to fully achieve the benefits of a multi-tenant platform the applications involved can't just be designed to handle a number of brands.

The whole platform must be designed to not know about its tenant beforehand. This means that the applications within the platform should only be allowed to know about the brands it serves at runtime, not at build time. A brand should be a record in a database and can never be allowed to be mentioned by name or ID in code.

While this may seem overly ambitious for a company whose brands can be counted in the tens or hundreds it's a vital principle to achieve the sought after benefits. If this principle is violated it's all too easy to end up in situations where special solutions are built for specific brands. If the code differs by brand, reasoning about how the platform works will be increasingly hard and adding new innovative features that should be available to all will be scary as it's hard to get an overview of how that will impact different brands.

This principle doesn't mean that the platform shouldn't be able to cater to different brand needs. It means that brand needs need to be abstracted to configurable features within the platform. We shouldn't build an application where brand A has its logotype to the left and brand B has its logotype centered. Instead the platform should allow each brand to choose where the logotype should be placed at runtime.

Not only is it nice to be able to change the placement of the logotype without having to redeploy applications. Reasoning about a general feature where logotypes can be placed in different places is much easier than reasoning about where a wide range of brands have their logotypes placed, especially when the list of such configurable features grows.

Provisioning

Being able to deploy applications often and at will is a strong indicator of a high performing team. Not because frequent deploy necessarily has business value but because being able to deploy often, without incidents, indicates that the team is using sound processes, a sensible architecture and has proper automation in place.

The equivalent of this when it comes to platforms is fast and easy provisioning of brands. Setting up a new brand should be quick and easy. Preferably done in minutes. As a business you are probably fine if it takes a day, or even a week or two. However, by saying that it's OK if it takes a week to set up a new brand you are inadvertently saying yes to bureaucracy, manual steps and sub-par architecture.

Achieving fully automated provisioning will probably prove challenging, but it's an excellent leading indicator when striving for the business goals of cutting costs and faster innovation.

Challenges

When trying to build a multi brand platform the application code is the meat of the platform hamburger. It's the natural starting point and probably the most important. While it requires discipline it's fully achievable using the simple principle of stating that brands and their characteristics can only be known at runtime.

There are however also other layers that are important, and who can prove even more challenging: styling and infrastructure, the bread in your burger.

Styling

Unless you are prepared to streamline brands to a level where their unique identity is in danger your platform will likely need to contain quite a lot of brand specific styling. That styling itself can't reasonably be an entry in a database. However, what can be an entry is which theme the brand is using. That is, rather than at build time knowing what styling a brand should have, the platform can at runtime know which theme it should use.

In some cases a small set of distinct themes, configurable features per brand plus a few assets, such as logotypes, that can be changed at runtime may be enough to achieve distinctly different brands. If it is not, each brand will end up with their own theme. In such scenarios you may not be able to completely provision a new brand in minutes, but you are at least able to get a copy of an existing brand up and running and can then spend some time designing its own theme. With that said, no matter the number of themes that you have it's vital that they are created from a well crafted design system. With such a system in place even per brand themes will be manageable.

Infrastructure

Your platform will need compute services, storage, networking and DNS. In theory, in the era of cloud providers this shouldn't be a problem when it comes to creating a multi-tenant platform with quick provisioning. Any cloud provider worth its name provides APIs for provisioning and managing all sorts of infrastructure.

However, in practice many old IT paradigms are deeply ingrained in companies. In order to achieve quick provisioning automation is key and that means you can't have steps requiring a human to look at a ticket in a service management system. To reach your goals you need to challenge old paradigms. You need to replace security through inspection by security through automated workflows. Such workflows can easily be audited and will be far less prone to (human) errors than the old procedures, but getting everyone onboard will likely require significant effort and large parts of the organisation working towards the common goal of seamless provisioning.

Success criteria

We started off by discussing the overarching goals of lower maintenance costs and faster innovation. I'm convinced that if you manage to create a platform where a new brand (or other type of tenant) can be fully created within minutes without any effort from developers or IT-personnel you will be in a great position to achieve those goals.

Your developers can work on improving the platform in a way that benefits all brands and you will be free to start a new brand at the click of a button or two.
Not only that, you may find that what started as an internal efficiency play is actually a product in its own right, just as Amazon discovered when AWS grew out of their internal infrastructure.