Y2K - WHEN IS ENOUGH, ENOUGH?

By
Ed Parker

Y2K ? THE FANFARE OF THE EARLY DAYS

Y2K burst on the public consciousness on a wave of public sector concern, swiftly mirrored by the management of large corporations. In short order the Y2K problem engulfed all sectors and all levels, even extending into home computers.

The public reacted to the Y2K problem with concern. Few comics developed Y2K jokes ? the public did not consider Y2K a laughing matter. Firms with product lines dedicated to Y2K solutions faced a lively market, often with cost being no object. The prospect of a public or private enterprise balancing risk against cost was not to be found. The publicity had been too pervasive. Y2K had achieved a life of its own that was independent of its technical merit.

Plans were laid, often with nostrums leading the way. Was management aware and exhibiting a proper degree of concern? Had a formalized approach been effected? Was the approach taken sufficient to the magnitude of the problem and the potential consequences?

Spurred by initial analyses, the Y2K problem quickly spread beyond facets directly controlled by management such as computer systems into loosely controlled or uncontrolled areas such as supply chains, critical automated interfaces, and imbedded technology such as security systems and elevators. Worries were expressed aloud that reapers would not be functional, potentially leading to famine, despite the fact that there would be nothing to reap in the northern hemisphere for several months after the turn of the millennium.

Real fears became stimulated. Would the banking system collapse, leading to chaos? Would records be destroyed non-recoverably? Would power be available? Mercedes Benz recalled later model cars to adapt internal computer systems for Y2K compliance. A market developed that sold bottled water, canned and dehydrated food, and other necessaries of life.

A group of experts entered into this arena. They were there not to effect solutions. Rather, they were there to judge whether the solutions were going to be effective. Their role was oversight, in effect filling a management role often gladly ceded to them. Essential maintenance and developmental work was postponed. The gains to be realized from such work was insignificant compared to the incommensurable benefit of being Y2K compliant.

Management was told the formula that had to be followed for Y2K compliance. Technicians were told by management that Y2K was the first priority, and that if compliance wasn?t both tested and documented it wasn?t compliance. This placed a large cart before several technical horses.

WHAT IS THE Y2K PROBLEM?

The Y2K problem arises from the lack of foresight in preparing devices for a millennium change. In some cases this should not have been expected. For instance, 2-digit century representations saved computer space when such space was expensive. In addition, who expected in a young industry that a language such as COBOL would not be superseded in the next 35 years? In other industries reasonable prudence might have avoided the problems of testing through foresight, but avoiding non-competitive expense will generally trump prudence based on important but not yet fashionable concerns.

While a simplification, the Y2K problem does not exist for more modern devices and tools that have been designed with 4-digit century capacity. In general while date compliance is testable in such devices, only the manufacturer can take corrective actions. An example is ORACLE, where compliance is assured to the extent controllable by management once the version being used is certified by the ORACLE Corporation to be Y2K compliant and code has been reviewed to ensure that all date logic is in date format.

Subsequent patches to the certified version or a succeeding version must be installed, but date testing can only discover that ORACLE?s certification itself is not valid. Corrective action must be by ORACLE Corporation; management and corporate technicians do not have access to the codes causing any non-compliance. The language itself forces Y2K compliance once date representations or calculations that are not in the ORACLE format are replaced.

In older computer languages programmers were allowed more freedom. Dates could be handled in routine fashion as dictated by institutional standards or in idiosyncratic fashion as determined by the programmer at the time. An additional layer of complexity arises in not being able to access the original programmer in many instances. Further complication is possible by bringing "dead" code back to life inadvertently. In older computer languages and devices the problem is to find the date representations and logic first, then to remediate code and test for compliance.

In effect, older languages must test the entire system in order to locate dates for Y2K compliance testing. Newer, 4-digit century languages need only locate programmer "abuses" such as using only 2-digit representations on input (will default either to ?19? or ?20? depending on the language ? all internal representations are 4-digit century).

While this distinction seems small the consequences are not. Testing an entire, probably poorly documented older system requires expertise in both the language and the application. Testing newer languages generally requires language-based expertise only.

Once the applications have been made Y2K compliant the difference between older and newer systems becomes even more pronounced. It is easier to verify that all dates are in date format and to rely on the manufacturer?s certification that the version is Y2K compliant if all dates are in date format than to continually test all changes across all key dates for all possible areas affected a given change. The latter strains most configuration management control methods.

EVOLUTION

The aspect of allowing change after testing for Y2K compatibility has opened up a continuing venue for Y2K experts. The strategy is 2-pronged, and relies on being able to pursue the issue until the Y2K issue is declared dead and buried, some indefinite time into the year 2000.

Buttressed by any errors found and by the lack of a planning assumption of Y2K level complexity when most configuration management methods were installed, Y2K experts are focusing on continuing, non-date related issues while also holding onto the power base of Y2K compatibility through contingency plan elaboration, etc. Management will not dare to remove the technical (and possibly legal) cover offered by the experts, even when the recommended Y2K activities can not be demonstrated to confer measurable corporate benefits.

Yielding management prerogatives for a prospective limited duration to outside experts has been led to a series of indefinite assertions, such as:

There isn?t enough time. The past and what should have been done must be ignored against the present exigencies. Don?t retro-fill, move ahead, but in a planned and approved manner.

There aren?t enough resources. Priority decisions must be made, and little used (annual versus quarterly for instance) or relatively low impact areas are to be addressed only if time is available. What is critical? What is important? What remains?

No amount of testing will be enough. Priority decisions about the most effective testing must be made.

If it isn?t documented it doesn?t exist. Retro-fill in the event of legal action, etc. Go the extra mile with suppliers, and ask for certifications that your corporation would not be willing to give to its customers.

How is Y2K compliance maintained, and what level of documentation is required to prove it? Companion issues are manufacturer?s certificate limitations (e.g., Microsoft will not guarantee compatibility beyond mid-2001 without a recently available, but somewhat costly, software upgrade).

By resource dedication and management attention many of these arguments have been laid to rest. In some cases, management has asked for certification of Y2K compliance by their experts. Few have received such assurance. Most have found out how lucky they were to get to where they are without adequate planning, control, and other management requisites. Above all, the public isn?t laughing yet. Ignoring expert advice that is not strongly based on demonstrable technical merit or measurable cost benefit is not yet a fashionable strategy.

However, accepting such advice also may not be a fashionable strategy. The result is to procrastinate, at least until the necessity for such expertise, now almost entirely non-technically based, is clearly no longer required. But this can range from 4 months to one year, depending on the perceived danger to the enterprise.

During this time the experts and their organizations will strive to survive and evolve. This is both human and smart business. Expansion urges to cement a future position will be met with increasing reluctance internally. At issue will be the date of January 1, 2000. One side watches time speed by, the other watches time crawl. As pressure mounts the question for management becomes when is enough, enough?

NEXT STEPS

If you still have a Y2K compliance problem, the above applies. If you had a Y2K compliance problem, the following also applies.

There is an inherent danger in being serious about a problem that everyone recognizes as a joke. Defending the solution when the problem has not yet manifested itself is quixotic. Espousing an "I told you so" attitude is never popular, usually in direct proportion to the truth of the assertion and the impact of the consequences.

The Y2K compliance situation by this definition is dangerous to management. The expenditure is large, and if successful tends to trivialize the problem itself. Given the universality of the response prudence will not be assumed, only following the trend.

Two potentials magnify this situation. First, the wide spread appreciation of the problem as real will tend to have a boomerang effect if it fizzles in the public imagination. Second, any humor inherent in such a situation will find management the butt of the joke.

When management moves on to business as usual will be a key in demonstrating prudence. However, there is no experience-based comparable situation on which to pattern such a determination. In this absence, reverting to experienced-based methods is preferable to inactivity.

Ask yourself some questions, and listen to your own answers:

Does the remaining Y2K problem measure up to the proposed costs when measured by cost benefits?

Separated from the hype, what is controllable?

What proposed activity covers remote contingencies?

Should full-time expertise be retained if the problem is viewed now as part time?

Should you separate your corporation from its competitors by proactive concentration on business issues?

Your corporation is gaining no competitive advantage from doing what every other competitor is doing. The risk in moving on should be measured at this point in time. For instance, how much do the experts expect to reduce risk by proposed future activity? Do you perceive that a measure of risk that belittles past efforts, or is imprecise, is to be expected after 1 ? 2 years focusing on the same issue? Are you so far behind the industry compliance standard that the risk of diverting resources to business as usual is outweighed by the possible consequences of not completing Y2K activities?

Concentrate on what the experts are advising. Are they expanding their comments beyond the Y2K, solely date-related problem? Does your technical staff have confidence that the Y2K problem is under control, including plans for reaction to the unexpected as the millennium arrives? What are the costs of adopting a future course that is dictated to some extent by experts without making them responsible for results? What is the consequence on staff of inserting an outside layer of control?

Deviation from business as usual has its own cost. People resist change. Perpetuation of an atmosphere of change may be beneficial, even if difficult to sustain. There is a tendency to become increasingly resistant, particularly if there is no perceived benefit to offset the irritant of change. As a general rule of thumb, if benefit is not demonstrated to your satisfaction it won?t be to your staff?s satisfaction either.

THE DIFFICULT ACT OF BEING WEANED

Safety, particularly of the enterprise in circumstances of high potential liability, is an alluring option. This is particularly so when an end, such as January 2000, is in sight. It is upon this caution that the experts are relying.

However, ask yourself several questions:

Are the bills for these services going down to maintenance levels as promised, or up with low return work?

Is your staff being freed for routine and developmental work, or involved in low return Y2K work?

Are you developing items such as contingency plans for scenarios over which you have no control? Examples are a collapse of the banking system, sustained loss of power, etc.

Using logic, what can be done if the banking system is dislocated? How will an acceptable amount of cash be acquired and protected? How can huge amounts of cash be used to pay trade bills and salary, or to remit withholding taxes? Buy stocks in armored car services if this option is chosen.

In a similar manner, if there is wide spread power loss, won?t your employees be seeking the safety of their families before thinking of work related problems? If the security system fails and the doors won?t open, won?t you break down a door or two and post guards?

If there are legacy system problems remaining this should be your first objective. If your focus has now strayed to the unknowable and uncontrollable it is time to wean yourself and your enterprise.

WHAT?S NEXT?

Life without the constant intrusion of outsiders can be a little scary at first. Staff will be relying on their own resources entirely, and this mode may not have occurred for a significant period of time. However, it is the most familiar mode, and will be swiftly adapted ? often with a sigh of relief.

When scheduling your staff for the millennium rollover you should keep in mind that they can respond only as much as the circumstances allow. Do you ordinarily have a full staff in New Years day? If not, a cast of thousands can?t help. Further, if basic services such as traffic lights fail having them on the road will contribute to the problem without contributing to the solution.

Going deeper into the New Year, when do your experts expect to say "all" danger is past? If this can not be defined in concrete terms at this time, the answer is a few months probably won?t provide dazzling new insights.

Not only your firm, but virtually the entire nation has been preoccupied with the Y2K problem. Hundreds of billions have been spent ? and will have to be justified in a retrospect that has the advantage of hindsight.

Life has risks. It may be time to realize that the greater risk is going along with experts that have already given your enterprise everything that they have to offer.