How do you go about defining an architecture that supports multi-tenancy? What are the design considerations? Let us explore answers to these questions. In the first part of this two-part series, I am setting the context and presenting a list of questions that will help you get adequate information on the task on hand. In the next and final part I will discuss the broad areas of architecture that influence multi-tenancy and provide some references.
The term multi-tenancy became popular with the advent of Software-as-a-Service or SaaS applications. One of the characteristics of SaaS based products is the ability to serve multiple customers through a single installation. This is known as multi-tenancy. With multi-tenancy every customer or company will have administrator and user credentials to access the system. This warrants privacy and security. In order to achieve multi-tenancy, it is essential to ensure configurability and scalability. With configurability, each customer or company can configure the product, and customize the UI as well as other elements (such as business logic, report formats, user preferences, personalization, etc.). Hence new customers can be added with ease – there is no need to get the product installed again! Also this architecture is required to provide cross platform support – for example it has to support multiple browsers based on a pre-defined set of browsers. Above all the SaaS enabled product needs to be highly robust and offer ease of integration.
What matters is the kind of questions you ask when a problem like this is thrown at you. The typical questions are,
1) How do we define the details of multi-tenancy requirements for our application?
2) How many tenants – both minimum and maximum, to be served?
3) How will the application and other routines identify a specific tenant?
4) What are the security requirements (across all layers)?
5) How are we going to validate users?
6) What are the configurable parameters needed to support multiple tenants?
7) How are we going to add new tenants?
8) How are we going to retire an existing tenant?
9) What is going to be the volume of data over the next five years? What are the scalability and performance requirements?
10) What are the UI requirements? Do we need to enable tenants or customers to define their UI or theme? (Obviously, yes. But to what extent?)
11) What are the external systems and interfaces? Are these different for different customers? How are we going to handle these?
12) What is the implementation view? Are we going to have multiple databases or application servers? Why? Why not?
13) How many browsers and languages are going to be supported?
14) What are the other devices from which the application will be accessed (such as tablets, smart phones)?
15) What is the expected load (number of transaction) during different times in a year?
16) What are the expected benefits of implementing multi-tenancy and what are the corresponding architectural or design considerations?
17) What are the maintenance routines and dashboards required to monitor the performance?
18) What kind of dashboard is required by the administrator or super user(s) of each tenant?
19) What is going to be the maintenance and release cycle? How will it affect multiple tenants?
20) Is there a need to implement usage based pricing or monitoring the number of transactions per tenant? If yes, what are the design considerations?
21) What is going to be the level of reuse to improve maintainability?
If you have designed (or are designing) a multi-tenant application these questions will lead you to additional questions. Please feel free to share those questions. I will add them to this list. Finding answers to all these questions will help you define an architecture that fits well.
In the next and final part of this series, I have discussed the broad areas of architecture that influence multi-tenancy.