>The key point that I make to my clients is that an ESB should not be viewed as the core of the >services infrastructure, and that not all messages must flow through an ESB. Only those messages >that require the services of the ESB should flow through the ESB. + 1 >Organizations that rely too heavily on ESBs wind up doing integration rather than designing shared, reusable services.
Indeed! I've often found that folks who have deployed or are thinking of deploying ESB's *without thinking through exactly where the ESB fits in the SOA Infrastructure* have a tendency to put their service analysis and design thinking on hold. Anne, by all means keep on fighting the good fight! You are not alone. Regards, - Anil ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Anne Thomas Manes Sent: Friday, December 29, 2006 8:20 AM To: [email protected] Subject: Re: [service-orientated-architecture] Bradley on Senior Management & SOA Being one of the "remaining hold-outs who continue to argue strongly that ESBs are irrelevant or transitory".... (By "ESB" I'm referring to products such as BEA AquaLogic, IBM ESB, and Sonic ESB.) Actually, I don't say ESBs are irrelevant. I view an ESB as a useful component in a services infrastructure. It provides a means to expose legacy application functionality as services, and it supports mediation (although not efficiently) and sometimes orchestration. But it's just one of many components in the infrastructure, along with service platforms, SOA management, XML gateways, registries/repositories, and other components. The key point that I make to my clients is that an ESB should not be viewed as the core of the services infrastructure, and that not all messages must flow through an ESB. Only those messages that require the services of the ESB should flow through the ESB. Most clients have a hard time with this concept -- the typical response I get back from them is, "so what -- we go back to point-to-point connections?(!)" At which point I try [again] to explain the difference between SOA and integration. SOA is about refactoring shared capabilities into services that applications consume -- in the same way that applications today consume DBMS services. Do you need a broker to sit between an application and a DBMS? This is actually the biggest issue that I have with ESBs -- they are fundamentally focused on integration rather than service-orientation. Organizations that rely too heavily on ESBs wind up doing integration rather than designing shared, reusable services. I try to make it clear that depending on a single product is harmful to a SOA initiative. Most large organizations already have multiple ESB/EAI technologies deployed, and these systems are not going to go away just because they've deployed a new ESB. Unfortunately (at least from my perspective) I'm only one voice providing advice to these clients. The reason that ESBs take up such a big percentage of current spending is that the vendors tell them that an ESB is a requirement for SOA. And enterprise clients *want* to hear that they can buy one product and get "instant SOA". They don't want to hear me tell them that an ESB is not the universal SOA solution. But most clients that have gotten beyond the early planning and pilot stages have begun to realize that my advice is worth listening to. Anne On 12/29/06, Gervas Douglas <[EMAIL PROTECTED]> wrote: <<A nagging worry among SOA advocates over the last year or so has been that SOA was not being understood or bought into by C-level management. A GCR's survey - sponsored by BEA - shows that this is now changing in the surveyed companies. It should be stressed that this survey was only of large organizations which had taken the first step already and deployed some SOA. The survey states that CIOs and CTOs are now the leading sponsors of SOA programmes. While this clearly demonstrates what most of us engaged in SOA programmes or advising such programmes already know: SOA is progressing along the normal adoption curve from pilot to more systematic deployment and as this happens the sponsorship moves up the management structures. Two nuggets which I found interesting were: * The second biggest cost (after software infrastructure at 40% of total spend) was staff reskilling - at 30% of the total cost. This should not be a surprise - SOA puts significant new strains on IT staff both in terms of technical skills and more importantly governance and collaborative skills. * The largest components of the software spend was on ESBs and security (both at 24% of that 40% of total). This suggests that the ESB has been recognized as a keystone product in a SOA strategy. This may come as a surprise to the remaining hold-outs who continue to argue strongly that ESBs are irrelevant or transitory. Two caveats worth noting: While it is good to see sponsorship at the CIO/CTO level, as a business strategy SOA needs line of business sponsorship as well. If SOA remains only an IT strategy, organizations will risk not gaining the full benefits. And with regard to the uptake of Enterprise Service Bus products, what isn't asked or answered by this survey was what the respondents meant when they said ESB - a subject which I will return to.>> You can read this at: <http://www.ebizq.net/blogs/soaroads/2006/11/soa_now_in_the_executive_su ite.php > I get the distinct impression that non-IT management attitudes to SOA (and other relevant technological concepts such as BPM, SaaS, mashups etc.) varies very much according to the market being surveyed. I have been reliably informed that CxOs of large enterprises in Nordic countries (Scandinavia plus Finland) are well aware of the concept of SOA. From my experience of that region, this is no geat surprise to me. Spain is another competent early adopter country where they seem to be getting to grips with SOA. I would also expect countries like Australia, NZ and South Africa to be demonstrating competence in this area. From some of the contributions to this Group, it would seem that there is a high level of SOA awareness in Germany and the UK. Does it however extend to non-IT CxOs?? It would be interesting to read your impressions on the subject. Happy 29th December! Gervas __.
