|
Architecture Maturity |
|
rev. 25/04/2008
|
|
|
Architecture Maturity |
|
|
rev. 25/04/2008
|
|
There are five levels of maturity of an SaaS platform. The higher the level in this ranking, the easier to support and the easier to scale to more clients. We have to always be targeting level 3 or 4
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.