Only last week, I wondered why pundits and analysts get so worked up about the role of an ESB in SOA. Since I've yet to see anyone argue you must have an ESB to have a SOA, I wasn't sure why the topic keeps resurfacing.
I also couldn't understand why some people were so passionate about warning us about ESBs as SOA -- particular when, as Joe McKendrick recently pointed out, so many organizations are using ESBs as a simple and useful path to SOA.
But after reading this ZapFlash on ESBs and SOA, I finally get it why this is such a hot issue -- and a particularly important one for those of you just embarking on service-oriented architecture, but already invested in an ESB solution or two.
ZapThink managing partner Jason Bloomberg does the best job I've seen of explaining why this topic is so important and, more importantly, putting ESBs in their place, so to speak.
As Bloomberg explains it, the problem isn't so much whether or not you use an ESB, but rather, how you use it -- an important distinction. He says committing to an ESB too early in the process of developing your SOA "substantially increases your risk of failure." So, of course, this is one of the most common mistakes companies make with SOA, a coincidence that might help explain those rumors of companies discontent with their SOA.
Which brings us to the real question -- why does the use or non-use of an ESB matter so much? The problem is companies end up designing their service-oriented architecture around the ESB, according to Bloomberg. You can see why this would be a bad idea even in theory, but Bloomberg explains the three common consequences this causes:
1. An overly integration-centric perspective of the SOA. I've read a lot about this problem, too, but again, Bloomberg does the best job of explaining how this hinders SOA. ESBs are, of course, really good at connecting things -- but as he points out: "SOA isn't about connecting things, it's about building loosely-coupled Services the business can leverage to meet changing process needs. We want to get away from the "connecting things" approach to distributed computing, and instead move to a 'composing Services' paradigm, where integration becomes a byproduct of composition." It's hard to do that when you've started with a technology that specializes in connecting things.
2. Too much middleware. I've shared before how ESBs are proliferating within organizations. Bloomberg points out this leads to using middleware to connect middleware -- which, now that I ponder it, would make a really good koan, but a bad architecture. (If you're curious about what this approach looks like, InfoQ has an article on ESB Topology Alternatives that offers an example.)
3. Needless expenses. People are buying ESBs and using them because their vendors tell them to. So, you've bought an ESB and now you have to use it, instead of figuring out what you needed and what would work, which really might have been cheaper. We'll never know, will we?
What's really smart about this piece is that Bloomberg doesn't just opine about why you shouldn't start with an ESB -- he assumes you're reading the piece because you are one of the unfortunate many who's already made this mistake and now must deal with the ESB you've been dealt. So he cuts to the chase and tells you how to avoid ESB-first ensnarements.
I'll let you read his full column for the details, but what surprised me about the "ESB-first Best Practices" is Bloomberg's contention that what matters most is what you don't use. This is because many ESB capabilities can actually inhibit your SOA by making it too inflexible in the long run.
In particular, he advises caution when deploying the traditional messaging middleware capabilities of the ESB or using its service runtime capabilities. Instead, he advises using the ESB as a Service intermediary, which is further explained within the article and with a link to a related ZapThink article.
You might also want to check out Paul Fremantle's article on "Reclaiming the ESB," which makes a similar case about how ESBs can be detrimental to SOA, depending on how they're designed -- which, obviously, could impact which solution you buy -- assuming you're one of the fortunate few who haven't committed to an ESB before starting SOA.