Intermediating ESBs for SOA: The Final Webinar?

OK, sorry to mix metaphors, but it is time to put this can of worms to bed (???). If you've been following this blog you couldn't help but notice the many posts on the apparent ESB vs. SOA controversy. All of this started with an innocent little interview John did for SearchSOA - where the topic of Intermediating multiple ESBs came up. This article created a tornado of posts from some heavy hitters on SOA topics over the last month.

Given all of that, we decided to have our own little webinar on the topic Monday - and we were glad to find dozens of you Chief Architects and senior IT & Dev Managers attending - and asking some great questions about how to rationalize ESBs with their existing technologies, and enable your SOA initiatives going forward.

You can watch an archive of this informal, and informative webinar, with iTKO's John Michelsen, and Chris Kraus here: http://www.itko.com/site/resources/esbwebinar.jsp. Chris demonstrates a little software how-to in the middle of the session for those to like to see the screens.

Hey, are ESBs evil? We don't think so - we've always considered them to be another valuable building block in SOA for many of our customers. The key to success here is making sure you are using ESB platforms, even if they are of different flavors - for doing what they do best in the integration process. An ESB does not make an out-of-the-box SOA. However with good design and architecture principles, and strong validation and Governance, you can mitigate the risks of working with these technologies and bring a lot of your legacy and transactional technologies into the SOA fold with much more ease.

Virtualization of ESB messaging behaviors (and the underlying apps and mainframes they expose) is another way to address these ESB intermediation constraints between teams - say if I'm on the webMethods (SAG) team and need access to the TIBCO team's messaging framework. Or if I'm using Oracle/BEA Aqualogic and need to interact with services exposed through the SAP XI messaging tools. Our counterpart on the other team may want to limit our access to these systems - especially if they are supporting live business requirements. The ability to virtualize away those inter-team dependencies, and have a realistic, stable Virtual ESB earlier in my design/develop/test lifecycles can take away much of the cost and delivery timing constraints inherent in intermediation.

Is this the final time we'll visit this controversy? Maybe not - as long as there is complexity and change in SOA, which is the case for virtually every decent sized enterprise IT shop, there will be a need to rationalize multiple technologies. After all, we have to keep doing business today, despite mergers, compliance changes and new competitive pressures that make us keep bringing in new technologies.

We invite you to sit in on the session and make up your own mind -- and welcome your comments on the content.