When ISVs move from an on-premise model to a SaaS model, it is quite common that they take the route of Single tenant model. What happens when they grow beyond 15 customers is 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 foremost roadblock towards the move is – Multiple versions for different customers. The misconceived business advantage of single tenancy which once allowed them to customize anything and everything for a customer turns as the biggest business disadvantage for growth. It is easy to imagine the difficulty of maintaining specs, test cases, upgrade plans, technical documentation for all these versions and the effort required for it. Hence, many of these processes are diluted, which leads to onerous confusions and quality defects.

What exactly should their plan be in solving the above problem, how should they approach it both technically and strategically?

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 90% + 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
Once you do this exercise the 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

a. 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”
b. 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
c. 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

a. 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.
b. 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

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

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

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

a. 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.
b. 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 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.

Start the migration

Once the technical approach is arrived, ISVs can be assured of the move towards Multi Tenancy and start their migration. Please refer the whitepaper “SaaS migration Strategy“.

Techcello’s  SaaS Development Framework

Techcello’s SaaS development framework inherently builds configurability to your SaaS application via which all the variations we discussed can be easily addressed. To know more about Techcello click here.