Service-oriented architecture and software as a service are a powerful tag team supporting flexible software delivery and systems integration.
As evidenced by the runaway success of Xtreme Fighting or the ratings-hungry catfights on American Idol, we love rivalries -- the bloodier the better. It's not surprising, then, to hear so much talk lately of service-oriented architecture vs. software as a service, or SaaS. It's as though there were some sort of service smackdown going on within IT organizations with both sides hunkering down behind opposing server racks, exchanging verbal volleys regarding superiority of their respective definitions of service.
But if you peer into your typical data center, you won't see anyone painted in blue screaming, "I am William WallSaaS!" Quite the opposite, in fact -- forward-thinking users are finding significant business opportunity by combining SaaS and SOA. In the world of acronyms, these users have literally done their own pseudo-math with the two broad concepts, reconciling their respective definitions of service like so:
SaaS + SOA = SaaSOA
So what kind of strange animal is a SaaSOA, and how is it being put to use? Before we can nail that down, let's spend a moment on the actual differences between services in SOA and SaaS.
A Service By Any Name
For SOA installations, a service is a discrete function (call it collections of transactions, like "show me a user's profile") that can be combined with other services to form broader business processes, such as a complete order-to-cash workflow. In the end, the consumers for these services are end points (such as an ERP system or a portal) or even other services.
A service for SaaS, on the other hand, simply denotes the concept of delivering software the same way a telephone company delivers your voice mail "service." You dial in for your voice mail, and you hear your own name and listen to your own messages as though that application belonged to you alone.
That's the key. SaaS is about delivering a single piece of software to many users, and SOA is about building software that's flexible and reusable. If you put the two together, you end up with a SaaS solution that uses SOA technologies to more rapidly adjust to changing market conditions and customer needs.
In the telco example above, imagine if the process of getting sports scores for your favorite team was a collection of SOA services. Your phone provider could rapidly add those to your voice mail SaaS application, allowing you to retrieve your team's score just as you do with your voice mail messages.
As a matter of fact, many SOA vendors like BEA Systems and Tibco Software are reaching out to telco providers, offering their SOA technologies as a foundation upon which the provider can then build SaaS solutions just like this.
Other SOA vendors like Progress Software have actually made SaaS a literal part of SOA by building a SaaS framework that exposes defined business processes for integration within SOA applications. Progress sells this framework along with SOA software and services to ISVs looking to build SaaS solutions. If you think this sounds far-fetched, consider that Progress already has 160 such partners and has enabled more than 400 SOA-based SaaS applications.
However, one aspect of SaaSOA that has yet to be fully realized is the idea of using SOA as way to connect an enterprise to an externally hosted SaaS application. As you may have surmised by now, SOA doesn't like to speak to humans. Rather, it likes to integrate machines, to connect services with endpoints that may originate internally or externally. For example, using an Enterprise Service Bus, SOA solutions can transform disparate data formats, mediate different protocols, and orchestrate transactions. Imagine if an enterprise that employs SOA internally were also to use a SaaS application, say Salesforce.com. That enterprise could use its ESB to connect Salesforce.com to its ERP or CRM systems. Salesforce.com, of course, has been shooting for this goal since 2005. But the real bang won't come until SaaS customers themselves maintain a SOA infrastructure internally. Corporate developers could then leverage Salesforce.com's SOA services elsewhere, say within a company portal (intranet) or even within the ERP system itself.
Whether SOA is acting as a foundation for a SaaS application or serving as a means of connecting corporate assets to that SaaS application, one thing is clear: These two software concepts are anything but mutually exclusive. If you were to put them in a figurative barbed wire-clad ring and ask them to duke it out, what you'd end up with is a powerful tag team, able to work as one in support of flexible software delivery and systems integration -- a regular Rocky SaaSOA.
Brad Shimmin is a principal analyst covering application infrastructure with Current Analysis.
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.