In continuation to my previous blog on Top 10 Critical NFRs for SaaS application, let’s look at the next 5 critical NFRs that have a deep impact on the SaaS solution architecture.
Multi-Tenancy is the most complex NFR that cuts across the SaaS application as well as the other NFRs. Multi-tenancy is a design approach that facilitates a single instance of a system (saas application) to function as logical isolated instances serving the customers. Multi-tenancy architectures are complex to design but once done properly can help in significantly reducing the operational expenses (compared to a single tenant or hosted model). The complexity further increases with concepts like tenant hierarchy and virtual tenants, which provides sophisticated mechanisms to deal with varying degrees of multi-tenancy. Multi-tenancy can be applied to both web/app layer and database layer. However, it’s also possible to apply only at the web/app layer keeping the databases isolated between tenants (customers).
SaaS model of delivering applications inherently brings in the complexity of addressing multiple, (sometimes) conflicting requirements. Many SaaS applications continue to remain in single tenant/hosted model due to this reason. However, when carefully analyzed and designed, each layer of the SaaS application can be built with sufficient configurable options, which can help in achieving the customer specific requirements through configurability instead of hardcoding. The standard layers that have to be considered for configurability are UI, Branding, Authentication, Role/Privileges, business rules, business processes, integration and database.
Security of a SaaS application has to be looked as a comprehensive integrated engine that connects the subscription, tenant level security, usage restrictions, data restrictions, encryptions, user and role level privileges. Taking a holistic view of all these aspects in the design of security architecture is the key step for a successful SaaS application. Having this consolidated as a unified engine not only helps in manageability of the system but also facilitates changes in a systematic manner.
SaaS applications seldom are used out of the box by customers. While customers understand that SaaS applications cannot be drastically customized to meet the specific needs, but they still want to make those fine changes that will help in fitting the application with the practical implementation level details. Given the revenue model of SaaS, there is no luxury of customizing the application for each customer. This is where the configurable architecture comes to play. In addition to it, there could be certain areas in the application that will have to be extended to meet the additional requirements. For example, a customer might want to capture additional fields as part of a standard application screen. In this case, you should be able to include, store and manage the additional fields but only for that customer. Rest of the customers should not be able to see this change.
Pro-active monitoring of SaaS application’s health can go a long way in ensuring the availability of the system and tackle any unexpected scenarios in production. There are multiple levels of monitoring including application layer monitoring, database layer monitoring, application usage monitoring, error monitoring, trial monitoring, event monitoring and alert monitoring. It’s important to design the architecture in a way the data points required for the above mentioned monitoring are easily available. It’s also important to track this information at a tenant level so that responses to customers can be expedited.
I hope this blog series helped in getting a perspective of various NFRs and how they are linked to a SaaS application.
Latest posts by Janakiraman Jayachandran (see all)
- Why enterprises should standardize Digital Application Management - July 17, 2017
- Top 10 Critical NFR for SaaS Applications – Part 2 - May 26, 2016
- Top 10 NFR in Software Architecture – Part 1 - April 29, 2016