Working in an IT dept. of a medium-sized business, we are often asked to “integrate” a couple of applications. The requestors may or may not have gone through the research necessary to the specify the integration they need. They may already have both applications, and they can specify the fields from one product that they simply want replicated to another, but upon furthur questioning, may still want either application to be used to enter these records and, of course, both applications should syncronize automatically. These “random integrations” can consume large amounts of time and may never fully satisfy the requester before one application needs an upgrade.

Unless the IT dept. has lots of time to spare, the only hope for success is to keep the project as simple as possible. Find out the ultimate goal of the requested integration. If management requires reports that include information from two distinct data sources; it may be possible to write a report that organizes information from both sources. That is a lot less work than to augment records from one source into another application. It’s also less likely to require extensive attention when either application is upgraded: it is simply a combined report. (Labor saving integrations will be discussed another day.)

For instance, let’s say you have one program that tracks employee’s time toward projects, and another accounting program that tracks income and expenses other than labor to these projects. The obvious report required would answer the question, “Which projects are making/losing money?” It may be a lot easier to combine data from both sources into a single report than to incorporate records from one database to another to effect the same report.

It may also provide more current data to leave the original databases alone. If users enter their time every day, a combined report would be updated daily. But if the accounting system gets an infusion of their time only at the end of a payroll period, then management would only see current data around payday.

Old data is of little use: even management cannot change the past. The more critical timing is, the less we want to rely on direct replication of records from one database to another. It’s also so much simpler: what will happen when a record that has already been replicated gets changed?

So there you have a case for keeping it simple.