Lets imagine Goldilocks, the senior software architect, who knows all about fairy stories, but is all grown up from her days tasting porridge. With integration projects eating up two-thirds of her overall IT budget, and the costs of maintaining and evolving integration solutions spiralling out of control, she has known for quite a while that she has to change the way her integration projects were currently designed and delivered.

In particular, Goldilocks saw four basic issues with her current situation: A couple of years back, the idea of standardizing on a single, albeit proprietary, approach for integration from one vendor sounded tempting, but the reality never panned out like that.

The Enterprise Application Integration (EAI) product she had picked had promised a lot in the area of ‘business agility’, but had failed to deliver. Next project costs remained high, and solutions were costly to change or evolve. Worse still, these complex and proprietary products also required scarce skills. As a result, maintenance and support costs were astronomical, and initial development was a slow and expensive process.

Finally, she discovered that for many of the integration projects, these EAI products were too unwieldy to use and her developers ended up building from scratch using not very well suited Application Server products.

In short, current approaches were far too costly, and were failing to do the job required. Worse still, Goldilocks found herself with unexpected integration problems – how to connect together the islands of integration.

Enter The ESB

Then one day, Goldilocks was wondering about what approach if any would solve her integration problems when she came across a new clearing in the dark wood of integration and the shiny new home of the Enterprise Service Bus. Goldilocks realized that although there are some different views about what exactly an ESB is, but most vendors and analysts agree on at least some of the core elements, and the benefits associated with them:

• ESBs are standards-based, relying on standard skills, and thus solutions based on the ESB should be more cost-effective to build and maintain – no specialist staff required.
• The use of industry-wide standards such as XML, Java and BPEL means that no organization need rely on a single vendor for all its integration needs. Multiple products can be used alongside each other – picking the best product for each challenge.
• By enabling a “service-oriented architecture” (SOA), ESBs promise to deliver real business agility. Re-use becomes a reality and existing applications can be extended or evolved without costly re-engineering.