Image: Diagram of the control panel in the cockpit of Apollo 13’s Lunar Module Aquarius, which circled the moon in April 1970, by Steve Jurvetson. CC license.

Nearly all new applications you add to your enterprise will need some level of connectivity to your existing systems, as well as to systems outside your enterprise, and so integration is a key part of your implementation plan.

The problem is this: every software firm will tell you their application can be integrated to just about anything. Yes, anything is possible, with enough money and effort.

Here are some key areas you should be familiar with:

An Application Programming Interface (API) is a protocol used by software components to communicate with one another. It can be source code, or written specifications. A good question to ask the software vendor is whether it has developed APIs for interfacing with other programs, and which programs in particular.

You’ll still have work to do if the vendor has well-developed APIs, but at least you’ll know someone sat down, thought about, designed, built and tested some form of integration — all work you shouldn’t have to re-do. One area of the money pit avoided.

Electronic Data Interchange (EDI) is a standard for electronic messaging of commerce between two entities and frequently between two different systems. EDI was established in 1996 by the National Institute of Standards and Technology; it has widespread use around the world as a replacement for paper-based transactions between companies.

The application you’re considering or your company may use EDI as its standard method of interfacing other systems, especially outside your enterprise, and that is fine. But don’t assume that EDI means it’s as easy as plug and play, because while EDI is supposed to be a standard, it has been customized by enterprises for their own specific needs and has many formats, and in addition there are two standards for every EDI message — UN/EDIFACT, and ASCx12. It’s not unusual for companies to maintain 20 or 30 or more partner-specific EDI data maps.

EDI has limitations: It’s prone to failure if data is incorrect or not recognized by the recipient’s system, or if changes are made to its structure without thorough testing. EDI is also like sending data through a tube — no one sees the data except the sender and the recipient, so if you want to exchange data or transactions with another trading partner you have to build another tube.

Don’t underestimate the time and cost of integration via EDI. My experience with EDI is that it takes a team of people to maintain it; to monitor the pipes, to push through transactions that have stalled or encountered errors, and to develop new connections or changes to existing ones. If EDI is how you will integrate applications, just be aware of the costs and effort involved. [pullquote]EDI is not standard, not necessarily low cost, and certainly not 100% reliable.[/pullquote]

If EDI is the way your customers want to exchange with you, you will have to accommodate. To mitigate the negatives of EDI, you can contract with one of the business-to-business (B2B) commerce companies that have emerged in recent years. These firms – GXS/OpenText, SPS Commerce, IBM/Sterling Commerce – among others — will host your EDI integration, monitor your connections 24×7, react to and solve messaging failures, and map new connections to trading partners.