Robin Bloor, a partner with consultants Hurwitz & Associates, noted in Friday's IT-Analysis.com column that ESBs are now associated with SOA messaging, but are they really something more?
His thesis: Are ESBs primarily an integration engine?
What prompted this line of reasoning was an in-depth interview with CapeClear Software about its ESB offering. While CapeClear is certainly promoting its ESB as an SOA solution, it also talks about its potential to offer integration on-demand.
While ESBs are now strongly associated with SOA, Bloor points out that ESBs actually herald from the Enterprise Application Integration days. So, he contends, it's really more than "just" a messaging software for SOA -- it's an integration engine or mediation engine, depending on which paragraph you're reading.
If you're deeply interested in his case, read the article. Here's the business-relevant integration tips I took away:
- Companies are using ESBs solutions such as CapeClear to integrate SaaS offerings, including SalesForce.com with in-house applications. More specifically, Bloor notes that it's been "deployed in anger," which just goes to show you there's some resentment going on in how IT handles SaaS integration.
- ESBs could be used to integrate mash-ups.
- Bloor contends ESBs will have to implement service level policy, since it's the first technology layer that gets hit with multiple requests for services in SOA.
Integration engine, SOA technology -- I'm not sure it matters, unless you're in marketing. It would be really awesome if you bought an ESB for your service-oriented architecture, and then found you could use it for all sorts of other things -- sort of like Microsoft Word. You can use it as a word processor, but it can also be a design tool, if you're REALLY patient. And like boxes.
But to me, the argument is a bit academic. The really big question -- one that may come back to haunt everyone -- wasn't raised by Bloor, but by a reader in the comment sections:
Just to make things fun, think about what happens in the inevitable scenario that you end up with two ESBs?https://o1.qnsr.com/log/p.gif?;n=203;c=204663295;s=11915;x=7936;f=201904081034270;u=j;z=TIMESTAMP;a=20410779;e=i
He then offers a list of vendors already packaging ESBs with their software, including SAP, Oracle, IBM, Tibco, Microsoft and now, obviously, Appian and Cape Clear.
That question made me pause. So, of course, I did a Google search, because I'm that kind of a girl.
The only recent reference I could find was in this recent CIO New Zealand article, "Five Ways to Roll Out SOA."
The article shares how Leapfrog Enterprises implemented SOA, and notes the company actually used two ESBs: The first for managing data flow and application handoffs with internal systems - ERP, ActiveDirectory, data warehousing -- and the second for managing Web-based applications used by customers, such as its online games.
According to the article, each ESB serves as a backup for the other when needed.
So, apparently two ESBs could be useful. What happens beyond that?
As it turns out, large enterprises already have faced this problem, though the most recent reference I found was from mid-2006. Ironically enough, according to this InfoWorld article, Network Director 4.0 actually offers a tool that manages multiple ESBs. It gets them to work together, talk to each other, if you will.
In short, it's a middleware for all your little middlewares, an irony that wasn't lost on a ZapThink senior analyst at the time. InfoWorld quotes Ronald Schmelzer as saying:
"SOA Software's Network Director looks like middleware for your middleware play. ESBs for ESBs, enterprise middleware integration. A plot that never ends. But Network Director obviates the need for an ESB in the first place -- if you have proper service intermediation, who needs an ESB in the first place?"
Maybe that's why there hasn't been more written about this particular solution since last year. But if ESBs continue to proliferate, Network Director 4.0 may get the last laugh.
Bottom line: Before you invest in a product with an integrated ESB, ask yourself and the vendor whether you're paying for something you already have. And then follow up with a few questions about how their little pre-bundled ESB will play with the rest of your middleware.