SOA: The Case for Lowercase

by John Tibbetts, Senior Consultant, Cutter Consortium

You'll notice that I've shamelessly put the term "SOA" right at the beginning of the title of this Advisor. I'm as eager to attract attention as the next guy, and these days SOA is a near-irresistible little acronym. Any conference, organization, Web site, or product line that promises help in getting up to speed on "service-oriented architecture" is guaranteed an avid audience.

But I'm actually no fan of SOA. I am a longtime advocate of what SOA purports to promote -- Internet-based, loosely coupled, discoverable, document-centric services -- but it seems to me that the SOA phenomenon gets in the way of achieving this goal. SOA is not a useful enabling technology; it is a marketing campaign that aims to sell hastily assembled collections of message brokers, orchestration engines, registries, development, and monitoring tools by passing them off as the definitive computing framework for the Web era.

I have some brief advice for organizations that are buffeted by these waves of software hyperbole. And with SOA being the fashion du jour, it will provide us with a good case in point:

1. When a vendor-promoted initiative comes with an acronym that ends in "A," lowercase the whole thing and knock off the "architecture." There may be a good idea there, but it does not need a brand label, and it is almost certainly not an architecture. Thus, SOA, the commercial blockbuster, turns into the modest "service-orientation" -- an approach, a technique, a system-building philosophy that involves getting loosely coupled, document-centric services to work together.

2. Focus on the underlying principles that will supposedly be provided by all the stuff you are being urged to buy. You may well be able to accomplish the same goals more elegantly and efficiently and at a fraction of the cost. For example, service-orientation is, like object-orientation, a way to achieve reuse. In the service-orientation case, this is reuse of comprehensive running services rather than of much finer-grained components, and the benefit comes at runtime rather than development time. But both aim at saving time and money, reducing uncertainty, eliminating duplication, and streamlining software utilization. Here's a case where you can learn as much from an initiative's similarity to what you have done in the past as you can from its differences.

3. Once you are sold on the value of the approach, look for a legitimate architectural implementation. There are, for instance, substantive architectures that can be used to design service-oriented systems. One of these is Web Services Architecture (WSA), true architectural specification promulgated by the W3C (www.w3.org/TR/ws-arch). It has precise definitions of its components and models for how the components interrelate. There is no ambiguity about its scope or contents. Like other architectures, it helps to clarify the issues rather than simply point to an enabling product.

4. Evaluate products on their individual merits. Or, to put it another way, do not invest wholesale in a vendor's product suite. You will do better with your own framework, where you can mix and match products and even take advantage of the many open source offerings that are out there. My client ended up using selected pieces of the vendor's SOA offering, but retained ownership of the overall architecture. Someone there compared it to a sophisticated audiophile buying stereo components one by one rather than investing in a large, integrated piece of audio "furniture."

We in the development community will surely be adding service-orientation to our technical toolkit over the next few years. We will be most effective if we resist the SOA juggernaut and convince our nontechnical colleagues to do the same. And let's widen this effort to resist the next big-ticket, highly publicized, vaguely defined, and profoundly disruptive software "revolution" inevitably headed our way.

-- John Tibbetts, Senior Consultant, Cutter Consortium