InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

SaaS Architecture Maturity Model

Posted by Steven Robbins on Feb 25, 2008

Sections
Enterprise Architecture
Topics
Architecture ,
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
Re: One Architect's Managed Chaos... by Vasudevan M Posted
Re: One Architect's Managed Chaos... by Derek Gilmore Posted
  1. Back to top

    One Architect's Managed Chaos...

    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...

    by Vasudevan M

    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...

    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

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.