I am big on using the Maturity Model concept to evaluate the architecture, process and deployment maturity. In the case of Software As A Service, a simple 4 step maturity model can be defined that would demonstrate how a SaaS vendor should consider building their product and how they can be assessed from a technical maturity and viability stand point.

I will describe the Maturity Model based on the Anatomy of SaaS application posting I did a while back. In that note, I described how a typical SaaS architecture would look like. We can use the same architectural elements to describe the Maturity Model for a SaaS application.

Level 1: Adhoc SaaS architecture

This is a simple model to follow and is probably how many SaaS vendors actually started off. The product is deployed in a “cut and paste” fashion for each customer. Thus each customer has their own dedicated instance of the software. This model obviously has drawbacks, but it also does have certain benefits. You cannot beat this model in terms of control and security. However these come with the price of scalability, maintainability, upgradability and several of the other common “ility” factors.

Level 2: Shared Core Functions

In this level of maturity, we are starting to see some of the reusability that becomes the real value of a SaaS solution. Software, process and design is re-used in terms of the “Core Functionality” of the SaaS product. This not only helps in the technical architecture maturity, but plays a huge role in the standardization of business processes and thus the overall business maturity is increased and cost avoided of having to support multiple, isolated business processes or functions.

If I were to gamble, I would bet that many SaaS vendors are inherently in this level of maturity. This does provide some basic level of re-use and addresses some of the drawbacks of Level 1. However, we can do better. Let’s look at Level 3 and 4.

Level 3: Multi-tenant and Configurable

This to me is a stepping stone level of maturity. It addresses some key drawbacks of Level 1 and 2, but really provides a path to Level 4. In this level of maturity, we achieve real multi-tenancy and configurability. The client specific tenants are typically only hosting code specific to a client and the configuration settings (generally XML or database driven) for a client. To the extent possible, we work in a true and complete multi-tenant fashion. This allows us to realize the core benefits of SaaS in terms of scalability, re-use, upgradability etc. When you read Level 4, you will see how Level 3 is a stepping stone to it.

However, it is important to realize that getting from Level 2 to Level 3 is probably where the most time and money will and should be spent by a SaaS vendor. As I am really a gambler by nature, I would bet that the most successful SaaS products would be somewhere between Level 2 and 3, probably closer to Level 3 or have concrete plans to get closer to Level 3.

Level 4: Multi-Tenant-Efficient

Level 4, the final level in this 4 step maturity model is often defined as Nirvana in other maturity models. With respect to SaaS, I am focusing on the true multi-tenancy of a SaaS solution as being the definition of this level. It looks a lot like Level 3, with a Tenant Load Balancer thrown in. This effectively means that there are no client specific tenants. Even the client specific configuration, client specific code etc that were in client specific tenants with Level 3, now are residing on shared tenants and are invoked on demand. The tenant load balancer, creates virtual client specific tenants on demand, as close to session-scope as possible (now we are talking Nirvana). However, it would be good enough if the load balancer is able to create and manage to virtual client specific tenants that can scale and grow based on demand and forecasting of demand from a client.
This was a very high level overview of a maturity model for SaaS. Subsequent blog postings will drill into some more details.