Leave trip wires to track modules
March 22, 2007
In his spare time, Mike Anderson of the Greater Houston 3000 user group helps a few local companies get ready for migration. Yesterday he shared a little trick with us. Leave bits of code, routines that act as trip wires, inside your forest of application modules. Go ahead, do it today, no matter how soon you will pull the trigger on your actual migration.
First, this counts as migration work. Creating code to identify when a module gets used, and report back to Routine Counting Central, can be the prelude to a savvy migration. Because like our At-Large Editor Birket Foster has said so often in the many talks he's given, you want to know how much of your code you will need to migrate.
Second, this kind of development can be a positive thing to report to a company boardroom. "Our migration project has begun with detailed research on the size of the task. Specialized code is being placed in our company applications. This software will deliver metrics we need to create budgets and schedules."
That's a report which may be good enough to buy some time to do the work correctly and efficiently. It's also true, too — this code must be specialized, because you will need knowledge and access to your source code to leave this trail of trip wires.
This tactical work won't help you nearly as much if your strategy is to replace your apps with what Foster likes to call Commercial On The Shelf (COTS) software. Yes, the use of these checking routines might help your search process for the best replacement package. But you're more likely to be ticking off company practices and business rules while you shop to replace.
It might be difficult to job out this "routine" task to an outsource supplier. A developer who's unfamiliar with your company's code could bill for quite a few hours figuring out the best spot to leave a crumb of this counting code.
HP has a tool to help inventory HP 3000 systems, the SIU, offered for free at the HP Jazz Web site. But the SIU won't report how often your data sits in each of the many trees in your forest of modules and applications. The SIU only counts and identifies files on your 3000.
This kind of bread crumb routine would be most useful if it could garner information over time. You'd think that six month-end closings would be enough to check if a module is being used. On the other hand, you might want to make sure one of those months is the end of a calendar year.
But every month in which your code does its checking might save many hours, or dollars, during the migration itself. Several migration suppliers charge by the line of code. Modules that you need not change would incur no charges, we figure.