Y2K Countdown: Knowing Where You Stand
In the last issue, I said that the minimum you owe yourself and your employer is to know were you stand by finding out how big the effort is to survive Year 2000 problems. If you aren’t already moving down this road, get going.
It is time to either get a tool to do the impact analysis or hire someone to do it for you. The impact analysis tool should allow you to plug in parameters to evaluate your repair or replacement efforts in terms of hours and dollars. This is called the application complexity model -- the better way to do estimates since little more than raw information comes from the lines of executable code model. This latter model just bestows a quick but meaningless number.
In a similar fashion a count of the number of database records does not express complexity or effort required -- just an implied value by database size (i.e., Big database assumes big problems suggesting big costs). But whatever you do, do not get tied up at the selection stage. Do it quickly with or without outside assistance and get on with uncovering tangible facts.
The output of this analytical step will present the facts necessary to chart your course through the next several months. It will also provide some foundation for making those resource requests. For example: There are 4,000 programs with 1,200 lines of code each. There are 192,000 date fields that require investigation and repair. Based upon the complexity, you will need X hours to repair and another X hours to test ensuring an uneventful transition past January 1, 2000.
What these tools do not “directly provide” is the business case, which management tends to fund. When will this begin to hurt the business, where and how much?
Within your analysis there are some facts that you can easily obtain to say as of this date we will no longer be able to provide inventory replenishment forecasts, sell a one-year insurance policy, issue a loan longer than X, or calculate interest properly. Seek and find the management motivators – it is usually whatever hits the bottom line or hinders your company’s ability to smoothly conduct business.
Given the right tool set, you can whip through this part of the project rather quickly as long as there are few bumps in the road. At the same time, it is possible to do automatic code remediation. However, the use of an automated tool does not excuse you from reviewing the changes, looking for questionable fields or seeking out the location of mismatched source and objects. Since nobody is perfect, neither is a tool that is made by people. With a little imagination though, you can use that same tool to recheck your combined remediated work efforts.
The road is littered with caveats and exceptions that hint that little action now will not hurt the end results. This is pure FUD [ fear uncertainty and doubt]. Compare the Year 2000 remediation effort to something everybody does in real life. When driving down the road, one tends to avoid every pothole, bit of trash or remains from accidents in an effort to protect the vehicle and avoid repair costs. It is only natural to take precautions to avoid unnecessary risks.
This column was written to urge you to evaluate your situation and take the necessary efforts to get beyond the Year 2000. Seek outside help if you have to, but get moving. The goal is to avoid complex paths, finish on time, intact, in business and out of court. If procrastination or doing nothing is the choice -- then loss of business and court are the default outcome.
Glenn Ericson has worked in the MIS area for over 37 years. After completing a successful 32-year career with IBM, he formed Phoenix Consulting (East Elmhurst, NY). For the last several years, he has concentrated his efforts on Year 2000 solutions and tools, the issues that revolve around MIS and the external infrastructures. [email protected]