Years of building integration solutions has taught us a great deal about what makes certain approaches productive or not.  We've observed many projects where traditional EAI Adapters were used to connect IT Assets to the integration infrastructure.  One constant in all of these projects was the staggering amount of legacy code that had to be written to make what should be a completely configurable adapter work.

As a result, when designing the Embedded Mediation Framework that our Mediation Plugins are based upon, I made a commitment to only produce a pre-built plugin when it could be reasonably deployed through configuration alone.  If our plugins were to require bespoke code on top of the configuration to achieve a certain design goal, then it suggests that we'd crossed the Configuration Threshold and would be better off producing a more specific plugin to do the job.
This approach has had two key impacts on our strategy.  Firstly it has lead to a rationalising of the number of plugins that we produce.  We currently offer over 50 plugins and still plan to produce many more.  Looking at the 300 or so 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 most importantly, it has lead to us opening up our architecture and exposing our design framework to allow end users to produce their own Mediation Plugins .  The result is that with the Adaptris EMF , we provide hooks and mechanisms to deploy custom code within the Mediation Plugins container.  This "Contained" code limits the need to write legacy code outside of the plugin.  In our 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.

This approach has lead to very real productivity improvements, because whilst there is some coding 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.

SOME CODING REQUIRED?

This doesn't mean that we advocate writing bespoke code for every Mediation Plugin deployment.  Far from it.  In fact the majority of our 200+ deployments have been made using our configuration tools alone.  However, integration experts respect our pragmatic stance that says that where there is a functionality delta between the Mediation Plugins and the IT Asset being integrated, we allow the code that will mediate away that delta to be accommodated within the Mediation Plugin.
Using our EMF it is possible to package new "Adapters" within days rather than months or years, this offers our customers a greater level of flexibility in how they bring packaged applications into a Service Oriented Architecture.