Just as light can be both wave and particle, software as a service (SaaS) can sometimes be part of service-oriented
architecture (SOA) and sometimes have nothing to do with it.
This dualism leads to some confusion as marketers increasingly talk about SOA products in terms of SaaS capabilities. A recent survey of CIOs and CTOs by the Object Management Group's (OMG) SOA Consortium indicated that there is an expectation that SOA has transformed the vendor marketplace so that significant software can be supplied via SaaS using an SOA approach.
But it is important to have clear definitions, said Bradley F. Shimmin, principal analyst of application infrastructure for Current Analysis LLC.
"I really consider SaaS as a delivery mechanism that supports single instance/multi- tenant applications," he said. "And I consider SOA as a philosophical framework for developing loosely coupled software. So, SOA is all about how software is structured and SaaS is all about how software is used."
Shimmin sees part of the confusion surrounding SOA and SaaS coming from ambiguity as to what we mean when we talk about a service.
"Perhaps the problem stems from the word 'service,'" he explained. "For SaaS, it denotes the application being delivered like any service, like voicemail on your home phone, which to you appears to be an application tailored to your very needs and something you can customize to some degree. SOA has nothing to do with that, as it leverages services, which are discrete and reusable transactions that together make up a business process, to abstract code away from underlying systems."
Jason Bloomberg, senior analyst with ZapThink LLC., agreed that confusion comes when SOA and SaaS are not clearly defined in terms of their differences and in their usefulness in the right combination.
"There's a lot of confusion surrounding the relationship between SOA and software as a service," Bloomberg said. "SOA is an architectural approach and SaaS is a delivery model. The services delivered via the SaaS delivery model may or may not be the loosely coupled, contracted services like Web services we talk about when we talk about SOA. Generally, the types of services are different, but we're seeing a convergence in the marketplace on contracted services being delivered via SaaS approaches."
Bloomberg noted that the "traditional" way of delivering applications functionality with SaaS was done via a Web interface. More recently SaaS began to combine with Web services for delivery without the user interface, but this delivery method is still not SOA.
"Web services delivered via SaaS don't require SOA," Bloomberg said.
However, Bloomberg and the other analysts interviewed for this article do see the SOA approach benefiting SaaS.
"What SOA brings to the SaaS party are loosely coupled, contracted, governed services," Bloomberg explained. "Such services have contract and policy metadata associated with them that constrain the relationship between the service providers and consumers. Such policies might indicate quality of service requirements, reuse guidelines or versioning policies, for example."
The need to have versioning policies highlights the value SOA provides for SaaS vendors, he said.
"Let's say you offer a Web service via SaaS and you have many customers consuming it. Now, say it's time to update that service. What happens to all the consumers? Do they break? Do they have to manually update their software? Either option exposes tight coupling between service consumers and providers -- an SOA anti-pattern in this case."
An SOA approach to SaaS solves this problem, Bloomberg said because SOA can provide "a predefined versioning policy in place that states that consumers must take a specific action every month to ensure they are on the latest version, for example, by automatically downloading an update and that the services will change versions one day after the consumers update. Now, it's possible for the consumers to automatically remain in synch with services as either or both change versions. That's loose coupling in action and an illustration of the power of SOA."
SOA is also important to the SaaS vendors because it helps them more efficiently deliver applications as they increasingly compete over price with traditional packaged software vendors, said Dana Gardner, principal analyst of Interarbor Solutions LLC.
"SOA is a very important approach for software as a service providers in terms of how they construct their architecture and how they work to most efficiently deliver applications," Gardner said. "So in a sense they are a proving ground for SOA. Because their businesses are often subscription-based and they're competing against the on-premises software licensed software enterprise vendors, they want to bring their prices down. So they need to be very cost conscious and make reuse and efficiency and agility in the market hallmarks of how they operate."
Companies are beginning to build a "SaaS ecology" based on SOA, Gardner said. Along with the big names including Google Inc. and Salesforce.com, he said Workday Inc., a startup focused on providing SaaS business applications is doing this. He also noted that Microsoft is beginning to move away from its packaged software roots to explore SaaS in offerings such as its Microsoft Office Live, which provides services to complement its desktop applications in a paradigm it is calling "Software plus Service."
Gardner said on the enterprise IT side of the equation, businesses are beginning to expect that SaaS will be available for their SOA implementations.
"As enterprises start using more SOA approaches, they are in the business of using and consuming services," he explained. "They are going to have developers and business analysts who are used to dealing with rich Internet applications and are used to doing mashups and using services in a compositing or aggregated application approach. There's very good reason to expect them to then move into using APIs that are available and Web services that are available from the open market as well as those they might use internally or across the supply chain or other extended enterprise business ecology."
As Shimmin sees it, this could be the best of both worlds in terms of SOA and SaaS working together.
"Both are very symbiotic but different animals that can work together in two ways," Shimmin said. "First, your SaaS application could be built using SOA standards and ideals, probably a good idea. Second, your SOA infrastructure could be used as a point of integration with SaaS applications. For example, some companies are employing SOA ESBs between external SaaS applications and internal line-of-business applications to provide the required transformations, routing data governance."
Gardner said this may be a view of the future of SOA and SaaS.
"So you can see in the not to distant future an increasing intersection between the offerings that are delivered as software as a service offerings, maybe not entire packages of applications, but certainly components and services that would be mixed and matched within a portfolio of internal business services that SOA architects and developers will be using," he said.