Multi-Tenancy
Multi-tenancy is quite common and almost indispensable in B2C software, but what about B2B products? Let's take a look at what multi-tenancy means, and how it affects the design decisions.
In my current company, I have been working on a product that is used by multiple B2B customers. This is not your internet scale B2C application, but a customized SaaS solutions for enterprises. It takes weeks and months to sign up a new customer, and involves proof of concepts, showcasing case studies, customization and new development. But the resulting customized application is not a stand alone solution for that customer, but is fed back into our own SaaS product. In this and the next few posts, I will go over the different aspects that I consider when developing such a system.
From Wikipedia:
The term software multitenancy refers to a software architecture in which a single instance of software runs on a server and serves multiple tenants.
A tenant is a group of users who share a common access with specific privileges to the software instance.
In other words, if you develop software and then use it for servicing multiple customers who have no relationship between them, then what you have is code that is multi-tenant aware. There are multiple layers of this - you could have one single deployment for all your customers, a unified backing storage, or you could vary your deployments to have separation between the tenants.
We will see later how this is different from a B2C setup, where a customer can typically "sign-up" on their own. The moment you have that option, many of the choices no longer hold true. More on this later.
Let's consider two companies (tenants) who are our customers - Ravenclaw and Hufflepuff. Both want to use our wand matching software MatchWand, but their requirements are not exactly the same.
One important business decision is whether to sell the software as-a-service or as-a-solution. In the former, we will try to develop MatchWand as a product, with variations for different tenants in it. In the solution approach, we will typically have a generic code base, which will be forked once for Ravenclaw, and again for Hufflepuff.
These terms - 'solution' and 'product' - are highly overloaded and used differently in different places, and are generally specific to how companies consider software. Here what I mean is, if it is a solution, it is only for one customer. A product, on the other hand, is a solution for multiple customers, and hence highly SaaS-able.
A solution approach typically ends up as a being deployed exclusively for that customer on your datacenters or on the cloud, or could even be deployed at the customer site. In the extreme case, there are separate code bases for each tenant even. Once the tenant-specific code base diverges from the generic code-base sufficiently, it is difficult to merge it back and create a software product out of it. When you want to add similar features or fix similar bugs for both clients, it may prove to be difficult or error prone.
The product approach is more interesting. We typically start off developing MatchWand for one client, Ravenclaw. It is deployed for Ravenclaw. Another client Hufflepuff now comes in and wants to license the software, but need its own customizations and modifications. The second client is always the trickiest and most critical. If you decide to take short-cuts here, you might end up with unmaintainable code (more on this later). We spend enough time refactoring, so that MatchWand remains as a single codebase, and can be deployed to Hufflepuff also.
So, which approach to take? The product approach would take more time upfront and would need good domain knowledge to know the potential 'change points' - where different customers' businesses differ. The solution approach can be deployed faster, but becomes unmanageable as the customers increase. Its all a trade-off. You may take a product approach, but if not enough customers come, you don't get the benefits of the effort you have put.
In the next post, we will see how to approach the "product" development from a technical perspective.
Cover Photo by Annie Spratt on Unsplash