--- In [email protected], [EMAIL PROTECTED] wrote: > > Its not ironic at all. > My initial tongue-in-cheek reaction to organizations having multiple ESB's is to just say "What did you do that for???". :)
I suspect that the presence of multiple ESBs is often due to the same causes as the presence of multiple anything in a large organisation's systems: lack of central buying control and/or inheritance of different systems through corporate mergers/acquisitions. Whatever the cause of such heterogeneous situations, one just has to deal with it in a pragmatic manner. Gervas > > However, I know that's easier said than done and large organizations are faced with adopting different technologies over different projects, and different teams with their own bias toward technology partners. Even when organizations have the maturity to standardize on infrastructure there are still mergers and acquisitions that often occur which means you kind of take what you get and have to make it work for the near term future. > > FWIW the original vision of the ESB was not to integrate together other ESB's per se, but to form an enterprise wide backbone that encourages and facilitates the development of new applications that are based on SOA design principles. The primary use case was developed around the reality of enterprises having contingencies of application server platforms and integration broker platforms that needed to be taken into account when building out the new shared services architecture across the ESB. Since then the appserver platforms and integration broker platforms have garnered additional capabilities to warrant being classified as ESB's but their underlying architecture has not changed that much (my current employer is included in this group of vendors, at least if you look at the ESB technology prior to the BEA acquisition). > > However, while that's worth mentioning for prosperity sake, its almost a moot point at this stage in SOA adoption. What I have found in practice, much to my chagrin, is that very few organizations (< 5%) have acheived a sufficienet SOA maturity level to build a large scale shared services architecture and therfore adopt a single ESB solution across the board, even though that's what they should be working towards. Most ESB adoption today is still driven by the applications teams wanting to integrate a small set of apps (< 10) for project by project single point solutions. > Dave > > > > > _____ > > From: htshozawa [mailto:[EMAIL PROTECTED] > Sent: Friday, July 18, 2008 8:54 AM > To: [email protected] > Subject: [service-orientated-architecture] Re: Seeley on ESB Proliferation > > > > The irony is that an "ESB" is needed to link ESBs together. :) > > H.Ozawa > > --- In HYPERLINK "mailto:service-orientated-architecture%40yahoogroups.com"[EMAIL PROTECTED], "Gervas > Douglas" <[EMAIL PROTECTED]> wrote: > > > "There's a whole space emerging among enterprise architects called ESB > > intermediation," he said. "They're finding that two or three different > > divisions of their company are using different ESBs from different > > vendors. Yet they're trying to build business processes across these > > ESBs. But the ESBs are designed to be their own center of the > > universe. How do you intermediate transactions across these ESBs?" > > >
