SaaS vs SOA

Objectives/scope, SOA provides a set of services that end users can take advantage of, while SaaS lists the services that can actually deliver.

Business model, SOA implies a list of found business services to be used in the system; SaaS implies a list of business services to be provided. Using existing business services could significantly eliminate software design and development expenses.

In SaaS a software system can be delivered either as just one service, or as a part of a greater collection of services that eventually compose the entire system.

Information system model, while SOA uses an architectural model that describes how interaction among service components happen, SaaS does almost the same but it does not limit its range just on services.

Technology model, In order to specify the Information system model the technology that SOA and SaaS are going to use should be stated (such is Web Services).

Detailed representation, WSDL, UDDI and SOAP are used for description, publishing and communication respectively. Those are used both by SOA and SaaS when implementing Web services. The platform on which SOA and SaaS will implement their services should be stated.

Functioning system, SOA systems demand the existence of monitoring and management of all communication, coordination, and collaboration among service components while SaaS systems require the same but just among its internal components.

Table 3 bellow summarizes the differences between SOA and SaaS

Table 3 (Laplante 2008)

The main target of SaaS is businesses driven and is also directed at the end users, when SOA on the other hand is developed within various IT environments and is used to offer application driven services. Although SaaS and SOA have different perspectives, there are still really closely related. In fact SaaS and SOA platforms are complement to each other and they cannot stand separately on their own.

As mentioned earlier the SaaS platform is characterised by a set of core components. These are: multi-tenancy, ordering and provisioning, user authentication and authorization, service catalogue and pricing, service monitoring, SLA management, usage metering, billing, invoicing and payments. In addition to the above the need for the SaaS platform to support various business functions arises. Those business functions may vary from marketing, lead tracking, sales, customer support, revenue and financial management, partner settlement, to business intelligence and so on.

A SOA implementation is composed by service providers and service consumers that belong to an enterprise. SOA platform is used by the service providers in order to publish their services, which consumers in their turn can take advantage of. Having a closer look at SOA platform technical implementation, we can see that it is composed by a set of well defined characteristics some of which are: service bus, communication protocols (e.g. SOAP), service interface definitions (e.g. WSDL), service discovery (e.g. UDDI) and so on. It is also well understood how important service monitoring, management and governance are but it is also clear that 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. So at this point the need for a service catalogue management, provisioning, authentication, authorization, usage metering and cross-department charging, arises. It is obvious that these elements are exactly the same as those of SaaS platform. Hence someone can come up to the conclusion that as enterprise SOA deployment become more and more mature, they are in more need of the core functions of a SaaS platform.

Back to SaaS platform the needs of offering new services of modify existing ones in the service catalogue with as little changes as possible to the core components of the SaaS platform is obvious. Those modifications should implement in such a way that the SaaS platform that derives from them is not a totally new platform for the existing services. On the contrary the SaaS platform basic functionality e.g. ordering and provisioning, authentication and authorization, service catalogue and pricing, metering, billing and invoicing, payments and so on, should allow reusability for as many service offerings as possible (if not all).Furthermore the combined use of SOA and SaaS platforms is an add

on, on flexibility of the architecture and also contributes to keep the cost of ownership low.

It should be already clear that SaaS architecture as well as other similarly complex architectures benefits of SOA capabilities. The opposite is not always true meaning that a SOA platform will not always be need of the capabilities that an SaaS platform can offer. At the beginning of SOA there have been lot of expectations that unfortunately over the years did not accomplish. Implementations of SOA that took place in large enterprises has not been as successful as expected or have not provided the expected Return of Investment (ROI) because and that was caused by missing SaaS elements in these deployments. SaaS management functionality is considered essential in order to make people aware of the way they can fully benefit from large-scale SOA deployments. This is also the point where SOA and SaaS enable the concept of "IT as a service" and become capable take IT to the next natural step in its evolution. Figure 10 bellow summarises the difference and similarities of SaaS and SOA platforms.