Looking up at the bookshelf next to me just now, my eyes are drawn to one section in particular — a well-populated shelf of books on service-oriented architecture. I think I could probably anchor the QE II with those books.

And it’s not just the books: I’ve taught SOA for five years and left in my consultant’s wake an SOA-based inventory system, service bus, and EDI reconciliation application.

Now, here’s what’s bugging me, and why I’m getting really irritated, looking at those books: I’m looking back at that service-oriented architecture, thinking about what it was intended to do and what it cost to put it there, and it’s hard to see the ROI.

Service-oriented architecture is supposed to give me all kinds of stuff I didn’t have before. The list of miracles that services supposedly offered me is so long I can hardly cram it into one paragraph: loose coupling (minimal dependencies between components); encapsulated logic (sequestered and minimized); reusability (plug the same service into lotsa apps!); statelessness (no overhead consumed by state management); autonomy (services are their own boss, independent of the app); metadata (all services speak the same language), and on and on.

It’s more fun than Big Bang Theory, if you’re a developer — but what does it really buy us?

I’ve used service-oriented architecture for the better part of a decade, and I can honestly report the following …

  • I have never seen the “contract” feature of any service I’ve written or designed be leveraged to enable its re-use;
  • I have never seen a service from one system be recoupled to another;
  • I have never seen encapsulated logic used in multiple applications;
  • I figure I have a right to feel a little gypped, at this point.

So I moped about this for awhile, and I briefly considered abandoning SOA as a design default. This isn’t too great a stretch, because contemporary design implementation, while extremely modular and loosely coupled, isn’t necessarily SOA-oriented per se. It’s easy to design modular systems without resorting to services as core components.

But then there’s the other side of the ledger …

Looking back at those SOA efforts, there’s a wonderful layer of benefits that aren’t as obvious as the ones SOA’s apostles claim. It’s a layer so rich and substantial that it bears close examination and, ultimately, appreciation.

Here’s what I really left in my wake, having designed SOA systems.

A higher class of coder

How good does a developer have to be to implement an SOA-based system? Damn good; SOA requires an economy and robustness that few other design paradigms call for. Services that meet the standard of excellence required by SOA design demand, to some degree, nonlinear thinkers, developers able to see in more than one direction at once.

No more monolithic assemblies

Remember COBOL programs that had 6,000 lines of code? Maybe you’re not that old. All right, then, remember those early .NET programs that contained 30, 40, even 60 references? Remember what it was like to maintain them or, hell, to test them in the first place? Remember how easily they broke and how many evening and weekend hours you had to spend fixing them? That doesn’t happen in the SOA world.

XML is now the courier of choice

Okay, whatever you might think of “contracts” or “loose-coupling” as a design concept — how cool is XML? Hasn’t it made all our lives a thousand times easier? Off the top of your head, can’t you think of half a dozen ways you use it, and isn’t it dirt-simple and effective, every time?

XML is a godsend, and while many architects and developers (myself included) have uttered a few unholy words over it in trying to bend it to our will, it beats by a light-year anything else we’ve ever had at our disposal for agnostic data transport. That agnosticism is the core requirement of SOA and has been a massive driver of XML’s increasing presence and portability in the IT universe to date. I, for one, genuflect.

Developers write reusable code by default!

To write code that can be reused is an art in itself. The code must be abstracted; it must be as functionally self-contained as possible; and it must be written in such a way that changes have easily quantified consequences to its output. I remember a time, not so long ago, when developers changed code and crossed their fingers. That doesn’t happen nearly as often in an SOA shop.

Fifteen years ago, the over-hyped technology that dazzled us all was ERP — which hundreds of companies bought into, only to pay and pay, year in and out, for piddling, incomplete results. It’s easy to characterize SOA as its successor, but ERP left us with nothing but piles of unused, overpriced manuals in some back room. SOA may have been over-hyped, but it gave us something much better: it carried us from reptile to mammal and left us well-adapted for the world that’s coming.