Countdown to the Millennium

The end of a century predictably spawns a cottage industry of naysayers, fearmongers and doomsday proponents. No one, however, could have prophesied that the first to promote gloom and crisis toward the end of the second millennium would be the logical, scientific types involved in the computer industry. The Year 2000 Challenge -- also known as the Doomsday Project or the Millennium Bug -- is the result of the very efficient, but perhaps short-sighted, memory-saving policies of programmin

The end of a century predictably spawns a cottage industry of naysayers, fearmongers and doomsday proponents. No one, however, could have prophesied that the first to promote gloom and crisis toward the end of the second millennium would be the logical, scientific types involved in the computer industry.

The Year 2000 Challenge -- also known as the Doomsday Project or the Millennium Bug -- is the result of the very efficient, but perhaps short-sighted, memory-saving policies of programming personnel and consultants over the last several decades, which called for using two rather than the more accurate four digits to describe the year in software date fields. Thus, at the turn of the century, legacy computer systems will display the new year as "00" but interpret it as 1900 not 2000.


The situation has caused panic among some of those aware of it, and while some might claim that the tone of conversation surrounding the issue has a religiouslike zealotry to it, everyone agrees that the computer industry has a sizable problem on its hands. The dilemma affects any computer calculation that involves a date -- including Social Security checks, payroll functions, mortgage calculations, the stock market and taxes -- and if left unfixed it will cause most systems to post wildly inaccurate computations or, worse, stop operating altogether.

What's more, all organizations with legacy systems must address the problem by the same deadline: midnight, Jan. 1, 2000. But with just three years left, many companies across all industries, as well as some government agencies, are compounding the situation by procrastinating. "No organization really wants to spend money on something that will only keep it from falling out of its current spot -- not help improve its productivity or competitive position," notes one industry observer.

And a lot of money must be spent. The average company, which has at least 10 million lines of code to convert, will pay anywhere from 50 cents to $1.60 per line, depending on which consulting firm you talk to. Ultimately, the federal government will spend $30 billion and industry at least $600 billion updating or replacing date fields, according to estimates by the Gartner Group, a research firm in Stamford, Conn.

"There's a lot of discussion about whether that number is realistic," says Barry Ingram, chief technology officer for the Government Services Group at Electronic Data Systems Corp. in Herndon, Va. "In my mind, though, it really doesn't matter, because even if the numbers are half wrong, it's still a big number and it's a lot of programs. It [will] take a lot of resources, there isn't any option to not getting it done, and there's no silver bullet out there that can easily fix the problem."

However, the problem is considered more of a program management issue than a technical one. It is simply a matter of tackling the problem -- the sooner, the better. For there is no breathing space on this project, industry experts stress. Organizations cannot change their requirements, since the work must be done. They can't take more time, since the deadline is final. And while they can apply additional resources to the problem, that variable will change as more integrators and programmers are stretched thin by demand.

"Those that wait [will] be in trouble," predicts Mark Sokol, vice president of advanced technology at Computer Associates International Inc., Islandia, N.Y. "As we get closer to the year 2000, everybody in the world is going to be after the same fixed number of people. It's sort of the full employment act for COBOL programmers. At this point, I would think that a significant percentage of these systems will not be completed in time."

Some industry watchers, however, believe that such overwhelming demand for products and services might spawn "roofing, siding and sheeting" year 2000 companies that promise results they cannot possibly deliver. To protect organizations against such practices, the Information Technology Association of America recently unveiled a certification program that will assure clients that the products and services offered support the transition to the 21st century.

"Users have definitely been concerned about what vendors are telling them about their products and services is accurate," explains Harris N. Miller, president of ITAA. "What they really wanted was a non-biased assessment of the different offerings as to whether they were in fact year 2000-compliant."

Performed by the Software Productivity Consortium, ITAA's technical arm, certification is offered in every aspect of year 2000 work, including assessment, conversion and testing. Vendors must complete a detailed questionnaire and provide supporting documentation. Certified companies receive the ITAA symbol and are listed in a Web-based database of qualified vendors.

"The likelihood is that this certification will become basically the standard of doing business in the year 2000 marketplace," Miller says.

Still, many organizations have already taken the plunge. According to a survey conducted this summer by Olsten Corp., a Melville, N.Y., staffing services firm, 62 percent of companies have begun looking at the problem. Within the federal government, the Securities and Exchange Commission has already completed converting its Edgar electronic filing system, which offers publicly traded companies' financial information.

The Social Security Administration has been addressing the problem since 1989, and the Internal Revenue Service has completed an assessment. What's more, two recently awarded, indefinite-delivery, indefinite-quantity contracts -- Defense Enterprise Integration Services (DEIS), worth $3 billion, and the National Institute of Health's Chief Information Officer Solutions and Partners (CIOSP), worth $1 billion -- include language that specifically allows for agencies to contract for year 2000 assessments and conversions.

For systems integrators, the grim situation translates into a happy one for their bottom lines. Already, a majority in the Washington area are gearing up for the coming blitz by developing assessment and conversion tools and processes, hiring additional personnel, and forming alliances with companies that have complementary skills and resources. And many integrators are pulling resources together into individual business units, such as McLean, Va.-based BDM International Inc., which will soon unveil Year 2000 Plus, and IBM's Information Systems Solution Corp., Armonk, N.Y., which now offers Transformation 2000.

"The good news is that the problem is well within the bounds of conventional engineering," says Pete Farkas, director of systems engineering and operations at BDM. "It isn't rocket science. It's just very, very large in terms of volume. But we have good tools, and we think that if you couple that with a good, solid methodology and testing capability, the problem can be fixed."

Still for organizations, fixing the core problem will be a hassle, because it's not only expensive but time-consuming. Intensive analysis of databases and operating environments will be necessary, as well as a complete understanding of how each system interfaces with others. No one-size-fits-all solution is available, since each legacy system is different, and more than 300 programming languages, most obsolete and many obscure, have been used over the years. Moreover, while documentation has been maintained with some systems, others have not. In fact, some systems don't even have the original source code available, so reverse engineering or even re-engineering will be necessary.

"Some of the systems will be nice, clean straightforward conversions where somebody has had a set of standards that has been followed consistently," Ingram says. "In other ones where there is no data dictionary or no set of standards used, it will be the devil to change."

As a result, strategies to make systems year 2000-compliant are a mixed bag of concoctions. Unique tools for the job are already on the market. Viasoft Inc., a Phoenix-based firm, recently released an assessment tool that can scan COBOL, PL/1 and Assembly programming languages for date references and predict the cost of updating systems. Object-oriented programming techniques and rapid application development tools will likely be used to help organizations rewrite code from scratch. And there are hundreds of other assessment and conversion tools to choose from.

For most organizations, the ultimate solution will involve a combination of automated tools and manual efforts, Ingram says, and a combination of steps that include assessing and converting old code, looking for and eliminating obsolete processes and simply rewriting or replacing older systems. Those organizations that have started early will also use the opportunity to take a hard look at their systems and clean them up.

The final step in the process will involve testing the updated systems, a process that optimally should take place over the course of 1999. "The key is finding out ahead of time whether it works, which will save everybody a lot of headaches," says Farkas. "And you really need a decent amount of time to test your month-end systems and your quarter-end systems on your financial systems. You don't want to have to wait until Jan. 1, 2000, to try it out."

ITAA's Miller believes market saturation is just around the corner. "No good vendor will promise results they can't deliver. They will simply begin turning down work, and I think you could see that start to happen in the next year. There's definitely going to be a tight squeeze in terms of resources." n


NEXT STORY: IRS Imaging: Success in the Making