ZapThink recently published what may be the most frustrating column about SOA I've read to date - and I read a lot of frustrating SOA pieces. This article even frustrated Sam the hamster, whose cage is next to my desk, because I woke him up yelling, "Well, what's the point if you're going to do it that way?"

I thought the piece was another in a series of recent articles on how economical SOA can be a topic tackled recently by eWeek's Channel Insider and David Linthicum for Software Development Times.

The ZapThink article certainly starts out along those lines. In a nutshell, ZapThink noticed back in 2002 that traditional middleware-based integration generates "unpredictable spikes in cost" whenever business requirements change. They even drew a nifty Integration Cost Curve to explain this relationship.

ZapThink believed SOA could alter that curve by making it easier, and cheaper, to respond to new business needs:

"Implementing SOA means building for change, so the argument goes, so while there will continue to be some ongoing costs, a fundamentally agile architecture will smooth out the ups and downs of IT integration expense."

But that's not how reality played out, and that's because SOA took a detour. Instead of eliminating silos and the need for middleware, many SOA implementations embraced both. Instead of using ESBs as service intermediary for SOA, they deployed ESBs as integration middleware.

And instead of using SOA across the organization, companies deployed platform-specific SOA solutions, which lead to "SOA domains." That's analyst-speak for a bunch of separate, siloed SOAs, often running on different platforms for different parts of the business. And guess what you have to do to get these SOA domains to work together? That's right: more middleware.

ZapThink put it like this:

"Herein lies the most dangerous pitfall of the SOA platform-centric approach to SOA: because it depends upon integration middleware, it succumbs to the issues with middleware that SOA was meant to address, namely the lack of agility and the increasing costs of integration over time. Basically, you'll eventually need more middleware to get your various ESBs running in various SOA domains to interoperate or federate with each other. Now, it's possible to implement SOA in this manner, but ... why bother?"

SOA can only cut integration costs insofar as it eliminates the middleware. But like so many other situations in life, the middleware middlemen inserted themselves into the process and gobbled up your savings.

At this point, I have to wonder if these implementations are really even SOA or are they just recreating the old problems with a layer of service-enabled abstraction and products?

ZapThink argues that the way to solve this problem is by focusing on the architecture (as if you haven't heard that enough) and opting for a no-platform SOA. You have to focus on connecting services, not things:

"More than six years later, we're still fighting this battle: integration should be something the business does with the Services, not something IT does to connect one bit of infrastructure to another."

In other words, stop paying the middleware middleman.

I suspect this will be easier said than done, since a boxed solution always sounds easier than custom building. And this ZapFlash author must suspect so too, because the piece devotes a good deal of space to explaining why platform-specific solutions create more problems than they solve.

Unfortunately for some, the economy is bringing these design flaws to light, ZapThink contends:

"While SOA promises costs savings and greater agility, two essential elements of surviving a steep downturn, simply having a SOA initiative doesn't guarantee success. After all, you have to get it right."

Someone once told me, "Do it right or don't do it at all." I took it as philosophical advice about how I should approach life. But when it comes to SOA, it's also a darn good financial tip.