[Source: http://geekswithblogs.net/EltonStoneman]

This was the title I settled on forthe interactive session at Microsoft’s Architect Insight Conference yesterday. We had a good turnout and some interesting discussions – thanks again to everyone who came along. The purpose of the session was to think about ESBs in terms of the value they provide to IT and to the business. The slide decks will be published on the AIC site, and this post adds some of the discussion points. Broadly we covered three topics: sources of value, components of an ESB architecture, and approaches to implementing ESBs. (The budget figures below are only illustrations…)

Sources of Value

Some of the key areas where value might be expected – in terms of ROI for the SOA/ESB approach, and more broadly in terms of IT being viewed as providing value to the business. The priorities will differ between organisations:

1. Project Efficiency

  • Reduced design, build, and test effort

An SOA goal to encapsulate logic within systems, prevent duplication and see the benefits of reuse. Provided the right governance and communication are in place, you should see value from projects being delivered more quickly, but possibly not at a level which will pay for the ESB (if the annual project spend is %u00a35m, you need substantial reductions in effort for a %u00a31m ESB project to pay for itself)

2. Operational Efficiency

  • Knowledge of system landscape and service cost
  • Rationalisation to reduce operating costs

Expected gains from streamlining operations may be higher than project gains (if the annual operational spend is %u00a330m, you only need 0.5% gain to pay for a %u00a31m ESB in a year). Large organisations with a disparate system estate will benefit from the centralized integration of an ESB, which can provide metrics around service usage – frequency of calls, time taken to respond etc. This enables informed decision making on rationalisation – virtualizing systems which are infrequently used, decommissioning unused systems, clarifying to the business how much a system actually costs.

3. Flexibility

  • Increased options for new technologies
  • Faster, higher-quality response to business change

Using simplified, standards-based communication makes interoperability an integral feature of the architecture. Commissioning new systems based on whether they can consume and publish ESB services may remove the need for customization, and make more systems available for consideration. The ESB also enables a strategic move to building bespoke systems using a composite application model for rapid development.

4. Cultural Change

  • Promotion of strategic thinking
  • Improvement of business-IT relations

Less quantifiable than other areas, but equally important. The move to strategic rather than tactical point decisions should provide consistent good design through new projects and ensure you’re not building up a new legacy of complex and fractured systems. Improved flexibility and quality should increase trust in IT, and prevent key business functionality being supported by rogue Excel and Access applications which are constructed outside of IT.

ESB Architecture

Common components of an ESB architecture. These can be evaluated in the light of the potential value they provide – which source of value can you trace a component back to, and will it provide enough value to consider it as a requirement:

  • Itinerary-based services
    • Transformation, routing
  • Service catalogue
    • Contracts, descriptions, SLAs, management
  • NFRs: reliability, scalability, performance
    • Potential compromise between latency and reliability
  • Development toolset – publish & consume
    • Ease of using the ESB
  • Service cache
    • Caching responses in the bus as a performance measure
  • Security
    • Authentication, authorization, identity management
  • Metrics/BAM – service usage & performance
    • Helps define system landscape and service cost
  • Centralised management – operations, errors, alerts
  • Standardisation/Interoperability – WSDL, XML/SOAP, WS-*
  • Governance & communication

Identifying the required components drives the technical selection of the ESB. We talked through a few different implementations, all of which were suitable in different situations:


  • Strategic

Full ESB delivered as independent project, with no active services or consumers

  • Tactical

Skeleton ESB delivered alongside tactical project, with few active services and consumers

  • Pragmatic

Project scoped to deliver full ESB with logical subset of active services and consumers

One of the difficulties in adopting an ESB strategy is defining exactly what you will need the ESB to do. Messaging load, security and operational requirements may be best-guesses until the ESB is in place and active. Implementing a standalone ESB in a project is dangerous as the best guesses may not be accurate. Delivering an ESB alongside a tactical project which publishes and consumes services has the advantage of ensuring the ESB has all key functionality, but may result in an under-specified bus which needs enhancing as it becomes more widely used. If you have the option of pragmatically implementing the ESB – take the best-guess requirements and a core subset of existing integrations, and deliver the ESB and migrated integrations as one project – you’re more likely to establish a bus which provides exactly what you need.

Takeaway from the session – an ESB will only provide value if it’s actually used. It needs to be easy to find, publish and consume services, and routing messages through the ESB shouldn’t significantly impact performance.