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.

Multi-tenancy 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 salesforce.com.

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 challenges at different levels depending on the customer/product. The above description is what we call as Non Functional Requirements(NFR). 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.

Scalability
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 capture 4 new customers every year. Now after 5 years the volume in the SaaS application would be the sum of all the customers data growth over the period of 5 years (from the time of their added to the system), which would sum up to 60millions. 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 right at the design level that the data cannot cross customer’s boundary and should not leave it to the developers to handle as it might lead to manual 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.

Configurability

The level of configurability in a true multi-tenant SaaS software is much higher as a single instance needs to be completely transformed and function 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. In addition to this, in a SaaS solution,

• The expected time and effort for onboarding a tenant and implementing the solution for their need is much more minimal compared to an on-premise 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 business model. As the customer base grows more self-serviceable an instance is the 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

In case of any queries please feel free to drop me an email at [email protected]