SaaS Simple Maturity Model

 A few days ago, Fred and I hosted a BoF at the OpSource Saas Summit. It was a great discussion.


Most of the 15 people who came to the BoF were startups exec. the few others were architects / director of dev. at larger companies. The discussion was not  whether they should move to SaaS (they were convinced of that already); but very much how to successfully implement SaaS.


As you can expect, there is no silver bullet for implementing SaaS and a lot of passionate exchanges of opinion took place. We quickly agree though that fundamental requirements one cannot overlook are:

  • scalability (with SaaS applications can potentially reach Internet scale),

  • multi-tenancy (this is to keep under control the cost structure, one cannot have 1000s of customer, each on a separate instance) and

  • customization through configuration (related to previous point). 



To facilitate the discussion Fred and I introduced a basic SaaS maturity model. (see below)





Level 0: (Ad-hoc / Custom)

At its level, nothing is done for allowing multiple tenants running on the same instance. The only way to support multiple customers is to serve them with different copies of the software. Furthermore, because little is done to allow customization through configuration, each copy includes specific customer customizations, in the forms of custom extension code, custom processes, custom data extensions. Needless to say that although “technically” the software is delivered as a service (i.e. the software does not run on premise) economy of scale cannot be achieved as each customer runs a different instance of the software. Although this could be a starting point to validate the business model, one has to move quickly up. Managing 1000s of customer at this level is very difficult.


Level 1: (Configurable)

At level 1, the software can be tailored  for each tenant via configurations (no custom code), all the tenants use the same code. However at level 1, the architecture is still not multi-tenant, each customer runs its own copy (albeit the same). The separation can be either virtual (virtual machines on a same server) or physical (running on separate machines). Although much better than previous level, the architecture allows customization through configuration (code base is the same), the computing power is not shared among the instances and therefore the provider cannot achieve economy of scale, putting it at a competitive disadvantage vs. a multi-tenant solution.


Level 2: (Configurable, Multi tenant)

At this level. the application architecture includes the multi tenancy concepts. Akin to level 1, the UI can be customizable per tenant, so can the business rules and the data model. The customization per tenant is fully performed through configuration and is performed through a self-service tool, getting around the need of provider intervention. It is almost the SaaS "perfect case"; the only big piece missing at Level 2 is the capacity to scale out; the data partitioning is such at this level that growth can only be achieved by scaling up.


Level 3: (Scalable, Configurable, Multi tenant)

The highest level in this model. At this level, the architecture allows all the capabilities of level 2 (multi-tenancy, configuration) plus the scale out of the application. New instances of the software can transparently be added onto the instance pool to dynamically support the increasing load. Appropriate data partitioning, stateless component design, shared metadata access are part of the design. In this model a Tenant Load Balancer (round robin, rule based…) is introduced, maximizing the utilization of hosting resources (CPU, storage etc.); the total load is adequately distributed over the entire infrastructure. The data is also periodically moved to average the data load per instance. At level 3, the architecture is scalable, multi-tenant and customizable via configuration.



BoF attendees found the model quite useful but also pointed that it is a bit too artificial and does not include nuances that customers often requests such as data isolation (for perceived security enhancement), does not touch upon versioning and upgrades of the single instance (are all tenants migrated at the same time?!) . Finally, this model does not tell how to move from level N to N+1; this will be the object of future posts (once we figure that out ourselves :))



What do you think? Please send feedback, comments, questions via comments here or linking to this post

Comments (10)

  1. ciruli says:

    Did you talk at all about implementation of a "Tenant Load Balancer?"  Is it assumed that this is an "exercise left to the reader" or did you discuss tools that might give this capability?

  2. gianpaolo says:

    Tenant Load Balancer is a pattern we believe will be required but have not gone into the implementation aspects… we eventually will describe it in more detials though.

  3. ciruli says:

    (shameless plug here)As a provider of .NET-based distributed computing systems, my company (Digipede) feels that we have created an ideal tool for just such applications.  If you’re interested, I’d be happy to invite you to a webinar (we give them every couple of weeks)…

  4. Yesterday morning I presented at the Sydney sessions of the Software as a Service (SaaS) seminar series….

  5. [Daily Post from Cesura] Business Certainty: Following Google into the Fray "The on-demand model is often thought of on an enterprise scale, or as something that will increase efficiency and communication on a network level. Many do not think

  6. En estos días estoy trabajando sobre este tema: Software as a Service, una nueva "buzzword" que se ha…

  7. Just for fun, I looked at the blog engine stats and compiled the Hit Parade of the blog entries I posted

  8. Wriju's BLOG says:

    Must read Gianpaolo’s BLOG at My 2006 SaaS Posts Hit Parade . In case if you feel that you need more

Skip to main content