Let’s Talk About SaaS

Before I write a blog post, I spend some time on understanding the concept from a geeks perspective. The intention is to simplify the concept and make it easier to understand / imagine (abstracting hi-tech lingo).

Let’s talk about SaaS… SaaS stands for Software as Service, which is becoming very popular trend in the software industry. Let’s try to understand how it’s different from have we have now (& had in past).

Hotmail.com, one of the most used online email software that is delivered as a service to end users. Now what is wrong in the hotmail that stops me tagging it as SaaS ? Salesforce.com is offering in-the-cloud version of CRM software that can be accessed over Internet. Both salesforce.com and hotmail doesn’t require any installation at user side and serves multiple users from single instance.

Salesforce delivers CRM, a line of business application and changes $59.00 per user per month, with no upfront cost. On the other side hotmail is a generic free email service available to internet users. The nature of the service is what differentiates a SaaS applications with other internet based (consumer) applications. A line of business SaaS application is a paid solution that addresses a business problem and requires a customized delivery channel.

When you want to get a line-of-business (LOB) application like an ERP; Currently, you will have to check for an ERP vendor, finalize the best fit solution, buy the hardware to install and plan for maintenance and customization. In the SaaS world the software is paid as it is consumed and the end user required no software or infrastructure to buy, install and maintain.

Though the concept sounds very exciting, there are lot of challenges that needs to be addressed for achieving the SaaS delivery model. There is a complete lifecycle considerations starting from Discovery, SLA, Security, Performance, Deployment etc.; which is beyond the scope of this topic; I’ll only mention the key considerations.

On the top is the multitenancy concept. This is like you have tenants in different apartments of a housing complex, sharing some common facilities (Beside having their private amenities). In SaaS, each tenant is the customer/ consumer of the hosted service instance. The multitenant-efficient SaaS offering supports a data model that allows sharing of the database and resources, while protecting data access to each of the individual tenants.

Next thing to consider is the ability to provide customized service based on the tenant while running a single instance of the service. This can be achieved by using metadata that describes the attributes of a tenant and map it with service. In other words, the behavior of service is defined by the metadata associated with each tenant. The level/ effort of customization required for each tenant is reduced by having the metadata.

Design for Upgrade

While this blog is more inclined towards the Agile software implementation, one of the incident happened last month has forced me to pen in a few thoughts on software architecture. We developed an application with Microsoft Office SharePoint and InfoPath. The development started a year back with Office 2003 and now it’s migrated to MOSS 2007. The application has been simply architected, keeping in mind the customer requirements. As mentioned in one of my previous post, the “tale of never ending requirements” hit us in the middle of migration. A new product release always carries additional/ improved features for addressing business problems. During the migration, it makes sense to evaluate new features and analyze the possibility of leveraging them for addressing business problems (in better way). Having said this, the solution architecture must support the up-gradation scenario with reasonable amount of time and effort.

Design decisions while architecting a software solution are derived from various sources like availability of resources, customer needs and preferences, business domain etc. However, the basics remains unchallenged for every implementation scenario. One of such fundamental is explained in this great quote from “Software Architecture in Practice, Bass, Clements, Kazman”

"Architects make design decisions because of the downstream effects they will have on the system(s) they are building and these effects are known and predictable. If they were not, the process of crafting an architecture would be no better than throwing dice. "

No architecture can be perfect, in-fact you do a tradeoff between software systems attributes to come with the best possible solution for specific business requirements. Thinking of an architecture generally brings into mind the concepts of layers and tiers (layers are logical separation of components while tiers are physical). Each layer will add an additional message call which will hit the response time. Then why architects still model the system in separate layers and takes the performance hit? The answer is “to make complex things simple”. More complex the system requirement is, more are the number of layers that are generally included in the solution architecture.


Coming back to our scenario, how would an architecture can support the technology up-gradation process? I believe there can not be a complete answer to this; unless you understand the vision of the technology/ product company, it’s difficult to handle this 100% with architecture. However, there are some basic principles that remains unchallenged. XML functional calls, loosely coupled layers, different tiers for application and database etc. are few checks to handle the situation .

One important point to consider: If requirements are simple then it’s not recommended to take the performance hit by including layers. Trying to over simplify the system will make it complex .