SaaS Architecture and The SaaS Maturity Model

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.

Community

Google+

And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:

Google

Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Answers.OnStartups.com

Subscribe to Updates

 

30,000+ subscribers can't all be wrong.  Subscribe to the OnStartups.com RSS feed.

Follow me on LinkedIn

OnStartups

Current Articles | RSS Feed RSS Feed

SaaS Architecture and The SaaS Maturity Model

 

I've recently been thinking a lot and discussing with my colleagues at HubSpot the implications of Saas (Software as a Service). We're looking at this from many angles: operational cost, development cost, support cost, etc.

One of the big advantages for SaaS startups 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 startup is exploiting it equally.

In my online readings and research, I came across an article about the SaaS Simple Maturity Model. Though I'm not particularly fond of the name, the framework is very useful.

Here's my (even simpler) interpretation of the levels of maturity of a SaaS architecture:

Level 0 (Chaos); Every time you add a new customer, you add a new instance of the software. If the customer needs something specific, you change that software instance. Each customer is essentially running on their own "version" of the software. Yuck!

Level 1 (Managed Chaos): Every customer runs on the same version of the software and any customizations are done via configuration. But, you still have different instances for each customer (their own website, their own virtual server, their own physical server, etc.).

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". The good news is that you're getting the benefits of multi-tenant (sharing resources across customers). Even better is that you're not writing custom code for each customer -- everyone essentially runs on the same version. The big challenge is that as you add more floors to your building (to stretch the analogy a bit), it gets more and more expensive. And, there are limits to how high you can build to accomodate a large number of tenants.

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). This is optimal because instead of letting the architecture decide how many tenants you put into a building, you can let the economics decide. And yes, there is an optimal number of tenants per instance and this number varies on your situation.

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". You're doing this not because you're writing custom code for a customer, but because you want to run different code for different customers -- to try things out. The best example is having an "early adopter" instance where customers that want to use your latest and greatest features can do so. Helps them. Helps you. Helps everyone. As long as you're efficient about release management. [Note: This last one is my own fabrication and wasn't part of the original framework referenced above).

HubSpot, my startup, is currently at a Level 2 and shooting for Level 4 this year (with a brief stop at Level 3 as an intermediate point). The good news is that we're adding cusomers quickly so this is more than an academic exercise for us. We can actually rationalize the investment in terms of economics because the benefits that we get from improvement actually makes us money.

---

Are you a superstar startup developer in Boston? Consider applying to HubSpot. Help us figure out how to delight thousands of customers and make money at it. Share in the fun and success. You can email me at dshah [@] onstartups.com. If you have what it takes, we've got some awfully smart and passionate people you'd enjoy working with.

Posted by Dharmesh Shah on Wed, Jan 23, 2008

COMMENTS

Nice descriptions, I'm at level 2 as well. It'd be nice to move up, but I think the higher you go, the less the return (unless you have a particular need). What I mean is, the incremental savings from moving 0 to 1 is greater than 3 to 4, would you agree?

posted on Wednesday, January 23, 2008 at 3:54 PM by Phillip Zedalis


Phillip: I think on a percentage basis, the returns do likely go down at the higher levels. If you're at level 0, even if you have minimal customers, you're awfully inefficient and spending a lot of money that might be saved.
But, one thing I've experienced is that as you get to the higher up levels, you tend to have more customers -- so in an absolute sense, the savings can be very significant.
For example, when you go from 2-3 or even 3-4 and you have hundreds or thousands of customers/tenants, the economic impact can be very high.
Of course, your mileage may vary and some restrictions apply. :)

posted on Wednesday, January 23, 2008 at 4:11 PM by


Good point on the %'s versus the actual amounts. At my stage (x < 1000 customers), I don't really need to get to level 3 yet. However I know that when it's time to build up, it will be critical to be at level 3 for sanity's sake.

posted on Wednesday, January 23, 2008 at 4:16 PM by Phillip Zedalis


I think that the returns scale fairly consistently with the investment, until you get to the last phase.
Kind of like the infrastructure costs of adding "more 9's" to your SLA. Going from 99, to 99.9 to 99.99 is economically efficient in most cases. Going from 99.99 to 99.999 takes a little bigger bite, but it's worth it when your customer base is growing. Going from 99.999 to 99.9999 takes a HUGE time and money investment to eliminate the chances of some really rare edge-cases from biting you in the ass.
As you scale up and add more customers, the chances for a small problem to have a huge impact are pretty significant. I think that with almost any startup, even the users/customers that seem fully "bought in" are still very skitterish for the first couple of years. A relatively small problem can spook a big part of the customer base, possibly creating a cascading customer exodus. So, there is some "insurance" to be had in maturing your architecture proactively instead of reactively.
It's also important to keep these levels in the back of your head as you're building up the software architecture to make sure that it can scale up and out fluidly. Seemingly small decisions now can impose large roadblocks further down the road if you're not careful.

posted on Wednesday, January 23, 2008 at 4:35 PM by brk


As we've grown we've had VC's tell us the only way to get their cash, and the hyper growth, is to provide a platform that does not have multiple instances (at least Level 2). They want as many customers on one "instance" as possible. However we have chosen to forego the VC route and customize our applications, which will keep us at level 0/1 for the short term and possibly the long term. It's tempting to raise some cash, reduce the customization and cost of supporting multiple instances and move up the levels but will it be worth it?
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.

posted on Thursday, January 24, 2008 at 1:41 AM by Noel Huelsenbeck


Nice list. I believe Levels 0 and 1 can be combined under one category: the never-ending Beta, because it never matures through new releases that add features but don't solve the vendor's (or customer's) problems. An application vendor running a Level 0 or 1 over N instances opens themselves up to all kinds of new and wonderful low-value tasks as they seek and destroy instance-specific problems related to custom mods and add-ons requested by the customer...one of the very reasons an application is delivered as a service at all. Sigh...back to work in the Level 0/1 application.

posted on Thursday, January 24, 2008 at 3:24 AM by Luke Smith


Great article and breakdown. We are somewhere between level 3 and 4. We have everyone running on one of two versions. We don't do any customized instances, but we do some times release to "beta" customers in a separate instance. We have all the architecture setup to be level 4 but don't have the number of customers to get the full benefit.
I can't imagine trying to do what we are in level 0 or 1. Even at our level (~140 customers that would be instances) it would be quite a task to manage. Planning from the beginning to be level 3+ seems like the way to go to me.
Good luck on your architecture upgrade.

posted on Tuesday, January 29, 2008 at 5:21 PM by Justin @ MerchantOS


I think most startups would be best to plan to start at level 3 or 4. It saves major a rearchitecting and the overhead in the short term is very minimal, if you do it right.

posted on Saturday, February 02, 2008 at 1:51 AM by Patrick Fitzsimmons


We are having a web based application developed in Microsoft technologies (ASP.net 2.0 & MS SQL Server 2005). The current architecture of the application doesn’t support to migrate to SAAS based platform. We are planning to offer our application as a subscription based model. This subscription based model is different than most offered in the sense our application will run in other domains hosted on the same server. Customer create domain, or host their domain with us and after they signup from our system, our entire application can be accessible via their domain. However we are stuck with architecture and a major maintenance question. 
 
 
 
1) What is the best approach we need to take? What sort of architecture is required? Can such an application be engineered with Microsoft .NET studio or any other tools required? 
 
 
 
2) If we have say 1000 customers, and we discover a bug. To fix that bug we do not want to go to each of these 1000 domains and update DLL or apply fix. Rather we look for updating code at one location and that auto corrects across all hosted sites. 
 
 
 
Please guide us. We do not have that much budget to get paid professional expertise and looking for knowledge sharing with you individuals. Any article links, your inputs and guidance we will appreciate most.  
 

posted on Wednesday, March 25, 2009 at 11:28 PM by Rasik Godhani


Odd place to ask - given the blog date. 
 
It depends how different your domains are. If they are essentially the same, then you only need one app and discern the customer based on the URL. Very easy. 
 
Phillip

posted on Wednesday, March 25, 2009 at 11:35 PM by Phillip Zedalis


But, 
 
 
 
If we have say 1000 customers, and we discover a bug. To fix that bug we do not want to go to each of these 1000 domains and update DLL or apply fix. Rather we look for updating code at one location and that auto corrects across all hosted sites.  
 
 
 
 
 
 
 
Please guide us. We do not have that much budget to get paid professional expertise and looking for knowledge sharing with you individuals. Any article links, your inputs and guidance we will appreciate most.

posted on Wednesday, March 25, 2009 at 11:39 PM by Rasik Godhani


What is the way to fix the bug in SAAS based application if we hav more customers

posted on Wednesday, March 25, 2009 at 11:40 PM by Rasik Godhani


REST vs. SOAP (Making the Right Architectural Decision?) 
 
 
 
We are Developing Applications with SaaS (Software as a Service) using VS 2008 and SQL 2005 Database. 
 
 
 
There are two popular programming models available for interacting with the web services (WS): 
 
 
 
1) REST-based. Representational State Transfer is a new way to create and communicate with web services. In REST, resources have URIs and are manipulated through HTTP header operations. 
 
 
 
2) SOAP/WSDL-based. In traditional web service models, web service interfaces are exposed through WSDL documents (a type of XML), which have URLs. Subsequent message exchange is in SOAP, another type of XML document. 
 
 
 
 
 
So which is the Right Architectural Decision for using REST or SOAP and why?  
 

posted on Monday, March 30, 2009 at 11:49 PM by rasik godhani`


The decision on REST vs. SOAP depends upon the consumer or end user of your web services. Both are viable. In some situations you can use both. 
 
If you are using web services internally use SOAP. If you are working with hardcore 3rd party engineers use SOAP. If you have non-technical business people who need to look at your data model in XML format use REST.  
 
This especially true if you don’t want to explain to them a complex XML hierarchy. If you have junior level engineers trying to slap together integrations quick use REST. 
 
Hopefully this clarifies things. 

posted on Sunday, June 14, 2009 at 8:13 PM by Derek Gilmore


I have a slightly different take: 
 
Option 1: 100% Virtualization (using Virtual Machines (VM)) at all layers, multiple databases, multiple versions of the application, each tenant gets their own VM slice.  
 
Option 2: Virtualization at the application layer (hybrid). This involves multiple databases on in single server via federated database, scripted provisioning and manual customizing for each tenant. The advantages: Low to medium start up costs, medium difficulty to design and build.  
 
Option 3: Single application deployed on a web farm, Single database instance leverage or federated DB. Customization is done dynamically by the customer via the application. 
 
Option 4: True multi-tenant SaaS. Single database, Single instance, Single app. Customization is done dynamically by the customer via the application. 
 
I drill in a lot further on my blog.www.saaswonk.com 

posted on Sunday, June 14, 2009 at 8:20 PM by Derek Gilmore


What is the best approach we need to take? What sort of architecture is required? Can such an application be engineered with Microsoft .NET studio or any other tools required?

posted on Tuesday, July 21, 2009 at 3:03 PM by sohbet


Comments have been closed for this article.