Implementing the SaaS Maturity Model

When it comes to SaaS maturity model, maturity is not an all-or-nothing proposition, as a SaaS application can possess one or two important attributes and still manage to fit the typical definition and meet the essential business requirements. So in that case the app architects may choose not to meet or fulfill other attributes, especially if in so doing the action would be rendered cost ineffective. Broadly speaking, SaaS maturity can be demonstrated using a delivery model with 4 distinct levels, with each level distinguished from all other previous ones by simply adding one, two or more attributes. The four levels are briefly described below.

Level I: Custom/ Ad Hoc 

This level of SaaS maturity resembles the conventional ASP (application service provider) software delivery model with its origin in the 1990s. At level I, each client has his/her own personalized version of a hosted application, which he/she runs an instance of the software app on the host’s servers. In terms of architecture, software at level I maturity closely resembles traditional line-of-business software sold earlier on, in that multiple clients or customers within a single organization are able to form a type of connection to a single instance running on the server. However, the instance if fully independent of other processes or instances that the host runs on behalf of all its other clients.

Typically, conventional client-server apps can be relocated to a cloud-based model usually at the initial level of maturity, and with lesser development effort or without having to re-architect the whole system by building it from scratch/ ground up. While this level has few benefits of a typically mature SaaS solution, vendors can reduce costs by simply consolidating server hardware, administration, etc.

Level II: Configurable 

This is the 2nd level SaaS maturity is where your SaaS vendor hosts a totally different instance of the SaaS application for each tenant or customer. While each instance is personally customized for each tenant, all instances at this level utilize similar code implementation. Moreover, the vendor meets the needs or requirements of the customer by offering in-depth configuration options that enable the customer to alter the look of the application as well as its behavior to its users. And while they resemble one another, particularly at the code-level, every instance remains completely isolated from the others.

Migrating to a code base for clients of a vendor significantly reduces the service requirements an application, as any changes effected on the code base maybe issued to all customers of the vendor at once without upgrading or performing slipstream customized instances.

In a SaaS maturity model, repositioning a conventional application as cloud-based at the maturity level may require additional re-architecting compared to the previous level, especially if this application has specially been designed for personal customization instead of configuration metadata. Just as the first level, level II requires the vendor to offer sufficient hardware or storage to accommodate multiple application instances running parallel/ concurrently.

Level III (Multi-Tenant-Efficient and Configurable)

Level III maturity is characterized by the vendor running a single instance serving each client with configurable metadata to provide unique, customized user experience and unique feature set. Security and authorization policies ensure the safety of each customer’s data, which is kept separate for every customer. In fact, there’s no clear indication that the instance is shared among multiple users/ tenants (from the tenant’s perspective).

This eliminates the need for server space to accommodate the many instances, allowing for efficient use of scarce computing resources than level II, thus, translating to lower costs. However, a notable disadvantage of this particular approach is application’s scalability, which is limited.

So unless database performance is managed by partitioning, the application may be scaled by scaling up (moving to a much more powerful server), until diminishing returns render it more costly to add extra power.

Level IV (Scalable, Multi-Tenant-Efficient, Configurable)

This is the final or the last level of maturity where the vendor hosts several clients on a load-balanced group of identical instances, but with each client’s data stored separate, and configurable metadata offering each customer a phenomenal user experience and unique feature set. A SaaS system can be scaled to a large number of clients, as the number of instances and servers on the backend can be adjusted to meet demand without you having to re-architect the application. Moreover, fixes or changes can be easily rolled out to multiple tenants just as easily as with a single tenant.

Choosing an Appropriate Maturity Level (targeting a maturity level for your application)

While you might expect this fourth or final level to act as the long-run goal for your SaaS application, this is not always the case. In fact, it could be more useful to view the maturity of SaaS as a continuum (progression of elements) between isolated data +code in one hand, and shared data+ code on another. But where your application falls along this continuum will largely depend on your business, operational and architectural needs, as well as customer considerations.

Scalability

Thousands of people can use large-scale software simultaneously. Anyone with experience developing enterprise applications knows the challenges of developing a scalable architecture. Scalability is a crucial aspect of a typical SaaS application as you are developing a unique internet-scale system that will actively support a broad user base that could potentially reach millions of users.

Applications (in SaaS) can be quickly scaled up (moved to a larger and more powerful computer server) as well as scaled out (run on more servers). At the cloud-based level, scaling out is considered the best option for extra capacity, as portrayed in SaaS maturity model, because a properly-designed SaaS app can be easily scaled out easily to a large number of computer servers, with each running one, two, or more similar instances of that application.

Conclusion

SaaS represents an architectural model that is built on the foundation of massive scalability, multi-tenant efficiency,as well as metadata-driven configurability to provide great software inexpensively to both existing and potential clients. Adopting these principles can help in implementing SaaS maturity model and place you on the right path to completely transforming the manner in which you depict the long-tail business.