Know Your Integration Points

The heartache of every systems administrator, development engineer, and software project manager is systems integration. No matter how promising a newly created application; a freshly purchased software package; or a long-awaited, new-feature laden upgrade; the business value rests in getting it to work smoothly within the existing company system.

If you are an experienced project manager, but new to the Information Technology (IT) arena, don't let the term integration confuse you. Integration simply means linking together all of your various software programs so that all of the subsystems work together to give you more functionality than you could gain from any one of the applications on its own. For example, you want data entry to occur only once and the information to flow smoothly to sales representatives, accounts payable and receivable, and into other systems that allow various employees to pull up the information they want, regardless of the software interface they open.

Unfortunately, it's often a tense time when new software upgrades are required. They may introduce trouble into a smoothly running process flow. Recently, we had a situation where an upgrade was scheduled for one of our systems. During the upgrade process, the vendor encountered unexpected errors.

There were several views, (pre-programmed screens configured to show specific segments of the database information) that were causing the upgrade to fail. The outside vendor doing our upgrade didn't know what the views were being used for, so they deleted them. The rest of the upgrade appeared smooth.

Several days later, a Service Desk ticket was submitted for a completely separate system that was having issues. Users weren't seeing any new customer data come across from the system that had been upgraded the previous weekend. As it turns out, the views that had been deleted, were the source for the missing customer data.

Since the source views were deleted to complete the upgrade, the synchronization process between the systems was broken. We had to spend hours troubleshooting the system before we came to the conclusion that the source views were missing. Then we had to re-create the deleted views, by hand, in order to get the two systems talking again.

Most IT departments have diagrams showing how the various components of their hardware systems are connected. But, we've found it is equally helpful to have visual representation of how data flows throughout our organization. Show the crucial junctures where data from one application flows into other programs.

We learned that having good documentation illustrating where your systems are reliant on one another, helps in situations like this. When we initially met with the vendor engaged to manage our upgrades, we could have shared our business flow diagram.

The initial upgrade problems could have been solved in another way, rather than deleting crucial views that fed other systems. We could have saved ourselves downtime, administrator stress, and come out of the upgrade process confident that we didn't have to live in fear that other, hidden problems had been introduced to the system.