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)

Krishna Markande

Source: http://www.infosysblogs.com/engineering-software/2010/04/saas_implementation_-_choosing.html?soc=rssinf