SaaS Implementation - Choosing the right SaaS maturity Level
Much before deep diving into implementing SaaS solutions, it is important that vendors sit back and analyze existing products, business goals, short term and long term objective as regards feasibility of 'SaaS-ification' and overall benefits during the process. It is important to be educated on the various maturity levels of SaaS orientation to succeed in this new business model.
What is this SaaS?
(this small section (definition of SaaS) is a little repetition from earlier blog..... just to help to recap )
SaaS popularly stands for Software as a Service. Though there are multiple terminologies in use (one of which is Microsoft's way of addressing the same as "Software + Service"), what is ultimately important is that the objective of such a model is met - which is to facilitate the use of the required software functionality as services from the vendor directly without being burdened with the responsibility of hosting the infrastructure and , maintaining the software on the consumer side. Indeed, the concept does look very interesting. Service consumers can now focus on their core business areas by consuming the required software services without having to pitch into their non-core areas like IT infrastructure maintenance, maintenance of an additional IT team etc .Definitely it is something very nice to have. I have blogged about this extensive in my previous blog here.
Are there any prescribed guidelines for rolling out SaaS solutions?
The answer is No. Surprised?
Many ISVs already have a huge list of Enterprise Products in their portfolio. These products are of varying proportions ( small, medium and large sized), servicing various domains and business functionalities. A significant challenge that needs to be addressed is with regard to how SaaS based solutions of such products can be rolled out cost effectively (with less effort, optimized infrastructure cost, and effective operational & maintenance cost as primary drivers) and within highly aggressive timelines.
Remember, the core objective of SaaS is to enable a set of business functionalities as hosted services, which can serve multiple customers and enterprises (as also referred to as 'tenants' in the SaaS/Cloud Computing world). It is considered to be most optimum when all tenants are served with the required (and agreed upon) performance and scaling parameters satisfied with same single source code in execution. But what we are talking here is the most optimal or highest maturity level of the SaaS model.
However, it also important for SaaS vendors or implementation experts to understand various options that are available to service tenants to satisfaction, rather than directly jumping onto the highest level of the SaaS model. Let us try to understand the various options that one can look into.
Level 1 - Ad Hoc/Custom:
In the first level of maturity, there will be separate instances of the source code hosted for each customers. In this level, code would have specific customization required for those customers as the multi-tenancy would have been not addressed at architecture level.
As we can understand from the definition above, the scenario is simple. Such products are not expected to undergo architectural changes or rework in order to add the mandatory features of SaaS such as multi-tenancy, data separation, scalability etc. In such products, multi-tenancy is provided by hosting dedicated instances for each customer.
This is still acceptable when the customer base is small and the level customization needed is minimal. Because, with cost effective technologies for optimal infrastructure usage popularly available today(yes, you are right, I am referring to Virtualization), one needn't worry much about infrastructure overheads(though licensing cost is still applicable). Proven Virtualization products available in the market today help achieve optimal infrastructure usage easily. However, one needs to thoroughly analyze as regards how many customers are targeted, what would be the operational and maintenance cost (for those many dedicated instances ) etc. (Remember, in such deployments, critical mechanisms such as proper metering (as per various subscriptions required) , automated billing (integrated appropriately), integrated monitoring etc would not be in place to make it cost effective.) But this methodology may be suitable when the customer base is small , the required level customization is considerable and re-architecting the whole product extremely complex and time consuming (remember, turnaround time is important where one wants to take competitive advantage)
Level 2 - Configurable:
The second maturity level provides greater program flexibility through configurable metadata, which allows multiple customers to be served separate instances of the same application code.
This option is very similar to the Level 1 option above. However, in this case, the product architecture anddesign has been changed in such a way that, personalized customization for different customers (depending on their business needs) are provided through detailed configuration options. The overhead of having to maintain multiple code bases is reduced (as personalized instances of the same code base are hosted) This simplifies maintenance by having a single,common code base.
Level 3 - Configurable, Multi-Tenant-Efficient:
The third maturity level adds multi-tenancy to the second level, so that a single program instance serves all customers.
Level 3 of SaaS maturity enforces the manadatory requirement of 'multi-tenancy'. This should allow more efficient use of server resources without any apparent difference to end users of the single instance in execution. To achieve this, the product has to be re-architected such that, it not only provides configurability, but also uses the necessary partnering software optimally (such as single web server, app server, data base server etc as is applicable for the product). However, this approach has its own limitation, which is scalability. While focusing on architectural and design changes in the product to achieve multi-tenancy, it is possible that scalability considerations are compromised because of the possible need for stretched effort and timelines necessary to achieve scalability depending on the 'As-Is' architecture, current technology limitations etc. Attempting to achieve scalability would have a major impact on architecture, selection of supporting products etc apart from design or code changes required for multi-tenancy.
Level 4 - Scalable, Configurable, Multi-Tenant-Efficient:
At the fourth and final SaaS maturity level, scalability is added through a multi-tiered architecture supporting a load-balanced farm of identical application instances, running on a variable number of servers.
The system's capacity can be increased or decreased to match demand by adding or removing servers, without the need for any further alteration of the application software architecture. The architecture would consider various technologies available for scalability such as database clustering, load balancing, appropriate partitioning etc, by leveraging appropriate products and components.
Which Maturity level to choose then?
One needs to analyze based on As-Is architecture, time and effort required for re-architecture or code changes, updates on competitor strategies and immediate steps (so that you don't lose on competitive edge), feasibility of migrating from Level1,2 to higher levels as per the strategy/roadmap, cost benefit analysis (to maintain the multiple versions, instances, software required for hosting etc) and clear visibility on market projections etc. There are many other factors for consideration, but at the end one needs to analyze based on exact need on a case by case basis. Otherwise, choosing wrong model/maturity level for wrong scenario can result in failure such as loss of market due to competition (by delayed go to market, or insufficient features etc), or leaking maintenance and operational cost, or breaking of the SaaS architecture (due to high degree of configurability, lower scalability etc).
