Last week we at SearchSOA.com ran a story about how ESBs aren’t as interoperable as users might expect them to be. The story prompted a response from StrikeIron CEO Dave Linthicum, basically wondering if the bigger problem here is bad architecture. He wrote:
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Call me crazy, but would it not make more sense to have a centralized plan as to what the SOA should be, based on the requirements of the business, versus people dashing out and shelling out the dollars for an ESB for some one-off tactical reason, or more likely just acting out of reaction to the hype? Now, you’re left with a dysfunctional mess that’s not easily corrected, and clearly costly.
Joe McKendrick over at ZDNet picked up on that and put together a brief history of ESB criticism. Linthicum’s blog entry also drew a lot fire down in its comments section (be sure to check them out as iTKO’s John Michelsen, the interviewee in our original article, makes a few points on the unavoidable nature of multiple ESBs). The response in fact spurred Linthicum to write a follow up entry addressing some of the critics of his first entry. After pointing out many of the dysfunctional things he’s heard over the years, he wrote:
[W]hat I’m asserting is that there has to be some architecture forethought behind dragging any technology into the enterprise, and I suspect that’s not occurring.
To be fair, he doesn’t suspect it. He knows that’s the case. We all know that’s the case. As Software AG’s Miko Matsumura put it in another article we ran last week, “People are addicted to messed up IT.”
Anyway, Linthicum finished his latest post with a request:
So, in the spirit of having an open mind, send me your reasons for leveraging multiple ESBs, and why that’s a good approach for your enterprise architecture. Also, while you’re at it, make sure to send me the reasons you’re using an ESB to begin with: your requirements and the reasoning behind the solution. I won’t post them unless you say it’s okay.
It’s an interesting topic, so make sure to send Dave your reasons, if you’ve got some. For my part, I know a lot of people who despise ESBs. During one interview I did with an analyst back in 2005, he referred to ESBs at “methadone.” This was actually praise for the ESB, making the case that it was better than EAI. Yet I know others who just as adamantly argue that at some point you’ve got to implement a service or pull together applications after a corporate merger, and at that point you will find yourself wanting an ESB.
Earlier this year, I actually did a podcast with Mulesource CEO Dave Rosenberg about why he maintains that enterprises will need to accommodate multiple ESBs inside their SOAs.
I would argue the larger point here, and this is where Michelsen was focused in the original article, is that multiple ESBs are a fact of life. No matter if it may be sub-optimal in terms of architecture, a good architecture should be able to tackle this kind of problem, or at least good governance should help ameliorate it. Mergers and acquisitions will happen. You will need to combine services with outside entities. Different divisions will buy disparate products, even if they shouldn’t. This doesn’t even touch on technology creep from the open source arena.
So it’s really two questions. The first is do you even need one ESB let alone many? It’s a fair question and one that every end user ought to put serious thought into answering. The second is, how do you deal with multiple ESBs in your infrastructure? Because no matter how you answer the first question, you will need to manage this situation for at least the near term.