SaaS Simple Maturity Model
Buena guía de Gianpaolo's Blog:
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.
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 :))
areudirty
pixelskylines
tangentwithtanner
2087
yousharknotpass
