By Alan S. Kay
Most business executives still don't understand the opportunity presented by the Year 2000 crisis. If they don't figure it out soon, it may be too late for them to do anything but apply Band-Aids.
As the clock ticks toward midnight and the brilliant ball descends toward
Times Square and the numerals 2000, there will be celebration of
the turning of the millennium. But you'll be able to pick out some of the
IS professionals in the crowd. They'll be the ones who, instead of partying,
are holding their breath. They will bear a weight as heavy as that ball:
systems that will come crashing down around them if they haven't successfully
eliminated every one of the millions of lines of code that cannot accommodate
a four-digit change in the year.
There is virtual unanimity on the threat posed to information systems by the advent of the year 2000; commentators differ only in how pointedly they describe it. John Rade, vice president of American Management Systems (AMS), a technology consultant and systems integrator in King of Prussia, PA, describes the Year 2000 problem in understatement as "a pretty big deal." Dick Kearney, partner in charge of the Global Year 2000 practice of consultant KPMG Peat Marwick LLP in Boston, evokes a stronger sense of the concern by likening the first moment of 2000 to midnight in the Cinderella story. Software systems, he warns, could turn into rags. Gartner Group describes the Year 2000 situation as "the most devastating virus ever to infect our business and IT systems."
It's a crisis that could have been avoided. There is nothing inherent in the structure of binary code that requires dates to be recorded using only two digits for the year field. But as the result of coding decisions based largely on expediency, two-digit dates now exist on millions of files and coded into millions of applications, many of them written in Cobol, PL/1 or other "big iron" languages running on legacy systems. William Ulrich, president of the Tactical Strategy Group in Soquel, CA, and an authority on Year 2000 issues, describes this crisis as "a symptom of poor management and poor planning."
For each of these systems, there is a moment, a tick of the second hand, when it will come to a screeching halt--when the code will return its equivalent of a negative time difference. Nuclear missiles may not be launched then, but an ATM network will crash. Or next month's mortgage bills will look very strange.
"I'm not a doomsayer," says Ulrich. "There are people you can talk to who will go on about the world coming to an end: elevators will stop, cars will stop. My biggest concern is with the worldwide financial problems that could ensue. It doesn't take a lot of major companies or agencies going haywire to make things go haywire--welfare checks, the tax system. The IRS, for example, has 60 million lines of code, half to two-thirds of it assembler code that's next to impossible to decipher."
You may not run the IRS's IT operations, but your code is no less critical to what you do. Your job is to fix it before it meets the millennium. The good news is that you may be able to present the situation as an opportunity to update your systems and migrate to an open environment and contemporary tools that will add competitive advantage to the business. The bad news is that you may have run out of time.
"If we don't get started now, and people wait until there's a panic in '97, you're going to see a crash in '00," warns Kevin Schick, research director for Year 2000 strategies at Gartner Group in Stamford, CT. "It is disturbing to see how passive business management is to these problems."
Schick estimates that at least 30 percent of the existing enterprise mission-critical systems will not be compliant: three of every ten systems. An average-size company with roughly 10,000 to 12,000 programs in its portfolio will spend $15 million to $20 million to solve the Year 2000 problem, he says. In short, this is the biggest task-management problem IS departments will ever face, according to HCL James Martin, a systems redevelopment solutions provider in Fairfax, VA. (For a sample of how some of our readers are handling this situation, see "Member Views.")
Kearney of KPMG puts Year 2000 spending in perspective. "To renovate that legacy system to fix the date, you're spending more than $1 per line of code, in some cases a lot more," he says. "And essentially, you're surviving--you're not adding any functionality, not conferring any new strategic advantage.
"So if you have had plans to migrate onto a different technology where you can put a new package in or write some cool software to provide even more functionality that really adds value to the enterprise, the delta cost of renovation versus replacement will probably lean you toward the benefit of migrating earlier than you had planned to. People say, 'I'm not going to spend this amount of money just to survive.'"
Remember also that the year 2000 is not the only time bomb ticking in legacy code. Assuming you get past Jan. 1, there's Feb. 29, 2000, for example. Centennial years are leap years every 400 years. There was a Feb. 29, 1600, and there will be one three years from now. Then there's the recoding that may be required if and when the European Union succeeds in migrating to the Euro as a common currency--or, even more problematic, as a dual currency coexisting with the national currencies.
Some beneficiaries of this crisis are obvious: the consultants, the automated tool and off-the-shelf business package vendors, and the programmers, particularly those who are specialists in legacy systems. The larger question, though, is whether you and your company can be beneficiaries as well.
To begin thinking along these lines, Rade of AMS suggests looking at a few indicators: the maintenance backlog on your system, what it will cost you to renew it by making it Year 2000-compliant, and whether your in-house staffers know the system intimately. "When you see a high cost of renewal, a big maintenance backlog reflecting a lack of user satisfaction, and a shortage of qualified staff, ask yourself whether it is worthwhile making an investment in that system," he says. "Perhaps you need to look at other options."
The most appealing option, of course, would be to seize the opportunity to migrate away from legacy code. After all, why spend millions of dollars and invest many person-months to redo many of the millions of lines of code in an application merely to weather the Year 2000 storm? Such a system probably generates no discernible added value, no increased user satisfaction, no competitive advantage and no new market opportunities.
There are stories of planning efforts that have already been going on for years, but Year 2000 compliance work need not have started before advent of the PC. For example, at health care provider Blue Cross and Blue Shield of Connecticut in North Haven, CT, Donna LaShomb, a systems engineer, and her colleagues began their inventory of systems' date compliance only in November 1995. By last June she had identified about nine million lines of code in a handful of systems that use dates projected three years into the future and so will run into trouble shortly.
At Sungard Security Systems, a financial services company in Hopkins, MN, Clark Kender, group manager of quality improvements, started work in February 1996, when Sungard began to have problems getting maturity and settlement dates to work properly for its five-year bonds. If you're just now thinking about addressing the Year 2000 problem, Kender warns, "You're woefully late."
Your options are constrained by two familiar factors, says Ulrich of Tactical Strategy Group: money and time. But only one of these really matters. "The real thing people need to worry about is time. Very soon, the dollars and cents won't matter anymore," he says.
In fact, it may be too late to consider a strategic migration of mission-critical business systems. According to Terry Zagar, chief scientist at BDM International, a systems integrator in McLean, VA, a substantial migration project to replace a legacy application with a contemporary system usually requires two years, plus another six to 12 months for the organizational aspects of the transition. "So for most," he says, "it's too late for a best-of-breed solution."
Rade argues that the opportunity to consider responses from a business investment perspective will remain available for the first half of this year. But at some point, he says, the only option will be to let systems fail. In that case, instead of worrying about fixing the system, you try to decide how to replace its functionality most quickly.
In considering options for responding to Year 2000 problems, the key metric to evaluate, says Gartner's Schick, is the time horizon to failure (THF) of any given business system--the point at which that system encounters a mixed date scenario and therefore will fail. The THF defines the window of risk. If, for example, one of your key financial systems calculates returns on three-year bonds, it does forward time projections over three years and thus becomes subject to failure in January 1997.
Other systems may look backward in time, rather than forward, and so won't run into dating problems until after the turn of the year 2000. Schick argues that a business must understand the exposure of each of its systems, as represented by its THF, in order to make reasonable management decisions about how to respond. "Without that knowledge, the issue is merely technology for technology's sake--a dangerous path to travel in the best of times," he says.
One of the reasons such evaluations are necessary is that costs are climbing rapidly for at least some of the Year 2000 solutions. While there are no simple metrics for comparison of the costs of rewriting legacy code versus migrating it to a new platform, Zagar of BDM offers a generic computation. Say you have 10 million lines of legacy code. Having programmers renovate it will range from 70 cents to $8 per line. Assuming a good code book and good regression test sets for the code, figure $1.25 to $1.50 per line, or a total of $12 million to $15 million.
Replacing the same 10 million lines of code by using existing tools to migrate it will likely produce a 10-to-1 reduction in the number of lines of code, resulting in an application consisting of one million or so lines, to which can be added commercial software--such as databases, statistical analysis packages and others--as needed. In these kinds of situations, the cost ranges from $3 to $5 a line of code--a higher per-line cost but for fewer total lines of code, some $3 million to $5 million in all.
Both these scenarios assume that you can find people to do the work. That is a tricky assumption. The pressure to rewrite Cobol and other legacy code is creating a market situation analogous to the one IS has had to deal with in recent years in the programmer marketplace for hot and emerging technologies. "People who waited too long are having to pay top dollar, because programmers are in great demand," says Rick Langston, a senior systems developer at SAS Institute, a software tools vendor in Cary, NC.
"The legacy programmers we tossed aside six or seven yeas ago are now a boom market," says Mike DeVito, president of HCL James Martin. The closer we get to 2000, he notes, the more enterprises will be forced to table scheduled work that is not related to Year 2000, because of the demand for legacy programming resources. According to one report, rates being paid to legacy programmers last October were up 45 percent over rates of the previous spring.
One other cost issue favors migration rather than renovation of legacy code. That's a ruling, made late in 1995, by the Emerging Issues Task Force of the Financial Accounting Standards Board, the body that establishes financial accounting and reporting standards for U.S. businesses. The ruling requires that the costs associated with Year 2000 internal-use software modifications be expensed as they are incurred, rather than being capitalized. As Stephanie Moore, an analyst with the Giga Information Group in Westport, CT, sees the ruling, it is an incentive for a move to a new system, since corporate managers may choose to replace an aging or imminently failing system with a package the company can pay for over several years, rather than impacting short-term earnings with the cost of a Year 2000 fix.
Despite the convenient opportunity proffered by the Year 2000 situation, analysts, consultants, vendors and IS executives all caution against trying to jam migrations to new code and new platforms into this relatively small box of time. The issues mitigating against it will come as no surprise: the amount of time a quality migration project requires and the risk of failure in a mission-critical system migration with a looming THF deadline. That failure could be gross--non-delivery or delivery late and over budget--or it could be more subtle, such as the new system failing to incorporate all of the enterprise's key business rules. Either kind of failure would be catastrophic.
Schick is particularly concerned about applications with forward-looking Year 2000 problems. "Both Year 2000 and open systems migration are risky. You may miss the delivery date, exceed budget, compromise functionality, perhaps run into political problems," he says. "When you build those into the risk model, these two combined become very risky. Most organizations don't have the skills or the project management ability. And frankly, many don't have the executive and political support to pull them both off."
He's more positive about systems that will encounter Year 2000 problems only retrospectively. "Things that look back in time are much more attractive candidates for going to an open system migration strategy. I'll have two to three to five years, depending on how much time I want to live in peril, to achieve a migration. These can become priority systems to move, test and prove that the new system works. Then I can continue the migration. I'm able to spread it over a little more time, so I have smaller chunks to migrate, which reduces risk."
"If a client started at this point," says Zagar, "I'd be hard-pressed to recommend wholesale replacement because of the time it takes to replace, integrate and train users. You don't have that much time left." And for federal agency clients, Zagar adds, going to a software migration solution isn't an option because of the complexity of the contracting issues.
"We're working our tails off," reports Kender of Sungard. They've been working to evaluate compliance not only of proprietary code but other hardware and software; he found that only 15 to 20 percent of the OEM software in-house was Year 2000-compliant.
Kender considered migration but concluded that it would have to be to marketplace offerings that could replace the existing software. He couldn't find any. "Migrate if you can to another software, convert software or bridge it, or drop the product," he says. "You don't have time to rewrite from scratch. No one takes Cobol and puts it perfectly into 4GL, and those projects take years."
Opinions vary about the merits of off-the-shelf packages. If the application is small enough and you can put the package in place in time (in six months, say), Kearney says, "Great--go for it."
Zagar is more wary. "There are some radical technologies that can be used to put a system in place maybe in two years, but you lock yourself into a proprietary solution."
Some packages are generic and modifiable. For example, Pamela McFadden, information systems manager at Kemper Insurance Cos. in Long Grove, IL, reports success with a ratings engine package. But again, the cost of finding one is time and research--resources that may be in short supply if you're just starting Year 2000 efforts now.
One interesting possibility, if time and resources allow, is to buy a package that runs in an open systems environment and reverse-engineer it to learn how to customize it to work with the legacy-structured data. "Seventy percent of companies don't develop code any more; they buy," says John McHugh, director of commercial markets for Cayenne Software, the Burlington, MA, merger of software tools developers Bachmann Information Systems and Cadre. "But any package, however good, is a black box; sometimes it has to be merged and customized. The more visibility into that package you can get to understand how it functions, the more clarity you can get about its data structure and modeling, the better able you'll be to use it."
Of course, any package you buy should be Year 2000-compliant; not all are. But even for a shrink-wrapped package, time is growing short. In fact, Kearney suggests that while a company might ordinarily buy a package and customize a lot of it, in the face of time pressures it may have to put the commercial application online as it stands and change the business a bit to match the software's functionality.
Says Schick, "Look at, say, an average 18-month project to implement and replace software to achieve Year 2000 compliance and bring in a packaged solution. To get that budgeted, approved and procured, in a very optimistic case starting in January 1997, you'll finish at mid-year 1998. You've then left yourself about 18 months for technical cleanup. That's OK as long as in the 18 months to implement I do not encounter the time horizon of failure, and after getting the implementation in, I don't have to deal with THF while I'm trying to clean things up technically."
The bottom line is that you're close to out of time to implement a packaged solution to obtain Year 2000 compliance. "A lot of companies have decided for business reasons to go to a particular package. But they also must fix the existing system, then bring the package in to run in parallel," Schick says. "That way they can ensure compliance, then do a cut-over. It adds to the time and costs, but this approach minimizes risk."
It seems, as is so often the case, that it is wisest here to use business priorities to govern technology decisions. Colossal shortsightedness led to the Year 2000 mess; more myopia in responding will lead to extinction. Most corporations, says AMS's Rade, will use a blended strategy that incorporates all three elements of triage. They will purchase packages to replace some problematic applications, rewrite or rehost others, and simply renew the code for the rest.
That's not to say that migration to open systems has faded as the future of enterprise IT. Despite the resurgence of big iron, integrators and consultants report that most new contracts are for client/server architectures. But enterprise needs will not fit the time crunch of the Year 2000 crisis.
What the Year 2000 crisis does provide is a goad. It's an enforced opportunity to make sound business decisions: to evaluate the status of strategic business systems, make plans to upgrade those systems on a schedule dictated by business rather than technology issues, and wrap those plans in a crisis in order to sell them more effectively to senior management. The language should be framed in terms of investment rather than expense. "When we get through this issue, you'll see legacy systems that are better documented and more efficient than they've ever been," says Zagar. "You also will see new application software implemented that should have gone in long ago."
There's no right or wrong answer to the question of whether to replace an offending system by building something new or migrating to another platform. "A company should be looking to identify which applications will break first and which are critical to support the company every day," says DeVito of HCL James Martin. "Then it should put a plan in place to address that, with all the options open. This is a good time to set a strategic plan, but the window is slamming shut quickly."
It seems certain that the window will close on a number of organizations, and no one knows how many will recover from it. When watching the clock is waiting for disaster, it's time to jump through that window.
Alan S. Kay covers business and technology from Washington, DC, and San Francisco. He can be reached at ask@well.com.