Enterprise Abstraction

What's an ESB

ZDNet asks:  What's an ESB?  It seems to me the best definition is that it's a burgeoning new market for a lot of software companies.  That always makes me a bit wary.

Wikipedia defines an ESB as:

an enterprise service bus refers to a software architecture construct, implemented by technologies found in a category of middleware infrastructure products usually based on Web services standards, that provides foundational services for more complex service-oriented architectures via an event-driven and XML-based messaging engine (the bus). An enterprise service bus generally provides an abstraction layer on top of an Enterprise Messaging System which allows integration architects to exploit the value of messaging without writing code. Contrary to the more classical EAI approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary.

perhaps we should all contribute our thoughts in that forum.

Ron Ten-Hove offers the more succinct:  " An Enterprise Service Bus (ESB) is a distributed middleware system for integrating enterprise IT assets using a service-oriented approach."   It may be worth mentioning that Ron and others have been working on the Open ESB project.

Do I need one?  I'm not sure.  I've heard many say that with good planning of services, and a well thought out infrastructure, depending on your needs and circumstances, and ESB is not required, but that it could certainly make life easier.

A strategy I've heard is that it's wise to plan your services as if you don't have one, and are not going to have one... essentially treating the ESB as an addition or an afterthought, thereby encouraging robust and efficient service design.  Sounds like sage advice.  I've also heard that a good governance structure around SOA would be important before implementing an ESB. 

Perhaps then it would be best to wait until things are a bit more mature before diving into the still undefined world of the ESB?  It seems pretty clear that a good strategy would be to concern ourselves with the architecture first, and ESBs second.

SOA middleware and ESB study

The AberdeenGroup is causing quite a stir with its recent study of 120 organizations and their adoption of Enterprise Service Bus (ESB) and SOA middleware technologies.  They claim:

• 90% adoption of SOA technology amongst the surveyed organizations

• 5%/year savings on integration costs amongst those organizations who have adopted SOA

• 40% of IT budgets are being spent on integration expenditures due to business process redesign and customization challenges

Note the 90% adopting SOA technologies.  This is perhaps not exactly the same as saying that 90% have adopted SOA.  The report is about ESB's and SOA middleware technologies specifically.  It's a subtle but important distinction.  Nevertheless, it would seem to imply a huge adoption of these technologies, and that certainly implies something.

They indicate 3 flavours of SOA and SOA suite adoption:

• SOA Lite is for users who are primarily deploying web services that do not require mission-critical capabilities such as high-volume scalability, high availability and failover, management, governance, and security.
• SOA ERP is used by companies that are choosing to deploy SOA surrounding their ERP application software.
• Enterprise SOA requires and uses mission-critical SOA middleware suite capabilities.

(-- from aberdeen.com)

Do enterprises require SOA middleware suites for mission-critical services?  I'm not sure.  There's perhaps something to be said about designing your services and service architecture for the required mission-critical features first, and adopting ESB/Middleware as an ease of adoption feature.  Vogels certainly encouraged this approach, but, not everybody's Amazon.  Having not yet approached SOA adoption from the indicated "Enterprise SOA" level, it's hard for me to say.  Nearly half the organizations in the study were classified in the "SOA Lite" category.

Other tidbits include:

• 1/2 of respondents are using Java J2EE technology in their SOA adoption.
• 1/3 are implementing on both the Java and Microsoft.NET platforms.
• Half of the respondents are considering enterprise application integration (EAI) side-by-side with ESB purchases.
• Average organizations are using  ESBs and SOA technology to reduce IT complexity, the costs of complexity, and to speed IT implementations
• Best in Class (BIC) organizations are driven by the need to align with the business and re-use applications via Web services.

With regard to SOA rollout and ESB adoption generally, the report says:

ESB adoption is a large enterprise phenomenon, with only about 7% of large companies
saying they have no plans to start using an ESB in their SOA rollouts. However, the majority of mid-size organizations and almost 80% of small companies have no plans to use ESBs, yet they are already designing and programming SOA applications. These data indicate that smaller companies are adopting the standards of SOA and the related programming, but are not yet ready to adopt an SOA style of development for missioncritical applications — or they will rely on SOA ERP to close the technology gap.

A full copy of the report is available free (with registration):   Enterprise Service Bus and SOA Middleware:  Next Steps in SOA Series - June 2006