SOA Can't Cut Integration Costs If You Do It Wrong

Loraine Lawson

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.

Add Comment      Leave a comment on this blog post
Nov 21, 2008 1:41 AM tonyj tonyj  says:
Very nice article. But the prescription -- Do right or don't do -- just pushes one back into an endless do-loop, for who gets to decide what is right? We generally call this governance, but it really is team work. Perhaps a problem with middleware middlemen might just be that they are not full-time team players. That might not be the only problem, because, if you start using your Cadillac as a pickup, you really can't blame the dealer because the upholstery doesn't hold up. Some organizations don't understand this fine point, or perhaps choose not to. Worse yet, some parties might build their contracts to protect themselves from blame when their collective governance fails. Neither of these is a prescription for teamwork, much less SOA success. Reply
Dec 5, 2008 1:34 AM Salman Salman  says:
Would tend to disagree with what you said in the end. My version of it is something like "do it once, do it right".Now the big problem is, what is "Right"? Who decided on what is right? Reply
Dec 5, 2008 5:37 AM SK SK  says:
I think if you if we follow Do right or don't do we might end up with doing nothing...Nothing is perfect in real are the requirements people working on those solution.Most of the time we try to implement new architecture solution be it the MVC era or SOA or Web2.0These things work as a Buzz word and every one in the industry is trying to ride that wagon...without understanding the core concept on why there was a need to implement new architecture....This competetion creates lots of defination on what and how to implement is a opportunity for so called Middleware middleman...The actual Business Person or the End Users is never worried about how a particular application is implemented and what technology it is using... Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.