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.