Many software architects seem to want to perpetuate the giddy 'buzzword escalation' of the 90's long after the decline of dot-bomb thinking has enabled customers to return the focus to hard measurable quantities like ROI. One of the terms that on the surface seems over-hyped is Service-Oriented Architecture or SOA. The methods and benefits of SOA sound like a late night repeat of what the software industry was aiming for over 15 years ago when it started focussing on object-orientation, and then again about 10-13 years ago when developers and deployers realised that a packaged component under middleware such as COM, DCOM and CORBA could have useful 'physical' properties like ease of deployment, discovery and replacement.

A web service is simply a remote-addressable component interface. A service-oriented architecture is achieved when the following are true:

1. there is a common platform-neutral middleware

2. there is a means to discover both types and instances of service interfaces at runtime, and additional information is available to help both people and software to select among them

3. the caller and the service interface are unrelated (loosely coupled and location independent)

4. each service interface is sufficiently well defined, high-level and abstract that (in combination with 3) an alternate implementation is not merely possible but practical

5. service implementations implement their interface specification correctly (but not necessarily in the same way)

It is quite easy to write web services that meet the technology requirements (1, 2 and 3) but it takes specific effort and knowledge to also meet the service definition and implementation requirements (4 and 5).

A further critical goal of SOA is to achieve reuse. Object-orientation alone failed to deliver this, but developers who focus on high-level interfaces and use HTTP/SOAP/WSDL/UDDI as a common protocol backbone will be able to easily reuse functionality exposed via RMI, Jini and CORBA as well as UNO and XPCOM, and with care and some more effort, even non-OO functionality can be adapted as a service.

Then we have folks like John Seely Brown and John Hagel III who talk at a high level about 'the service concept' and 'radical incrementalism'. Everyone understands what a service is, but for a developer it is nothing more than good old fashioned object-orientation with emphasis on loose-coupling and the addition of location independence. The latter concept (RI) is nothing more than kaizen (continuous improvement through time-boxed reflection and change), with a nod to techniques from agile development methodologies (frequent applied change, customer orientation and use of appropriate metrics to guide decisions) applied to the business arena.

What then is SOA ultimately about? It's not simply about one or two technologies, despite the heavy focus on web services. For businesses, it's about ROI. It's simply too damn expensive to have to throw away versions/iterations of a service (or a set of interacting services) just because it was imperfect or incomplete. And its about choice, especially vendor-independence. SOA done properly will enable you to avoid the 'hairball', which is Scott McNealy's term for a bunch of inter-locking features which don't let you replace an unsatisfactory component with a better value one from another vendor. Ultimately SOA is about integrate-ability, choice and evolution.

How will you know what to avoid to achieve the evolution-enabling nirvana of SOA? Here are a few key roadblocks:

1. proprietary stacks and containers - if multiple software services depend on the same specific database or a particular vendor's platform, your ability to evolve your architecture is seriously limited

2. behind-the-scenes dependencies - if your services interact appropriately via web service protocols but in their internals they are are exchanging information in common configuration files, directories, databases or filesystems, then you don't have an SOA; even worse, some web services require you to pass information parameters that must first be obtained from one of these backend data sources

3. proprietary data formats - if you are restricted to a single tool to create certain data or documents, or if the format is subject to arbitrary change by a vendor, then your web services won't help you avoid lock-in to specific vendor's software and even specific versions of software

4. proprietary enhancements - vendors add extensions not just to satisfy customer requirements that the current standard does not meet, but also to limit their customers' ability to switch to another vendor's products; businesses should leverage proprietary features to meet their short-term goals, but they need to insist that vendors evolve the open standard to meet these extended requirements

An interesting aspect of SOA is how it is beginning to impact on IT vendors. Some vendors think that 'proprietary' is the only way to sustain revenues. This view is declining as businesses are demanding the ability to choose and evolve the components in their IT environments as a right, not a privilege, a view that Sun has notably held and acted on for many years. As CTO's and CIOs use the goal of SOA and the metric of short-term and future ROI to determine how they select and deploy software, vendors will have to compete on value, not on how much their products are mutually inter-dependent. This will facilitate competition among vendors and force a focus on delivering maximum value in a few key areas rather than trying to create a web of inter-locking inadequate products around a few popular ones. This in turn supports the businesses need to maximise ROI.

Finally, does open-source have a connection to SOA? Not at all. To businesses, open-source is just another licensing model and says nothing about their ability to choose, to evolve and to maximise value received from their IT architecture.

1. For software developers and vendors, SOA is about using a common service delivery technology to provide software components (possibly based on reuse of existing functionality) as discrete services that may be deployed independently.
2. For businesses, SOA is about the ability to choose independently sourced software components and to integrate them as part of an evolving IT architecture focussed on maximising ROI