In four short years, we will all experience the unique transition of one millennium to another. Ona personal level, no real impact will be felt for most of us. Life will go on as usual. Unless, of course, you earn a living as an information technology (IT) professional.

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.


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

Age in 2000 is: 00 - 54 = -54

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.


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