When ISVs move from an on-premise model to a SaaS model, it is quite common to take the route of Single tenant model. But when they start growing beyond 15 customers is when they start realizing the pain of maintaining a single tenant model both from cost and effort as well as from a quality perspective. When they make an attempt to move towards a multi-tenant model, they are stuck with more strategic decisions than technical decisions.

The primary roadblock towards the move is – Multiple product versions for different customers. The misconceived business advantage of single tenancy which once allowed them to customize anything and everything for a customer turns out to be the biggest business disadvantage for growth. Needless to say the difficulty of maintaining specs, test cases, upgrade plans, technical documentation for all these versions and the effort required for it. Subsequently many of these processes are diluted, which leads to onerous confusions and quality defects.

What should a SaaS ISV do for solving the above problem? How should they approach it both technically and strategically? Below are my thoughts on these questions.

Identify The Core Product

The first task is for the product management team to identify the right features they want to call as “Core”. Core is the product that can be marketed to 80% + of the customers without many changes. This can be easily done by drawing a feature map sheet with the following details,
a. Feature
b. Business value
c. Selling Value
d. Number of customers who are actively using it

 Identify Variations from core product

Next step is to find out the variations in these features and additional features that you have supported for other customers. It is very important to understand the kinds/types of variations we are talking about and level of complexity it is going to introduce when you want to merge and support all these variations into a single code base. The variations can be categorized as one of the following

View level changes

  • Label level text changes in the view. Customers can demand different label texts for fields in order to be consistent with their nomenclature. For example in an employee management system- one customer could call an employee identifier an “Employee number” while another customer could call it “ID number”
  • Simple validation changes. Customers can demand different validation requirements for the fields. For example, one customer might require the employee number in certain format and the other customer might need in a different format
  • Field visibility. The number of fields required by one customer might vary from other customer. For example, in an employee management system some customers need Passport details and some would not want to show the field.

Data level changes

  • Additional information fields. Customers might need additional fields to be captured than what is offered in the product and the kind of fields can vary from customer to customer. For example in a loan processing system, the kind of information fields that the system has to capture could completely vary from one lending organization to another.
  • Data level validations. Some customers might need different validation logic across fields. In the same example above one lending organization could need different validation logic for the fields from another

Workflow related changes

  • Business process level changes. Manual workflow could be different based on the need of the customer. For example, in a SCM order processing workflow could be different from one customer to another.

Integration related changes

  • On premise integration. Some customers might require their on-premise systems to be integrated at certain scenarios while others might have a different scenario for integration.

 Additional Reports

  • Additional Reports. Some customers might demand additional reports on top of the pre-canned reports for viewing and export purposes. These report needs could be completely different between one customer to another.

Additional Features

  • Additional informational screens. Some customers might require additional screens to capture information for ad-hoc use cases. For example, in an employee management system one customer might want to capture training related details of an employee other than what is offered in the product and another might want to capture vehicle details of the employee.
  • Changes in existing features. Customers can demand completely different navigations, business logic within existing features.

 Design a technical approach to address the variations in a single code base

Once you identify and categorize the variations, the next step is to see if at all these variations can be accomplished via a single code base. The good news is 99% of these variations can be achieved with a single code base by building a proper configuration framework. A configuration framework mostly comprises of,

a. Field Metadata system
b. Data Metadata System
c. Configurable workflows
d. Configurable Webhooks
e. Configurable Reports

Even with a solid configuration framework, products may still demand (to meet the 1% variation) different coding level implementation to address the customer variations. To achieve this instead of maintaining different code bases it is advisable to adopt configurable tenant based code extensions where the extensions get executed at the right scenarios for the respective customer. The architecture of your core product would look something like this.

Single to multitenant

Start the migration

Once the technical approach is arrived, ISVs can be assured of the move towards Multi Tenancy and start the migration.

Wish you a happy multi-tenant journey.

Visit our website for more details on Multi-Tenancy Enablement