Software as a Service is a software delivery model in which software and its associated data are hosted centrally (typically in the (Internet) cloud) and are typically accessed by users using a thin client, normally using a web browser over the Internet.

Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants) for example

As an architect when I first dealt with a multi tenant SaaS product (When multi tenancy term was not hyped much) I just saw it as another on-premise solution with additional filter criteria in tables to segregate data. Well is that what it is. Is that all the difference between on-premise and multi tenancy. Answer is yes and no. It could turn out to be just any other product with minor data filters or could turn out to be massive challenge based on the need of a product.

Let us look at the detailed definition of multi tenant SaaS solution –

Software which securely segregates and

Serves data and operations (with agreed performance SLAs )

Behaves according to the customer’s user context,

Available (with agreed availability SLAs) from a central hosted location offered as a Service in

Integration with the customer’s other LOB applications

from a single instance.

Hence you can see that each of the terms in bold could pose challenge at different levels depending on the customer. These terms are nothing but what we call as Non functional requirements. How can these be different from an on premise application? I am just going to list few of the NFRs and compare it with an on premise application.


SaaS is a volume game. An ISV becomes successful only when there are huge number of customers in the system. Hence imagine the volume of growth of a SaaS application. For example, in an on premise scenario you could architect your solution to serve 1 million users for a large installation. After 5 years there is a possibility that it might grow to 5 millions. Let us look at the same scenario on SaaS, assume you have started with 1 customer whose user base is 1 million and other 5 customers whose user base is ½ million. Now after 5 years the volume in the SaaS application would be the additional customers served by the instance as well as the additional user based added to the existing instance. As you can see the growth that the SaaS application needs to handle is multi fold compared to the on-premise and in a multi tenant solution all from a single instance. Hence there is a need for a strong scalable architecture at all levels of the software – presentation, application, database, backend processes and so on.  This is first area to tackle in a multi tenant SaaS solution.

Data Security

Data security needs to handle

  • Isolation of data between customers
  • Protection of data stored  and accessed
  • Protection of data while transmitted

In an on-premise model, the data ownership rests with the customer and hence it is not something an ISV needs to worry about. In a SaaS solution this is key and if compromised can lead to adverse effect. The architecture should build enforcements that the data cannot cross boundary of customers right at the base and should not leave it to the developers to handle as it might lead to errors. Also the way the data is protected and stored needs to be watched out as even an ISV’s DB admin should not be able to view a customer specific protected data. These enforcements should be applied to all the possible access points of the software.  Data Security Architecture is another priority area to tackle in a multi tenant SaaS solution.


The level of configurability a true multi tenant SaaS software needs to have is much higher as a single instance needs to be completely transformed and behave as per the requirements of multiple customers depending on the user context. The level of configurability required could vary from

  • theme branding
  • view configurability
  • business rule configurability
  • data attributes configurability
  • workflow configurability
  • access control policy configurability

and so on.  In an on premise application customizations can be brought in using even code extensions which is not possible in a multi tenant SaaS solution.  Also in a SaaS solution

  • The expected time and effort of on boarding a tenant and tuning the solution for their need needs to be much more minimal as compared to an onpremise solution
  • It becomes highly important to keep the customer satisfied as there is a lot of possibility of customer churn in a SaaS model and hence the need to bring in features demanded by the customers easily and quickly.
  • Operational efficiency is extremely important for the profit of a SaaS solution and hence as the customer base grows. More self serviceable an instance is by the customer more efficient it is for the ISV

The above parameters in a SaaS solution make it more compelling to have a larger configurability in comparison with an on premise application


The list of NFRs that become more challenging in a SaaS solution is not just this. We will cover the others in the coming blogs