SOA Watch: The truth behind ESBs
Stories Columns Opinions Resources
Preflight builds spread wings for smoother projects
Developers are increasingly turning to preflight builds, allowing them to experiment with ...
|
Coverity creates program to enforce code adherence
The Architecture Analyzer uses mapping technology from the company's Software DNA static a...
|
QCon 2008 features domain-driven development
This year's QCon invites speakers like Eric Evans and Dan North to talk about domain-drive...
|
.NET similarities prove golden for Silverlight
Microsoft has focused on making Silverlight 2 symmetric with the .NET platform, and that h...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Advanced Corda CenterView™ Data Visualization for the BusinessObjects™ Intelligence Platform
Corda Technologies presents a white paper on pervasive BI. The BusinessObjects business in...
|
From Mobile to SOA: A Guide for Optimized Application Deployment
Customer need has driven the emergence of multiple computing tiers. Today’s application d...
|
e-Kit: Web Application Security
Is your network secure? What about your web applications.
If IT security is your top p...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
By David S. Linthicum
September 1, 2008 —
You never know what will set people off, but a recent blog posting that I made concerning the value of ESBs ignited a firestorm in the SOA blogosphere. Perhaps what sparked the response was not what I said, but how I said it. Indeed, I’ve been pushing back on ESBs for some time, for architectural reasons. Now it seems that people are jumping on the anti-ESB bandwagon, and I’m not sure what to think about that.
Just to be clear, this is not about ESBs being bad technology. Clearly, ESBs have a place in some SOAs, but not all. Rather, this is about vendors’ tendencies to overuse the term. ESBs are all different, but in many instances they are being sold as SOA in a box. Enterprises then run out and drag them into an IT infrastructure, expecting great things, and typically they find they have a square peg in a round hole, which only adds to the architectural complexities.
ZDNet SOA blogger Joe McKendrick posted a poll on the issue, partly in response to the firestorm around my ESB pushback. The poll asked: "Are ESBs an effective platform for SOA?"
At the time I filed this column, Joe had 51 responses, distributed as follows:
» |
It doesn't really matter; SOA should be oblivious to underlying technology (43%). |
| » |
No, they create costly messes (29%). |
| » |
Yes, they provide a ready solution (24%). |
| » |
Other (4%). |
Most surprising to me was the 29% who said they think ESBs create “costly messes,” since most of those respondents have probably already purchased ESBs and have watched those messes emerge around them.
Although ESBs are not all the same, they have a tendency to be too information-oriented, and they are typically repurposed messaging systems with service interfaces built on top of them. Thus, some ESBs have issues in dealing with true service behavior and really are just service-oriented message brokers. In some instances, however, your architecture may need a service-oriented message broker, or an ESB. That needs to be within the context of a much larger architectural plan.
But keep in mind that ESBs are not all created equal. Many times, existing integration players from the past days of EAI have done a search-and-replace job on their Web sites and documentation and replaced “message queue,” “message broker,” “EAI” or “integration server” with “ESB.” The underlying technology, however, is pretty much the same. Suddenly, everyone is an ESB—and that’s why ESBs are as distinct from one another as snowflakes, all solving very different problems.
The core issue here is not the ESBs themselves, but the lack of planning that occurs when enterprises consider ESBs in the context of a larger architecture and strategy. The fact is that those who consider SOA just another technical problem to be solved are doomed not to solve it. Instead, they will layer technology upon technology, an exercise that creates complexity, hinders agility and moves them further away from the desired state.
SOA, at its essence, is about decomposing IT infrastructure down to a primitive state and building it back up, first as services and then as mechanisms to turn those services into solutions. ESBs typically don’t provide a complete mechanism to do that.
The Burton Group found in a recent survey that SOA failure is less about technology than about people, processes and politics. My point is that in many instances, the symptoms of a people/process issue are tactical one-off technologies that are dragged into the enterprise as part of a “strategy,” when in reality there is no plan to drive systemic change in the context of the business.
The core issue is leadership within enterprise architecture and beyond. The entire executive team should be involved in making sure that a core plan is both created and followed, so that the enterprise doesn’t wind up mired in an endless cycle of hacking and patching, as most are today.
Stop the wasted motion. Put a plan in place that works for the business, and then execute the plan. It will not be perfect. But we have to get better at leveraging our IT assets in support of the business.
For now, it seems that many are dealing with the messes and consider that behavior "just fine." I don't accept that.
Reach analyst David S. Linthicum at david@linthicumgroup.com.
Related Search Term(s): ESB, SOA & SaaS
Share this link: http://www.sdtimes.com/link/32738