A picture is worth a thousand words, as they say. Based on all the words that have been written about ESB, I'd say the picture below is worth even more.
Bill Inmon had the following picture of why a bus is not an integration panacea is his recent B-Eye Network article The Bus as a Substitute for Integration, Part I:
Now you could read the article, but this picture sums it up, doesn't it? That's how it struck me. Creating a powerful, yet simple, picture of a complex issue is hard, and takes a foundation of expertise in a topic area, and still then some sweating over. (For some great examples of excellence in infographics, I highly recommend The Visual Display of Quantitative Information, with my favorite Napoleon's March chart.)
Bill Inmon certainly knows a thing or two about data integration, which is perhaps why this picture is so poignant. And while it is not about EII per se, it reminded me of many conversations I've had with ESB proponents over the past year. The point I always try to impress on people is that ESBs are good at reliably moving data, and they are (thankfully) more open than some of the older bus technologies, but they still don't help you integrate the data. The reply to which - and I always love this one - is "All you need to do is write some code..." If I had a dollar for every time I heard that one...
Here's a better alternative. Create a parameterized View of what you want in an EII product like Ipedo's. A View is essentially a virtual representation of the data you want, joined, cleaned, and - importantly - semantically correct. Then, instead of the typical bus flow of Get A [invoke custom code] then Get B [invoke custom code] then Get C [invoke custom code] and so on, the View queries multiple data sources and returns the information your application needs to the bus. It's not magic, just a cleaner, easier approach with a more suitable tool.
So before you jump on the bus bandwagon, take another look at that picture and think about how EII can help.
Comments