Tips for Treating 2000 TraumaMaking your company's legacy systems 2000 compliant is an either/or proposition: Either you do it, or you can toss your investment in equipment and applications in the dumpster when January 1, 2000, rolls around.Unfortunately, there's no anesthetic to take the pain out of your corporate Year 2000 Trauma. But if you start now and follow the tips outlined in this article, the operation won't hurt quite as much as it otherwise might. by Steven J. Davis Two more years; only twenty-four more months. That's how much time your company has to become Year 2000 compliant. And it's a deadline that can't be postponed. The pending Millennium Crisis ranks as the most significant problem in computer history. And the irony is that the industry has been aware that the problem was coming for decades - lots of time to plan and prepare - but there are still plenty of companies who have not yet taken action. To date, only about half the companies in Japan, mostly the large financial firms, have converted their systems to handle 21st century dates. And time is running out. If we ignore the problem, maybe it will go away...
Another element is that some companies, in spite of all the press coverage that has been devoted to the topic, do not yet accept the Year 2000 Problem as real. Since it hasn't physically (or financially) impacted the company yet, the narrow-minded managerial mindset typical in Japan says, "If it's not a problem yet, why fix it?" Still other companies are waiting and hoping for a "magical antidote": a third-party software solution that will automatically convert all the dates, and thus make their systems Year 2000 compliant with the click of an icon. Unfortunately, this will not occur. Although there are software tools available to assist in the conversion process, these tools cannot automatically adapt the program modules wherein the system code is defined. Nor can the software tools identify every diversified date-code string; there may be many inconsistent date strings within each program. Factors to consider
The actual programming to achieve Year 2000 compliance is simple. Expediting the necessary conversions to finish with the next two years, however, is problematic. There are six major factors to be aware of when contemplating Year 2000 compliance: Supply and demand - The economics of hiring engineers to deal with your Year 2000 problem are pretty straightforward: As the year 2000 draws nearer, the demand for skilled engineers is increasing. And as the demand increases, the resource pool of available engineers grows smaller. I personally know of a few very large projects for the local offices of some US and European financial firms that are employing more then 200 mainframe, COBOL, and assembler engineers. These skilled Y2K engineers will be working full-time on these projects through the year 2000. And many of the remaining available engineers will soon become busy with large projects from other companies who are now preparing to implement their Y2K solutions. What this means for your company's Y2K project is that, as the demand increases, the supply of available engineers decreases. And as the supply decreases, the price (the cost to your company) increases. Increasing costs - One important way to save the greatest amount of money is to begin your Year 2000 conversion now. If you wait too long to start, the extra cost can be incredible. And the longer you wait, the greater the cost will become. The price per line of code (before impact analysis) in late 1997 was about \75. But that will not be the price next year, or even next quarter. Expect the price to more than quadruple by the end of 1998, up to \350 per line of code. And if you wait until sometime in 1999 before taking the plunge to become compliant, the price may be anywhere from \500 to \1,500 per line of code. No one can predict where it will peak.
If your company has 1 million lines of suspect code, for example, and you contract for conversion now when the price is \75 per line, then you would be paying \75 million. But if you wait one year, you may be contracting at \300 per line of code and so paying \350 million - an extra and unnecessary \275 million burden. (Note, too, that if you have 1 million lines of code total, the conversion process will cost \75 per line, or \75 million. If you first do an impact analysis, the conversion will likely cost about \300 per suspect line of code, and the average number of suspect lines of code [those likely to be impacted by date conversion] per million total lines is 250,000. Two different pricing strategies, but both end up costing the same.) Utilizing offshore resources
The first advantage is price, since the cost of offshore development is typically 30% to 50% cheaper than the cost of doing it all in Japan. The second is the skill pool diversity. The education and project experience, along with the tools and hardware, that are available offshore are impressive. A third advantage is the time that you will save, which impacts directly on the cost. The total time it would take to set up and complete an 80-man-month project offshore is half or even less than the time it typically takes to do development in Japan (due to the greater number of available engineers overseas). Maintaining control is the fourth advantage. Utilizing a combined onsite and offshore strategy, with engineers onsite to manage the client's needs, but all coding, development, and unit testing done offshore, is the best method for maintaining customer confidence and control. [For more about offshore development, please read "Decreasing Computer Budgets in Japan" in our February issue.- Ed.] Spreading out the budget
Special assistance has been set aside, in the form of low-interest, long-term loans, for those companies that qualify. These loans are available specifically to assist companies in Japan in becoming Year 2000 compliant. (The last thing the Japanese government wants is for the nation to experience a temporary economic drop due to companies not being able to operate past the year 1999.) These government-established loans for the Y2K effort offer a new opportunity for decreasing the amount your company must budget. By utilizing this special government program, you will be able to allocate your Year 2000 costs over two or three decades. This makes economic sense. If your company is able to allocate the Y2K budget over several years, then your investors (private or public) who care only about the bottom line will not suddenly see a large dip in profits due to the sinking of an exponential sum of money into becoming Year 2000 compliat. No, dealing with the Year 2000 Problem isn't an easy task. But the longer your company waits, and the less planning you do, the worse the trauma will be. Steven J. Davis is Division Manager of Offshore Development at Japan Information Engineering Co., Ltd. (JIEC). For more information (or to ask about a free seminar) relating to the Year 2000 Problem and reducing computer budgets via offshore development, you can contact him at davis@jiec.co.jp, or phone 03-5351-5968. |