InfoQ

News

SaaS Architecture Maturity Model

Posted by Steven Robbins on Feb 25, 2008

Community
Architecture
Topics
SaaS
Tags
Maturity Models
Dharmesh Shah recently wrote about a maturity model of Software as a Service (SaaS) architectures. Drawing on previous thoughts from Gianpaolo Carraro that scalability, multi-tenancy, and customization through configuration are requirements, Dharmesh laid out 5 levels of a SaaS architecture maturity from 'Chaos' to 'Utopia' and provided his thoughts on the economics behind each one.
  • Level 0 (Chaos); Every time you add a new customer, you add a new instance of the software.
  • Level 1 (Managed Chaos): Every customer runs on the same version of the software and any customizations are done via configuration.
  • Level 2 (Multi-Tenant, Highrise): You've got all customers running on a single version of the software, and they're all running essentially on one "instance".
  • Level 3 (Multi-Tenant, Build-Out): This is when you've got multi-tenant, single version of the software model. But, you can scale-out (add buildings at will).
  • Level 4 (Utopia): This is like Level 3, except you've figured out an efficient way to run different versions of the software on different "instances".
Gianpaulo's original maturity model moved from custom version and instance per customer through single versions for all customers but each on their own instances and on to single version with single scalable instance for all customers. Dharmesh added the Utopian level in which you can also effortlessly deploy "sandbox" instances for any given customer.

Dharmesh's main point in discussing the model was:
One of the big advantages for SaaS start ups is the opportunity to be economically efficient along many dimensions through multi-tenancy. But just because the opportunity is there doesn't necessarily mean that every start up is exploiting it equally.

The key behind the economic advantages is an architecture that uses "customization through configuration" and intelligent data partitioning. Without these two elements, you probably won't be able to move past Level 1 (Managed Chaos) and recognize the efficiencies of multi-tenancy.

Noel Huelsenbeck commented that this maturity model might not fit your organization's business model:
Also wouldn't your price point and overall market dictate what level you end up at? There's a small chance an app like Quicken for the Web would make a customization and hence be at level 3/4 but if I'm a Fortune 500 company I would bet Salesforce.com will probably go back to Level 0 to get my business.
Commenter 'brk' made the observation that there are some big risks that come along with the big economics of being high on the SaaS maturity model. As you approach the point where all of your customers are sharing code, hardware (virtual or physical), and administration you run the risk of any small problem with a client can impact your entire client base.
One Architect's Managed Chaos... by Colm Smyth Posted Feb 25, 2008 7:38 PM
Re: One Architect's Managed Chaos... by Renie Chan Posted Mar 11, 2008 2:10 AM
Re: One Architect's Managed Chaos... by Derek Gilmore Posted Jun 14, 2009 8:37 PM
  1. Back to top

    One Architect's Managed Chaos...

    Feb 25, 2008 7:38 PM by Colm Smyth

    ... is another architect's utopia. Having a single version of the software that is customised using configuration is usually the end goal as it prevents having to maintain multiple branches of the source code.

    Naturally the more that you are benefiting from scaling a single source product across multiple customers, the more you need to broaden your regression testing for every single new release of that product. Having a single source product means that there can no longer be a "quick" enhancement because every time you expose a customer to a new release, it needs to go through a full integration and regression test. However, the increased cost of regression testing that common code is usually a worthwhile trade-off for the higher quality that all customers benefit from without customer-specific QA cycles.

  2. Back to top

    Re: One Architect's Managed Chaos...

    Mar 11, 2008 2:10 AM by Renie Chan

    This SaaS vs others debate is similar to Apartment vs independent house. Both has itsown advantages. SaaS may be useful primarily for smaller companies who dont need to bother about day2day administration and monitoring with better "perceived" reliability and availability. At the same time, it discounts a closer control in terms of extensibility and security. I dont see many big enterprises going in for SaaS model. Unlike web hosting, the confidentiality, agility and control aspects could deter them.

  3. Back to top

    Re: One Architect's Managed Chaos...

    Jun 14, 2009 8:37 PM by Derek Gilmore

    The SaaS architecture you select should be based upon your business model and the target market you are going after. There are several viable models and each are dependent on the target market and the amount of capital you have access to. I dive into this specific issue on my blog www.saaswonk.com

Educational Content

Brian Marick on 4 Challenges and 5 Guiding Values of Agile Software Development

Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).

Are You a Software Architect?

The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?

Agile – A Way of Life and Pragmatic Use of Authority

The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.

Getting Started with Grails, Second Edition

"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?

Using ITIL V3 as a Foundation for SOA Governance

Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.

Adrian Colyer on AspectJ, tc Server and dm Server

SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.

Adam Wiggins on Heroku

Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.

SOA as an Architectural Pattern: Best Practices in Software Architecture

For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.