Software as a Service (SaaS) is getting a lot of attention these days. The concept of SaaS is not new and has existed for a while. It has been referred to by other names such as Application Service Provider (ASP), Managed service provider (MSP), on-demand services, cloud computing, utility computing etc. SaaS involves exposing applications over the network on a subscription basis with the pay-as-you-go model. This model was earlier popular with only small businesses who didn't want to invest heavily in their own IT departments, but slowly, this model is making its way into medium and large enterprises. SaaS offerings from companies such as SalesForce.com and Cisco WebEx have made this move up the chain possible. SaaS value proposition is now pretty clear to companies of all sizes and SaaS has become a crucial component of IT strategy for all companies.

Similarly, Service Oriented Architecture (SOA) is getting a lot of attention these days. Again, the basic concept behind SOA is not new and has existed for a long time. SOA basically involves exposing functionality from distributed systems in the form of stateless functions; this is similar to other distributed system architectures such as CORBA and DCOM. What is making SOA much more popular and prevalent than CORBA or DCOM ever did is the web services standards such as SOAP, WSDL, UDDI etc. Similar standards existed with CORBA and DCOM as well but were not open enough and led to vendor or technology lock-in. With web services, all the major vendors are behind the same set of standards, so there is a higher chance of interoperability between various systems and hence a higher potential ROI for SOA.

SaaS deployments are revenue generating businesses targeted directly at end users, whereas SOA deployments are usually created within IT environments and the services are exposed to other applications as opposed to end users. What I intend to communicate through this article is the close relationship between SaaS and SOA. SaaS and SOA are very complementary in nature. In fact, they can't exist without each other.

What are the key elements of a SaaS platform? Every SaaS platform has to have a few core things in place, these are: multi-tenancy, ordering and provisioning, user authentication and authorization, service catalog and pricing, service monitoring, <st1:place w:st="on">SLA</st1:place> management, usage metering, billing, invoicing and payments. Besides these core components, a SaaS platform also needs to support the usual business functions such as marketing, lead tracking, sales, customer support, revenue and financial management, partner settlement, business intelligence etc.

Now, let's take a look at the key elements of a SOA platform. A typical SOA platform deployment consists of service producers and consumers from across the enterprise. Service producers publish services via the SOA platform, which get consumed by multiple service consumers. There has been a lot of focus on the technical aspects of a SOA platform e.g. service bus, communication protocols (e.g. SOAP), service interface definitions (e.g. WSDL), service discovery (e.g. UDDI) etc. The importance of service monitoring, management and governance is also well understood, but this is not enough. In a typical large enterprise, the service producers and consumers could be applications or systems belonging to different departments, organizations or even subsidiaries within the enterprise. In such environments, services cannot be produced and consumed informally without proper service management in place since there is a cost associated to hosting and exposing a service by the service producer. In order to derive this cost, the total cost of operations or ownership (TCO) needs to be taken into account besides the cost to create the service. Also, there are security concerns around publishing the services openly. This leads to the need for service catalog management, provisioning, authentication, authorization, usage metering and cross-department charging. As highlighted before, these are also the core elements of a SaaS platform. So as an enterprise SOA deployment matures, it is suddenly in need of the core functions of a SaaS platform.

Let's take a look at the flip side of this. Every SaaS platform needs to support the ability to add new service offerings and modify existing offerings in the service catalog with minimal changes to the core platform components. These additions or modifications should not lead to creation of a whole new SaaS platform for every service. Instead, all the basic functionalities of the SaaS platform such as ordering and provisioning, authentication and authorization, service catalog and pricing, metering, billing and invoicing, payments etc should be reused for multiple service offerings. Such reuse necessitates the need for a SOA platform. Further, use of a SOA platform enables other advantages such as a more flexible and plug-n-play architecture leading to lower overall cost of ownership.

It is probably quite intuitive that most complex architectures including SaaS architecture will benefit from SOA capabilities, but a SOA platform needing SaaS capabilities is not that intuitive. There has been a lot of hype around SOA for a while but most SOA deployments in large enterprises have either not been successful or have not provided the expected ROI because the SaaS elements are missing in these deployments. In order to realize the full benefits of large-scale SOA deployments, it is essential to have a SaaS like service management functionality in place. This is where SOA and SaaS together can enable the concept of "IT as a service" and help take IT to the next natural step in its evolution.