Skip to Content

ESA – EAI – Need for a perspective


The content for this blog was triggered of by an offline chat I had with a fellow geek from an integration competency in a leading SI over the change in integration landscapes brought in by host of new age products like ESBs, adoption of standards thro’ webservices , challenging the domination of EAI products in pursuit of a new goal of all integration work centers- towards SOA(ESA).

The Issue

Apparently one of the discussions veered away towards the problem of having to deal with the multiple middleware islands sitting in the typical customer’s landscape(having to foot an heavier bill owing to the challenge , numerous middleware installations now pose over his looming infrastructure).This now poses a greater challenge of consolidating the integration landscapes,with perhaps an all pervasive EAI tool to hold these disparate middleware islands together.The dillemma of owning Mother of Middleware (MOM)(* excuse me for reterming the usual meaning but couldn’t think of a better one on top of my head) to gain every cent out of making my current middleware talk to each other

The Big question

But question is , Is this the right approach to governing our IT strategies, as ultimately focus of business is not only to gain the maximum ROI from the business systems in place but also to minimise the risks involved from creating multiple failure points in the system!!!Risks arise due to problem of having to modify the interfacing points between the middleware (legacy Middleware with new MOM) as owing to changes within the interfacing structures

Typical MOM fiasco in an InOrganically grown organisation

So What do we do???

One answer to this would be evolution of a good ESA Architecture which has its own anathema in the continuing cycle of evergrowing hype over standards and dilemma of having to entrust your SOA to be built over a single vendor platform. But my view point is that regardless of the implementation, having a birds eye view of the overall technological landscape cross org across multiple integration landscapes is critical to establishing resonance over the approach and give a better clarity over the goal.

Offcourse challenges exist in having to bring the various teams (cross middleware, cross apps, business process owners) to sit across and agree towards working out the architecture but this is more a human challenge towards managing the individual team priorities and really needs a sensible leadership with a vision and ability to push the IT arms towards organisational priorities.

Take Away

One Major Advantage which immediately comes to mind over adopting ESA replacing architectures which employ standard middleware connectivity is that it lets businesses think in terms of Business Services.Call is going to be, are we going to use more middleware for running businesses or are we gonna adopt more flexible technolgies which can help us expose the business functionality with ease and perhaps better agility and with more interoperability.One answer to this is use of Webservices – with WS Basic Profile 1.1 we get all this and more(as i had mentioned 6 months back in a previous weblog). But again watch word is the evolution of standards in this area, particularly in the security standards is not yet through the hype cycle.

Though latest reports on this front envisage use of webservices in business critical functions but point is that this entails exposing vital data on the web(or on the net), which needs to be done only after a thorough analysis on the security risks you face from choosing a particular security standard.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.