SaaS is not just SOA, S+S and Web 2.0

Microsoft has defined SaaS as "Software deployed as a hosted service and accessed over the Internet." (see here for the article). Although I don’t disagree with this definition (quite frankly, it’s hard not to), it seems a bit generic and could cause a lack of focus on what differentiates SaaS from the basic SOA concept itself. By being so generic, I’m concerned that what makes SaaS different could cause a bit of confusion to understand what SaaS is and what it isn’t compared to other IT concepts such as SOA, S+S and Web 2.0.

Gartner’s SaaS definition is “SaaS is defined as an application owned, delivered and managed remotely by one or more providers, where the provider delivers an application based on a single set of common code and data definitions, which are consumed in a one-to-many model by all contracted customers at any time, on a pay-for-use basis or as a subscription based on usage metrics.”

There are some key differentiating elements between these two definitions with major implications. For example, Gartner’s definition assumes a single instance, multi-tenant application. It also declares that all customers are contracted and pay for their services explicitly by a pay-for-use or subscription funding model. These two differences are important not because they are different from SOA and S+S but the downstream consequences of what they cause which makes them different. The metering capabilities based on a business’ revenue models and the support capabilities of a single code base, multi-tenant system architecture cause a business to really think about, and perhaps change itself, to optimize their business model and customer support model.

These two consequences are what keep me up at night these days. No, it isn’t the the system architecture of a SaaS-enabled service but the business need of either consuming or providing SaaS-enabled services. Although the SaaS system architecture is a major challenge in and of itself, as a techie I can conceptually envision a system architecture to solve this challenge.

I prefer to think of these two differentiating characteristics as the business needs for either consuming or providing SaaS-enabled IT services and the customer support capabilities for supporting them. These two characteristics are what make SaaS different. The rest of SaaS (eg the system architecture) is merely a specialized implementation of SOA, S+S and, in some ways, Web 2.0 in my opinion. That is, SaaS-enabled IT systems merely reflects a services system architecture designed to support specific constraints such as metering, role-based access, trusted subsystem security, activity-based service granularity, etc.

Getting the a) business models, b) customer support models and c) system architecture story to all fit together is really the challenge today. Overlooking any of the three components is VERY risky for successfully understanding a SaaS strategy for any organization.