Analyst estimates indicate 20 percent of business applications will fail because of invalid date computations in 1995 (0.6 probability), and that without corrective measures, this number will increase to more than 90 percent by 1999 (0.8 probability).
The issue will also not be solved via procrastination. Unlike other vexing IT issues of the 1960s and 1970s, analysts agree no panacea is forthcoming from the vendor community. Therefore, the year 2000 date change creates a major problem for all government enterprises with computerized information systems that want to avoid the specter of government operations lurching to a halt as systems fail when the clock strikes midnight on Dec. 31, 1999.
ORIGIN OF THE CRISIS
Put simply, the problem is the absence from almost all software of the two-digit century value within a date-field that distinguishes dates as either 19xx or 20xx. For example:
Birth year: 1954
Age in 1999 is: 99 - 54 = 45
Correct calculation should be:
2000 - 1954 = 0046
The problem was created by limitations of earlier technology and the historically higher cost of storing information. In the 1960s, the dominant method of entering data into a system was the 72-character key-punched card (with eight characters reserved for control information). This advocated a data-entry strategy that optimized characters because of limited space.
Additionally, early databases (e.g., IMS) were designed based on hierarchical structures and optimized for transaction-based processing so the relative dates of a transaction were stored in the same database record as the other transaction data. This translated into a two-bytes-per-date savings by not storing the century value when a date was stored, and was a tremendous cost saver at the time.
The problem then spread into application code because applications are designed based on data, and the data was stored without the two-digit century value. Even when organizations migrated to relational database management systems, the date data were not always modified to include the century, and due to costs the applications were rarely modified or upgraded. The emphasis was on moving the data to a more responsive storage management system, not on date formats.
It is clear that business pressures and horizons drive awareness and allocation of budgets. This "truth"
made it virtually impossible for applications development organizations to focus on the year 2000. While the legislature or other governing boards -- along with program areas and/or business units -- were stressing requirements that had to be met within the next six to 12 months for survival of the agency/department, the year 2000 was beyond that horizon and therefore not a concern. Increasingly, however, the year 2000 will fall within critical time horizons as applications begin to fail more frequently during the next few years.
SOLUTIONS WILL BE COSTLY AND TIME CONSUMING
The stakes are high, and solutions will be costly -- both in time and dollars. Yet the consequences of not responding could be far more damaging. Worse yet, the vast majority of agencies and departments are not geared up to solve the problem.
So what is the solution? Let's look at the experiences of one organization trying to prepare for the year 2000. The organization is a multi-national private service company, with annual revenues of $15 billion. Though it may not seem like this organization correlates to government, it does have many similarities: multiple offices spread across geography, multiple lines of business (a.k.a. different departments), and it delivers a service, not a product. I will reference it as Company X.
Company X recently completed its analysis of resources required to solve the year 2000 issue. It determined that over the next four years it would spend nearly $400 million, with 75 percent of this going to labor! A few footnotes to this staggering figure are important:
This investment is two and a half times more than Company X spends annually on new IT functionality, yet no new functionality will be generated by this project.
No interim resources will be available during the project period. Given that this project will be huge in scope, it will require all of IT's best people. Once again, big dollars but no new functionality.
The project will replace or reengineer all applications.
Half the investment will go toward application work-arounds and bridges that will be thrown away later.
Roughly one-third of the money will go toward application packages that will be used as is (no time for customization).
Client's analysis indicates no vendor's product or service could meet their needs, i.e. "no salvation through technology."
Company X will cut-over to new code one year before deadline (or 12/31/99) to allow for trouble-shooting. This means they have only 36 months to solve the problem!
Company X realized the life-threatening nature of this issue (life-threatening to the corporation, that is), and convinced executive management to invest hundreds of millions of dollars on a project that will offer no new functionality. Government IT executives need to gain the same degree of management support within their jurisdictions to move forward with a solution. This challenge will prove particularly onerous in an environment of constant cost-cutting. Yet the costs to government may indeed be greater than the private sector given potential litigation costs the private sector often does not have to contend with.
The bottom line is, although good business and technical decisions were made in the past based on the state of business and technology at the time, steps must be taken to ensure that application and data assets are secure. To minimize exposure to the year 2000 crisis, IT organizations must begin immediately to analyze their application portfolios, assess the extent of the problem and begin budgeting, planning for and implementing the potentially extensive corrective measures that will be required.
Ian D. Temple is Program Director of GartnerGroup's IT Executive Program for Government.
*
