Why Traditional EAI Adapters Fail


Many years spent building integration solutions have taught me a great deal about what makes certain approaches successful. During this time, I’ve observed many projects where traditional EAI (Enterprise Application Integration) adapters were used to connect IT assets to the integration infrastructure.

The recurring feature in all of these projects is the staggering amount of legacy code that needs to be written to make, what should be a completely configurable adapter, actually work. This isn’t necessarily a criticism of those specific vendors’ adapters; instead it’s a comment on the futility of attempting to build configurable pre-packaged adapters for every possible use case. It just isn’t practical.

The configuration threshold

Common sense suggests that vendors should only produce a pre-built plugin when it could be reasonably deployed through configuration alone. If plugins require bespoke code on top of the configuration to achieve a certain design goal, then it implies that the configuration threshold has been crossed and that the better course of action would be to produce a more specific plugin to do the job.

Adopting this approach has impacted our strategy in two main ways; the rationalisation of plugins and the encouragement of end users to create their own mediation plugins.

Rationalise not compromise

Only producing a pre-built plugin when it can simply be deployed through basic configuration, undoubtedly leads to a rationalisation of plugins produced. However, looking at the range of adapters that other vendors offer, tells me that their customers must be cutting a lot of code or making a lot of compromises.

Contained code

Secondly, and more importantly, this approach leads to organisations opening up their architecture and exposing design frameworks to allow end users to produce their own mediation plugins. For example, hooks and mechanisms are available to deploy custom code within the mediation plugins container.

This “contained” code limits the need to write legacy code outside of the plugin. In my experience, such “uncontained” code is typically 8 to 12 times more costly to develop and maintain because it is usually developed within a non-productive, code-intensive, skill-shortage legacy environment.

By following this rule, organisations can realise significant productivity improvements. Whilst some coding is required within the plugin, the result will be a perfect fit, built upon and reusing existing services, and in keeping with the design approach of the embedded mediation framework.

A pragmatist stance

I’d certainly not advocate writing bespoke code for every mediation plugin deployment – far from it. In fact, the majority of our 1250+ customer deployments have been made using our configuration tools alone. The key here has to be pragmatism. Where there is a functionality delta between the mediation plugins and the IT asset being integrated, allow the code that will reduce the delta to be accommodated within the mediation plugin.

Such pragmatism makes it possible to package new “adapters” within days rather than months or years, offering customers a greater level of flexibility in how they bring packaged applications into a Service Oriented Architecture.

What about hosting the integration logic?

One thing that often gets overlooked is the runtime aspect of the adapters. Generally adapters are hosted locally, close to the target application. Hosting locally is one option, however an increasing number of customers want to host integration logic elsewhere, or use adapters to integrate on premise applications with cloud applications. Such flexibility is undoubtedly key and ties in to my belief in integration anywhere – and something that more and more customers are looking to harness.

SHARETweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Pin on PinterestDigg thisShare on RedditShare on TumblrShare on StumbleUponEmail this to someone

Jeff Bradshaw is chief technology officer at Adaptris. Jeff is responsible for the overall technical leadership of the company. He sets the development roadmap, and works with the Chief Architect to deliver innovative software that the "field" organisation can take to market. Jeff also works with the operations team to ensure that the solutions deployed within the company's four data centres are always available. In addition to this, he liaises with customers, to ensure that solutions exceed their requirements, and grow with their business. Jeff has spent his working life in the B2B arena. Prior to forming Adaptris, Jeff worked with EDI and EAI industry leaders Perwill and Frontec (Axway) and end user organisations DHL, and Equitas. Jeff has been engaged as a consultant with many large partners including Progress and customers including British Airways, Scottish Widows, British Telecommunications, and Carrefour.

  • Hkachoria

    Nice Article, Jeff we are working on one adapter to integrate 2 ERP and one challange we see for integration is the synchronous or asynchronous.

    synchronous approach give us a real time data trasfer but it comes up with limited resource on one side and which ends up low throughput.
    However asynchronous approach gives 100% throughput and better management of limited resource available on one end.

    What’s your view on this and what are factor needs to consider for right choice

  • Allthebest

    Monolithic code is bad, holding to predefined layers is good. The broader you enforce the rules about layers the more reuse you get. Location of components is based on desired service levels and points of failure isn’t it?
    I think it would be better to name the problem – unwise adapter construction rather than traditional EAI. Our teams have built integration in layers starting with Corba in 1993 through today.
    For me, this article does not make a case for any distinction about cloud that we haven’t always considered for remote integrations. I don’t see what service we are providing the industry in generalizing and simplifying former technologies and techniques. Vendors too often try to open a gap where none exists and none need exist. I’m sure the product that is silently being positioned in this article has benefits that don’t require the fictional characterization of 20 years of integration architecture. Further, the product is probably valuable because it follows the best practices of the discipline.