ESB Part 2 : The Shapeshifter…

So the obvious, and much publicised, question one asks when hearing about the Enterprise Service Bus, is what is it? Is it a style, is it a thing, or is it #*%!!

I have a particular take on this borne out of my own experience in having to justify such a thing within a large scale enterprise architecture programme. As per my earlier post on SOA==WS?, one’s perspective on SOA has a huge bearing how the ESB shapeshifter can be manifested within your problem-space.

 In a traditional EAI landscape, we centralise the integration problem. This means that we enable the interacting systems to utilise local dialects when firing requests into the EAI space. The EAI brokers then deal with the transformation from external dialect, through the common, canonical dialect and into the external outbound dialects of the target systems (I am generalising in a big way however….). Difficult business integration problems are pushed away from the endpoints into the magic-in-the-middle, and this is where much of the EAI bad-press has come from, simply because it trades in peoples pain ! Would we need it if integration was easy ?

 So my primary driver when looking to evolve my enterprise integration roadmap to support the unfolding SOA transformation, was to decentralise the pain and give it back to the owners. Not just to reverse the trend, but to drive convention and middleware infrastructure templates back to the edges of the relevant IT domains such that the runtime becomes federated.

This federation has an implicit but significant reliance upon consistency and contracts at the endpoints, whilst opening out a consistent, scalable messaging conduit (finally!) between the domain brokers. Standing back from this – we have clients and servers adderssing the transformation in/out of service contracts at the edge of their domain, with common representation, messaging and infrastructure management in the space between. The EAI Bus architecture was taking shape.

The most significant thing in my opinion was the reduction in diversity by prescribing inter-domain standards. Finally the EAI brokers didn’t need the full range of COTS and Technology adapters they were usually encumbered with, nor did they require the high-end process-management abstractions, and as a result the technical requirements on these components reduced dramatically.

Over time, the movement of endpoint-specific transformation, standard messaging and document convention and runtime independence to the endpoints became analagous with the vendorised ESB concept which came along subsequently.

 However – my experience places the term ESB (and with major Emphasis on the ‘E’) as a scalable Enterprise framework, incorporating disciplined distribution of the integration problem space, and the consistency evolving int the messaging backbone.

I do see, and understand alternative perspectives (and I will use the term ‘eSB’ where the casing of the ‘e’ implies the technology being used in a less than Enteprise capacity. Where we see a the (systems not Enteprise) architecture incorporating a single messaging and transformation broker – supporting service contracts at the edges…implying the clients and servers are already emitting/consuming the expected dialect. I’m less convinced by this model and the shades of grey between this and my own perspective – purely because I am focused on the Enterprise ‘E’ in ESB as opposed to the ‘e’ in eSB…

Advertisements

One Response to ESB Part 2 : The Shapeshifter…

  1. JonC says:

    Dealing, as it does ,in the pain of integration the ESB cannot help but be percieved as yet another silver bullet by those wanting to believe.

    A federated model and distributed messaging backbone still does not ensure that responsibility for the contract and compliance with the Enterprise standards is assumed by the system/service endpoints. Without the discipline you mention and ownership of the integration problem the system owners do not just delegate the development of the ESB solution to a specialist group but also abdicate responsibility for compliance and evolution of their service as well.

    If this does happen the domain expertise so essential to success does not become part of the ESB solution but remains outside and is only given grudgingly and sparingly. The enterprise discipline and governance of the integration space is the hardest part to insinuate into BAU .

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: