I had the opportunity to give a talk last Wednesday night at VanDev Meetup (Vancouver’s Software Developer Network).
In this talk, I have presented a few criteria to help developers and architects decide between using ready-made EAI tools versus custom built solutions. I have discussed the identification of contexts, patterns, topologies and decision factors that can help favor one approach or the other.
If you’re hesitating between walking the ad hoc coding path or the integration tool path for your integration projects, then keep reading as the following may help you.
Clicking on the above image will take you to the presentation’s slides.
Context
The context in which an integration project happens is an important determinant for the fact that using integration tools will be truly helpful.
- Changeability – When the systems that need to be integrated can not be easily changed, using a tool that has the necessary mechanisms to connect to, monitor or poll the inflexible system can be of great help. Conversely, if a system can be altered to speak an inter-operable protocol (like SOAP), ad hoc coding can be considered.
- Deadlines – Time constraints can help favoring a tools based solution, provided there is a good matching between the problem space and the support offered by the considered tool.
- Politics – In some organizations, application development projects are big dramas: an ad hoc solution to integration may fall into this category and turn into a death march. Bringing a tool in the equation can help, as the integration project suddenly shifts ground: it becomes about deploying and configuring an existing solution, not developing something new.
Patterns
Being able to identify enterprise integration patterns in your project is a good way to define if a tool will be helpful or not, as tools often offer ready-made implementations of these well-known patterns. There are 65 of them so I can’t discuss them all, but here are a few for your consideration:
| Pattern Icon | Name | Rationale |
|---|---|---|
 | Channel adapter | The capacity you’ll need to integrate a system to messaging channels. |
 | Polling consumer | When monitoring a resource in a non-invasive way is the only option for integration. |
 | Message Translator | Whether you’ll need to transform a proprietary format into another one or standardize all your message payloads into canonical forms. |
 | Message router | You may need advanced logic to route messages between integrated system, based on properties or payload of these messages. |
 | Wiretap | Being able to divert copies of messages opens up new integration possibilities. |
Topologies
Identifying higher-level patterns, in the form of topologies of systems, can help you decide for tools that intrinsically support them.
- Store and forward – Being able to accumulate messages until a system comes back online and distribution can happen is often required when integrating systems that were not designed with high-availability in mind.
- Hub and spoke – Sometimes, routing decisions must be taken in centralized manner, freeing the different systems from carrying the smarts required for this. A centralized messaging hub can help achieving an efficient smart routing strategy without affecting the integrated members.
- Orchestration – The capacity to execute short to long-lived message-oriented processes between integrated systems reveals the need for tools that support the notion of orchestration.
Factors
Besides the previously stated criteria, there are many other factors that come into play when deciding for (or against) a tool as opposed to a custom coded solution. I have talked about three that I’m detailing hereafter:
- Growing complexity – An ad hoc solution that evolves over time to support more and more features ends up complex, suffers from bit rot and becomes a burden to maintain. Using a ready made tool transfers the problem of maintenance to the tool builder, letting you focus on the task at hand only.
- Learning curve and idiosyncrasies – Because they’re feature rich, most tools for integration are characterized by a learning curve that is significantly steeper than the one incurred by using a development language and its SDK. Moreover, each tool carries its own idiosyncrasies that can potentially send you back to an unexpected learning cycle.
- Axes of tension – Finally, when it comes to picking up a tool or developing something, diverging interests between in-house developers, software vendors and consulting firms (who sometimes work with vendors) may blur the picture. Interestingly, a converging core of interests can be found when open source solutions are envisioned.
Do you have other criteria you’re considering when weighting between using a tool or writing an ad hoc applications or scripts for your integration needs? Please share them in the comments!
