Software-as-a-Service applications (SaaS) best practices

Choose the right technology platform

CIOs of companies are under constant pressure to adopt the latest and greatest technologies that they get compelled to make choices on technology platforms. However, building a SaaS platform needs careful evaluation, research, and analysis. From a business standpoint, SaaS platforms can have the capability to scale to an unimaginable extent. The technology and the architecture need to ensure there are no breaking points or hostage situations due to the choices made in the technology. Decision-makers need to consider the tech stack, learning curve, availability of developers, pricing model, support for automation, containerization, and more,  A tiny mistake can have a steep consequence in the future when the application scales or functional requirements change.

There is no one size fits all policy while building any software application and this applies to SaaS too. Whether to use AWS or Azure or Google for your cloud needs, whether to use React, Angular, Vue, or other JS frameworks for your front end, or whether to use Oracle, MSSQL, MongoDB or another database all require a good amount of research and analysis keeping the goals, objectives, and requirements in mind. 

Choose between multi-tenant and hybrid-tenant architectures

Multi-tenancy is one of the best architectures for building SaaS applications and the default choice for architects. Multi-tenancy allows a single instance of your service layer or application to serve multiple customers. However, a hybrid tenant architecture or a hybrid tenancy leverages both multi-tenancy and single tenancy to counterbalance performance and client functionality. Some requirements work well with multiple services having a single central database and some of them require satellite databases apart from the central database. This is mostly driven by the complexity of client requirements and the level of customization. The architectural principles of a hybrid tenant architecture are the same as a multi-tenant architecture thereby supporting high scalability and security. But at the same time, it is flexible enough to allow dedicated functionality using focused single-tenant services that can be called where required. Hybrid tenancy is growing popular day by day and the future of SaaS applications tends to move towards a hybrid tenant architecture. 

To understand this in simple terms, all the common functionality across clients is built and deployed publicly while all specific functionality for a client is built and deployed as private services to the SaaS clients.

Implement scalable architecture

The biggest mistake for any SaaS application is ignoring scalability of any kind. Architects need to keep in mind functional scalability, software scalability, and hardware scalability. SaaS applications are built differently as opposed to normal software applications. Once your SaaS application is live, making any unwarranted changes to the core functionality can be catastrophic affecting multiple businesses and their customers. Scalability helps increase or decrease cost and performance on demand and gives the capability to align the infrastructure to the varying workloads. Scalable architectures are more efficient and successful across alternating swings of businesses. Hence designing applications with scalability in mind is of utmost importance for SaaS architectures.

Microservices-based architectures offer great scalability and establish loose coupling between services. Serverless architectures with AWS lambdas or Azure functions achieve the highest scalability with minimum overheads.

Implement Security of services and data

SaaS implies multiple implementations by different businesses each having its own set of customers. This means threat modeling of SaaS applications is of paramount significance. Any lack of security means a breach of data across customers or even across businesses. Data breaches can be expensive and can be frightful to businesses. Even worse, data breaches can affect privacy and bring legal complications. SaaS applications must be built with good authentication, authorization, and role-based access control restricting users from changing or accessing data they are not allowed to access. Creating roles for end-users, administrators, super users, and vendors should be factored in while designing SaaS applications from a security perspective. 

Encryption of data at rest, data security, prevention of attacks, designing against spoofing and tampering requires following guidelines of OWASP and STRIDE, and more. Rogue competitors can bring down your servers by simple DOS attacks, suffering serious losses and losing valuable customers. While security is an investment, it is essential for the safety and stability of businesses. 

STRIDE - stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privileges. Every aspect of STRIDE needs to be carefully factored into the architecture of SaaS-based applications. 

Design your SaaS application for high availability

Downtime of applications is bad news for every business. SaaS applications carry the burden of multiple businesses and need to be built for high availability. While hardware can be purchased with more investment, downtime can also be caused due to poor software design or bad coding practices. Bad choices in using data types by developers or designing wrong caching mechanisms by architects in applications can bring down core services causing downtimes. SaaS applications cannot be built keeping a single client in mind as the use cases vary from client to client and user personas of end customers may differ across clients. This means generality against specificity leads to careful considerations at the code level, design level, and architecture level. 

CIOs and CTOs and even business leaders are tech-savvy and expect SaaS applications to be highly available with 99.999% up times. Therefore, architects and decision-makers have to keep availability as an important factor while designing SaaS-based applications.

Build a highly customizable functional and component architecture

As explained above, SaaS applications cannot be built keeping a single client in mind as the use cases vary from client to client, and user personas of end customers may differ across clients. One of the key factors clients look for in SaaS applications is the amount of customization it offers. They are constantly looking to decide between building custom applications that can suit all their needs or going for a SaaS application that can take care of most of the required functionality along with the ability to customize some of the features to their specific needs. 

Building a highly customizable architecture allows client-specific changes to be implemented without affecting other clients. This could mean a common larger database combined with dedicated micro databases for each client. Personalization is a highly desired feature and a must for all SaaS architectures. Themes, styling, language specific annotations, region specific information are all factors to be considered for personalization. SaaS clients require their customers to feel as connected to their brand as opposed to the feel of generic looking website. This means user experience customization for brand colors, fonts, images, placements and more. Apart from functionality, some clients have very unique and specific requirements that may not be required by other clients. This requires customization of components and building separate code bases that are separately versioned for maintainability.

The market for software development is highly competitive with so many choices in front of clients, the level of customization is a key factor in deciding on SaaS applications. Hence, the ability to customize a SaaS application becomes an important best practice for architects.

Develop a robust onboarding process in the architecture

Nobody likes filling forms and spending a lot of time registering to websites and applications. The attention span of a customer is limited and in order to keep customers engaged in our applications, every workflow and process needs to be as seamless and quick as possible.

Onboarding is the entry point for any SaaS application and a tedious onboarding process means losing customers immediately. A robust onboarding process keeps customers engaged with profile completeness bars, colorful wizards, part by part workflows, pop-up completions and a smooth user experience. Resilient workflows ensure continuing from where the user had left off in case the window was closed or connectivity issues or simply the user had to do something else. 

The goal of any SaaS application is to ensure customers are properly signed in, setup and explore using of the product. This implies, illustrating the feature usage, walkthroughs that are attractive but impart information at the same time. Most SaaS companies ensure enough automation in the onboarding process for ease of use and reduced efforts from the user. It is quite important for a SaaS application to have a robust process for onboarding that encourages them to use and get familiar with the product as much as possible. 

Adopt policy based data lifecycle management

Managing data is critical and a required practice across various industries. Data lifecycle is all about managing data as a resource which includes storing, accessing, processing, transforming and governing data at all stages of its use. If data is not versioned for changes, a bank will never know the previous address of a customer as the existing record gets overwritten with the new data. There are regulatory requirements across various industries to ensure historical data is available for a certain number of years. 

As SaaS application carries the burden of multiple businesses, any data management issue of an individual business using the product can have a direct impact on the SaaS providers. It can implicate financial, legal and even reputational risks with mismanaged data lifecycle. It is important to adopt good practices and governance in your data lifecycle management. Automating housekeeping is a best practice, timely archiving of data is another good practice of data management. By implementing policy based data lifecycle management in your SaaS architecture, you will be able to monitor data from ingestion to archival and be able to access data at a given point in time.

Operationalize auditing, tracking and monitoring controls

Although Auditing, tracking and monitoring data is a part of data lifecycle management, it is a separate design and architectural aspect to be kept in mind. Apart from data, user behaviors and actions are tracked and monitored for a multitude of reasons. Almost all analytics and data science features require tracking user actions and behavior for building recommendation engines, prescriptive analytics, validating feedback and reviews from customers and more.

This thought process needs to be imbibed at an early stage of the application definition process, architectural analysis and design. A best practice for operationalizing monitoring and tracking is to build horizontal components and data stores for clickstream data, logging and analytics.

Make it extensible for regulatory and compliance updates

Regulatory and compliance requirements are always a challenge but it also means acceptance by a majority of clients and improved sales. With GDPR, data privacy, and security becoming more and more important these days, implementing regulatory and compliance standards is winning half the battle. Some of the documents like CIS benchmarks help in defining these standards for different cloud implementations. Creating the rules and business logic governing compliance is not enough when building a SaaS application. The architecture needs to be extensible to allow appending or modifying new changes to the compliance and standards. 

Extensibility of applications can be achieved with loosely coupled architectures, interface based design, configuration files and more. 

Other considerations

Some of the other best practices while building a SaaS application are version control, action mechanism for customer feedback, self-service modules and standard integration APIs. SaaS application layers and functionality get complex over a period of time with continuous changes and features and a good version control of source code and binaries is vital for manageability. Standard integration APIs avoid vendor lock-ins and allow users to continue without switching vendors. Process improvement is a critical success factor that can be achieved by addressing customer concerns and taking feedback into consideration. Self-service portals reduce the burden and delays in interaction with customer support and increase likeability.