X
Business

More bus-bashing: ESBs are 'standards-based,' but not 'standardized'

I guess the acronym "ESB" won't stand for  "Enterprise Standards Bus" anytime soon.Neal Ford just published this piece on the ongoing travails of the enterprise service bus, making this interesting observation: that ESBs tend to be "'standards-based,' but not 'standardized.
Written by Joe McKendrick, Contributing Writer

I guess the acronym "ESB" won't stand for  "Enterprise Standards Bus" anytime soon.

Neal Ford just published this piece on the ongoing travails of the enterprise service bus, making this interesting observation: that ESBs tend to be "'standards-based,' but not 'standardized.'

An important distinction, he points out, because ESBs tend to be "held together by highly proprietary glue" from their respective vendors. Contrast this with the standardization we see in Web servers, such as Java EE or J2EE, as imposed by Sun. As Neal points out, the vendors' proprietary glue "shows up in the administration tools, the way their BPEL designer works (along with their custom BPEL meta-data), how you configure the thing, how you handle routing, etc. The list goes on and on."

"Even the open source offerings in the ESB space suffer a little from this," he adds.

What's the motivation for vendors to keep their own proprietary hooks in ESBs?  They don't want this lucrative market segment to get commoditized the way J2EE did a few years back:

"The last thing the vendors want is to see their (crazy money making) babies turned into commodity software again. They'll make noise about creating a true standard, but it won't happen. They want to be more like the database vendors, not the application server vendors."

It looks like the challenge for some time to come will continue to be figuring out the best the way to federate these mediation engines that are springing up across their enterprises into a true service oriented architecture.

Editorial standards