Over the past few months, we’ve worked on several application integrations. And each time we go through this process, I am struck by how every implementation has its own personality and set of challenges. 

In theory the problem of inter-application communication is simple; one merely establishes a standard protocol (TCP/IP, XML, etc.) and then codes or configures an application to use that protocol. 

In practice, however, it becomes a little more complicated; the first set of messages exchanged between supply chain systems always seems to take longer than planned. 

To save you some headaches the next time you plan a system upgrade or implementation, I’ve created the following list of points to consider:

During the planning stages it is natural to feel comfortable with a large, established software company and to feel a bit nervous about the execution capabilities of a smaller company. But, be wary. In practice, I have seen some of the biggest industry software providers vary wildly in their ability to hit milestones. 

The amount of time and involvement to complete the task really depends on the complexity of your particular business case and the experience level of the services team assigned to the modification and implementation scope. Minimize and contain this performance risk by establishing test integrations as early as possible in the project performance and create buffers in the schedule before critical milestones.

The most common integration problems consist of data format and security access issues. It is usually possible to test basic messaging using dummy data well in advance of the completion of complex underlying functional modifications. Most programmers may grumble about the dubious usefulness of exchanging a simple message header – and corresponding ACK (an abbreviation for the acknowledged receipt) – using dummy data. 

But from a project-management perspective, the exercise is very useful. It tests the readiness for integration of the physical IT infrastructure, the program build and configuration, IT security readiness, and vendor ability to support preliminary testing. 

Recently, we were testing a simple heartbeat message with a large supply chain software supplier, expecting this to be a routine one-hour exercise at most. We thought we’d see a simple ASCII “1H” character from the host and instead received an XML data stream, revealing an application configuration problem early enough to correct it easily. 

The test manager investigated the problem and found that one of his system configuration team members had not been on distribution for the client’s interface spec and had proceeded with a default standard. So, test early and often, and make sure the whole team has familiarity with the applicable specifications. 

Make sure your IT administrator is a participant in the conference-room pilot. I have seen many instances where access-point configuration, firewalls, and other IT security issues have caused problems with data-sharing (mapped drives), database access (can read but can’t write), RF terminal disconnects, and inability to connect to communication ports (the messaging worked fine in development, why doesn’t it work in test?). 

In each of these cases, the project team had been assured that all IT security policy issues were taken care of weeks in advance. Make sure your CRP includes an IT rep who can address and fix problems on the spot. 

System integration is an art as well as a science. Keep these points in mind and you’ll be well-prepared to address the inevitable problems that arise during this phase of the project. 

For those of you who’ve already experienced this phenomenon, tell us about your headaches.

-- Paul