Let’s say that you’re building a car. You’ve got your engine – a beauty of power and efficiency; your gas tank is made of a light alloy that’s just the right shape and size and strength; and your brakes are designed perfectly to stop your car on a dime. You’ve spent a lot of money on those high quality parts, a lot of time making sure the engine’s not underpowered and the gas tank won’t blow up, and you are now ready to put them together.

…and so you decide to use drinking straws to get the gas from the tank to the engine, duct tape the gas tank to a frame hastily built out of 2x4s, and stick brakes to some mismatched wheels using chewed bubble gum.

I’m not an mechanic, but i’m guessing you won’t get very far. It seems a no-brainer that the connections between the parts of the car should be as good as the parts themselves (something about a chain being as strong as the weakest link), otherwise, sooner or later, the whole thing will fall apart.

Why, then, do we have projects where the connections between “workhorse” components and the framework that ties it all together are an afterthought?

Back to the pillars… More often than not, these “pillars” of EAI are known as “PERL scripts”, “FTP”, and “Email”. If your inner *nix pit-bull is starting to growl, settle down: I’m not against any of those technologies. They all have their place.

Put all three together, and you’ve got a fantastic recipe for a great proof of concept for an EAI (or EII) implementation, if you’re starting from scratch.

However… there are few things more permanent than temporary solutions (that’s someone else’s quote; i can’t take credit for it), and after we add to that recipe a dash of “project ADHD”, a dollop of reuse, and a pinch of time, so your batch of reused proof of concept solutions turns into an unmanageable disaster of lost data, mismatched files, and inconsistent system state with little t-shooting information to help smooth things over with your irate clients (let’s hope there’s no legal action).

This isn’t to say that a working EAI implementation can’t be done using just scripting, ftp, and email. A competent team with discipline, documentation, and unbelievable employee retention can probably write a script-based, transactional, instrumented, flexible, secure, and transparent EAI system using nothing but PERL and FTP, and keep track of all the scripts, manage state and change control, et cetera, quite well – even over time.

The question is: if you have such a fantastic team, why would you waste their time doing that?

Instead, wouldn’t it be better to recognize your file transfer and data exchange process for what it is – an EAI or EII effort? Competent EAI demands a different skill set and a different approach to implementation and governance.

Unfortunately, without a top-down (sponsored and funded) approach to EAI, and/or a recognition of its importance, we end up with an accidental EAI solution, and, to finish off with the car analogy, get stuck carrying the engine on our own backs as far as we can take it.