Is SOA essentially "Software as a Service" contained within the enterprise walls? The analogy makes a great elevator speech, especially if one is hard-pressed to describe the philosophy of SOA to end-user customers.
Rather than building, maintaining, or delivering their own services, business units subscribe to SOA-based services from a publisher somewhere else in the enterprise, or even outside the enterprise. Someone else worries about upgrades, maintenance and testing; you consume the service, and pay on some pay-as-you use arrangement. Sounds a lot like Software as a Service.
Conversely, while SaaS providers themselves may not necessarily be using SOA, it's probably in their best interest to align their services using SOA methodologies and protocols.
John Crupi sees plenty of synergy between SOA and SaaS, as he relates in a post over at the JackBe blogsite. He even provides us with a new acronym mashup, asking: should SaaS be more appropriately called 'SOA and Ajax as a Service'? With SOA as the middleware, and Ajax as the “face” or last mile to the end user, he sees three types of organizations evolving:
SOA-only Software Providers - A new generation of ISVs that only provide services, but not UIs. Think SugarCRM and Salesforce as a set of SOA-only services.
SaaS Market Enablers - Companies that know how to host, manage and secure services for application consumption.
Composite Company - A new generation of ISVs that provide applications and composite apps that are completely built by consuming SOA-only Software Providers running on SaaS Market Enablers' data centers.
I would like to add a fourth category to John's list:
'Intrapreneurial' SaaS - Corporate units (probably, but not limited to, IT) that build, maintain, test, and offer libraries of SOA-enabled services for consumption either by others within the organization, and even offered externally. Consuming business units may have the choice of using these services, going to an outside SaaS Market Enabler, or an internal SaaS/SOA publisher at another enterprise to fulfill process needs.
David Houlding, writing in the venerable Dr. Dobb's Journal, has also waded into the SOA-SaaS mashup, observing that it is possible to "grow a local SOA into a federated SOA distributed over the Web to both use and deliver SaaS."
"As more services become available over the Web as part of the SaaS trend, service implementations can change so that instead of implementing all logic by themselves or delegating to some local third-party product, they instead delegate to some remote service delivered by some third party."
Houlding cites the example of a Yahoo Maps, which includes an API that you can use to geocode an address. If you include a mapping service as part of your SOA, "you can simply switch the implementation of your mapping service and change the geocode method to delegate to the Yahoo geocode Web service instead of processing such requests in your local system."
However, he cautions that there are several issues that need to be addressed in a converged SOA-SaaS offering, including security, software licensing, and network and service reliability.