The Family of Year 2000 Problems

	Sign In Sign-Up

-- an Executive Backgrounder

A Ross Stewart, Year2000 Ltd, Wilson White Group, Auckland, New Zealand

version 3.5 - April 1997

------------------------------------------------------------------------

The following is based extensively on material from other people and this aggregation of information, being of necessity quite compact, does not necessarily do justice to some of the ideas expounded in the original texts. Full details of those texts are in the acknowledgements at the end of this document.

------------------------------------------------------------------------

Introduction - General Summary

Stage 1 - Awareness, Understanding and Decision

Stage 2 - Inventory, Assessment and Triage

Stage 3 - Research & Planning

Stage 4 - Conversion/Replacement & Testing

Stage 5 - Implementation into Production

Stage 6 - Monitoring

Grateful Acknowledgements | For More Information

------------------------------------------------------------------------

Introduction

Most New Zealand companies are blissfully unaware of the threat to their very survival from the family of Year 2000 computer problems. It is possible, but highly unlikely in our experiences thus far with our clients, that there are no problems for them to face but this cannot be known until at least two of the six stages detailed below are carried out.

The Year 2000 problems are NOT just technical computer problems - they are business problems with major profit-impacting considerations which MUST be addressed by the Directors and Chief Executives of all organisations.

If the problems are not addressed now, then it seems to us that those Directors and Chief Executives are putting their businesses at risk, with possible exposure to litigation (both personally and from a corporate point of view) from a variety of sources.

The Year 2000 family of problems are more complex and far-reaching than a causal observation would suggest. Changes must be made to hardware as well as a host of software elements, ranging from source code, database schema and file layouts, I/O screens, utility programs, packaged applications, reports, interfaces, operating systems, archived and historical data, and so on. Thus, the effects of the Year 2000 problems extend far beyond the commonly-mentioned legacy, mainframe based applications.

The problems are not inherently technically difficult to solve, but they are, when considered in total, a logistical nightmare, primarily through lack of human resource within a fixed time-frame.

------------------------------------------------------------------------

General Summary

There are several members in the Family of Year 2000 Problems:

1.dates may be stored with 2 digits for the year instead of all 4 digits; thus leading to ambiguity and possible misunderstanding unless the context is unmistakably known, 2.dates although stored correctly may be incorrectly processed because of poor programming

3.the year 2000 is indeed a leap year and many computer programs may not cater for this, and

4.many computers and electronics devices have internal clocks and similar clocking software which does not correctly handle the changeover to the year 2000.

There is an over-riding consideration :

1.it must be solved, as there is a finite immovable deadline.

There are several complicating factors:

1.the volume of work to be undertaken by enterprises large and small is enormous

2.the problem is not just a legacy mainframe applications problem as is commonly and mistakenly thought

3.various technical issues (such as missing or inconsistent source code, now-unused languages, etc) further complicate the fix effort

4.the diversity and lack of standards in each organisation count against a simple solution 5.the Year2000 problem is outside the scope of most outsourcing contracts

6.many commonly used packages and operating system versions have not yet been upgraded to compliant versions

7.there are not enough qualified professionals available to help every company, thus it may very well be a first-in-will-survive situation.

There are six stages in the process of resolution of the family of Year 2000 problems:

1.Awareness, Understanding and Decision

2.Inventory, Assessment and Triage

3.Research and Planning

4.Conversion/Replacement and Testing

5.Implementation into Production

6.Monitoring

------------------------------------------------------------------------

Stage 1 - Awareness, Understanding and Decision

The first stage involves learning that there are such problems, then understanding and comprehending the natures of those problems, and finally recognising that if no action is taken, significant and potentially financially catastrophic difficulties could result.

•What are the Year 2000 Problems?

The Year 2000 Problems are a group of difficulties which may arise with misperforming software and hardware at the end of this century or with respect to the manipulation of information which includes dates relating to the next century.

The classic difficulty is that many computer systems, frequently but not solely mainframe-based systems, hold dates in a 6-digit format (being one of YYMMDD, DDMMYY or MMDDYY) rather than 8-digits, with the two "missing" digits being the century indicator. Thus the date 15 February 1997 might be stored (in YYMMDD format) as 970215. [In an 8-digit format of YYYYMMDD, this would be 19970215.] In a 6-digit format of YYMMDD, the date 15 February 2000 would be held as 000215.

Dates in computer systems are often used

(a) to sort information into sequence (eg on a bank statement, etc) ,

(b) for comparisons to see which of two dates may be earlier,

(d) to determine the age of a person or object , and so on.

The list is almost endless, depending on the activity of the organisation concerned.

Thus if the date or dates upon which the calculation is performed is/are suspect, then the results must of necessity be unreliable. Even if the dates have been stored correctly, there are many examples now surfacing (for example the PICK 17 May 1996 problem) where similar problems have arising through faulty processing of valid dates.

A second problem within the family is the fact that many programmers from way back didn’t allow for (didn’t realise, didn’t know, or whatever) the fact that the year 2000 is indeed a leap year with 29 days in February. You may remember from your school days that the rules for determining a leap year are that the year must either be (a) divisible by 4 but not by 100, or (b) divisible by 400. For example 1800 and 1900 were not leap years, but 2000 is. In systems having this defect, by-day interest calculations will be incorrect, the wrong day-of-the-week will be returned from the system, and so on.

The third problem within the family relates to the fact that large numbers of PCs (including those acquired quite recently) contain internal software and hardware clocks (BIOS, RTC, etc) which will give an entirely wrong date as they click over on the 1st January 2000 (for example over 50% of the PCs in our company will click over from 1999 to 1994!). This can have distressing (to say the least) effects on such common programs as WORD and WordPerfect where business letters commonly get the date of the letter from the PC’s internal clock! There will be other, significantly more serious, problems with other software products where, in smaller organisations, these are run on such PCs.

------------------------------------------------------------------------

•What are some of the causes of the Year 2000 problem?

1. Resource Constraints

In the early days of computing, main memory and file storage (disk, tapes, drums even!) space was expensive and every bit (no pun intended!) made to count. It was standard practice (because the turn of the century was soooo far away) to use only 2-digits to represent the year within a date. As software versions were updated, enhanced and or ported, date formats were most commonly left unchanged. In fact, even today screen layouts and report layouts are still under significant space pressures.

2. Applications Have Lasted Longer Than Was Ever Expected

The designers of applications in the 1960s and 1970s just didn’t ever expect that the date-handling routines they were developing would ever last to anywhere near the turn of the century. Often older systems have stayed in production because replacement systems have failed to meet performance expectations.

3. User Pressures

User friendliness is the name of the game and users get extremely upset if they have to always key in what they consider to be unnecessary information needlessly - the "19" in a year.

4. Compatibility with Earlier Versions

In today’s integrated systems environments, updated applications tend to be slotted in to an existing suite and thus compatibility with what has always been done needs to be maintained. Thus the problems of the past continue into the future. It is simply easier (and usually cheaper) to make the new accept the old.

5. The Use of Standardised Routines

Most IT shops have significant libraries of standardised routines developed and proven over the years. These, even though now very old, continue to be incorporated into brand-new applications. Date-handling routines are almost invariably contained within these libraries and logic errors in these (for example incorrectly not treating the year 2000 as a leap year) are then replicated throughout many systems.

While the correction of these libraries may be quite simple, it does mean that, as a minimum, every program using those routines has to be checked for non-standard use and then re-compiled or similar. Not a trivial exercise.

Even in today’s world, there are still programmers who "know better" and who don’t use the standardised routines provided in the installation. Thus, even if all standardised routines are identified and fixed, all programs still need to be check for unauthorised non-standard routines.

6. Historical Data

Competitive advantage is a major goal for most organisations and this advantage is often gained from reviews and analyses of the data stored over many years. In most organisations, IT professionals shudder at the thought of re-visiting the gigabytes of old data in order to check and convert the date fields held in that data. But without that verification and correction, date-based analyses of that data will be suspect, and thus the organisation’s plans may be based on entirely false premises.

7. Procrastination and Other Priorities

IT professionals have always known of the Year 2000 problem (although in the old days, it was never called that, nor was it ever considered a priority) and it has always been assigned a low if not non-existent priority. A "we’ll look at it next week" attitude was the standard. Now the problem’s coming home to roost.

8. Restructuring, Right-sizing, Re Engineering

In the early days of computing, BPR (Business Process Re-engineering) was otherwise known as common-sense. But these days BPR almost always involves a reduction in the number of IT professionals employed by an organisation. Outsourcing can have even worse effects as an organisation can end up relying on totally external people for the maintenance and enhancement of its critically important IT processes. And the outsourcers’ staff may have no loyalty nor allegiance to the client. In a "right-sized" department, the remaining staff have no time at all to consider the Year 2000 problem.

------------------------------------------------------------------------

•What difficulties might there be if the problems are not fixed?

•Your bank may not credit your account with the correct interest

•Your credit card interest bill may be enormous

•Automatic payments from your bank account may go out on the wrong date, jeopardising your credit rating with the other party involved

•Automated warehousing systems may not select the correct goods, thinking that perfectly normal products are out-of-date and thus to be destroyed

•Computer-controlled lifts may refuse to allow access because the computer controlling the lift believes it is a weekend by mistake

•On Wednesday 5 January 2000 (the first business day in New Zealand after New Year), user departments may be unable to enter transactions such as accounting journal entries in its general ledger because a posting date is required and "00" is considered an invalid year

•A navigation system using annual variations from magnetic North may give spurious and potentially lethal readings when it uses 1900 as the current year rather than 2000

•A food manufacturer that produces a vacuum packed product with a four year shelf life calculates an expiration date of "00" for its latest product run and issues recall notices to its retailers because the date is less than the current date

•Similarly, this could happen to the "life date" on aircraft parts; with automated just in time inventory systems, improperly returned parts could shut down an airline maintenance operation for days

•Phone calls started just before the end of 1999 that carry over to 2000 could be billed as 52 million minutes long (60 minutes x 24 hours x 365 days x 99 years)

•Precedent contracts in a legal office may be printed with a 1994 date on them instead of 2000, invalidating the contract

•In payrolls, salary payments which are based on dates may be ridiculously incorrect.

------------------------------------------------------------------------

•What legal liabilities might there be if nothing is done?

Estimates of the costs of investigating and correcting the Year 2000 problems range from US$2.00 per line of code in 1997 up to US$7.00 per line of code in the year 2000. If a small company runs say 10 applications each with 20 programs each averaging say 300 lines of code, than the 1997 estimate for investigation and correction would come to 60,000 lines at US$2.00. This amounts to over NZ$150,000 for a small company alone.

Our New Zealand estimates reduce the USA-based figures to 25% but even at that level, costs (in 1997 terms) are in excess of NZ$50,000 for the smaller companies. If the problem is not addressed until 1999, not only may there no longer be anybody to do the work, but those that are available may well be charging rates as high as NZ$500 per hour.

This is a significant amount of money and, when considering a large and/or listed company whose investment in software might be 10 or 100 times greater, you’ll appreciate that this is a potential liability which must be disclosed to shareholders, investors and financiers.

Auditors are bound to ask what provisions have and are being made in this regard and may qualify their audit reports if the correct answers are not forthcoming.

If no disclosure is made in the annual accounts in 1997 and thereafter, then shareholders may well consider instituting legal action against the Directors and Officers of the company under the New Zealand 1993 Companies Act.

Stock Exchange listing requirements for a public company may also be jeopardised if no action is urgently taken in order to address the Year 2000 problems.

------------------------------------------------------------------------

•Why aren’t the problems being taken seriously?

The Year 2000 is immovable - it WILL happen, it is inevitable, regardless of how much professionals (whether in the information technology sector or in general) may otherwise wish (and hope). It is a potentially disastrous occurrence, with which those concerned in some way or other must face and "come to grips with".

Unfortunately, otherwise rational executives have to date responded to the Year 2000 group of problems in ways which are similar to those exhibited in the face of impending disasters such as terminal illness. It is thus vitally important that Chief Executives lead from the front, as if in a war effort, to have their staff accept and confront these issues, unpalatable as they may seem to be (especially when there is a cost involved with little apparent consequential return for this cost). One would have thought that the ongoing survival of the business was a fairly good return for the effort employed!

These reactions, which may be termed "early response avoidance mechanisms" tend to occur as organisational personnel prepare to accept and deal with an unpleasant reality. Their relevance to the year 2000 date problem is that no problem solving occurs until the full magnitude of the problem is accepted. What is important is that an organisation minimise the time and effort spent reaching acceptance and especially not get stuck or linger in any of the early avoidance stages.

While these reactions are understandable, they amount largely to wasted effort which does not address the problem. They are only precursors to productive problem solving. Yet, too many organisations are still lingering at various points in these avoidance stages. By understanding these avoidance reactions, organisation can potentially minimise their impact.

1. Awareness

While overseas, much space has been devoted to the year 2000 group of problems in the general press, here in New Zealand little information is available apart from the occasional; rather sensational article, usually maintaining the emphasis on the legacy mainframe area. Most IT managers have at least become aware of the year 2000 date problem. Yet, few organisations have mapped out a strategy for addressing the issue.

2. Denial

Perhaps the biggest obstacle to addressing the year 2000 date problem is denial, ie., ignoring or downplaying the importance of the issue or its potential impact. Several reasons account for this. To some IS managers, confronting the year 2000 date problem is akin to admitting failure, as few of them want to admit to their Managing Directors or Board that there is a multi-million dollar problem to be resolved now but which was known about twenty years ago. Others have the attitude - "Not my problem - I’ll have left before then." And other managers may underestimate the scope of the change required and reason that "there is plenty of time left" to address this problem. While many computer specialists are well aware of the impending crisis, many senior executives tend to underestimate the importance of it. Managers outside of the IS department may be especially prone to not recognising the importance of year 2000 date problem as so little attention has been given to this issue in the popular business press.

3. Anger

After passing the denial phase, a common response is to look for parties to blame for the "mishap." This may especially be a common response of top management when they first hear about this issue. To many observers, the year 2000 date problem appears to be more of a "tax" or "data virus" than an opportunity. That is, the cost associated with addressing this problem is something that no one wants to pay, it is not value adding, and it is a maintenance expense that is required just to stay in business. Yet, it is not productive to look for scapegoats for the year 2000 date problem since it is really not anyone's "fault." If this were the case, the problem would likely affect only a few organisations instead of being so widespread.

4. Bargaining

Once denial and the search for the guilty are overcome, another response that some organisations take to the year 2000 date problem amounts to a marginal, "band aid" approach. They think that if they just change a few lines of code and data, the problem will go away. For example, some organisations have only patched specific systems as millennium related problems have arisen, rather than being proactive in considering what problems are likely to occur with other systems. Confining the focus of the issue in such narrow terms may be a sufficient response in some settings. However, in most cases, this approach is short sighted and oversimplified. It entails a higher risk of failure, and it does not take advantage of potential opportunities that may be presented in a year 2000 conversion such as the chance to retire outmoded or unused systems, add functional enhancements, or migrate data or applications to other platforms.

5. Acceptance

Acceptance marks the end of the early response avoidance mechanisms and the beginning of productive problem solving. It is reached when an organisation reaches the full realisation that this is a business problem that will not go away, it is important, and it must be addressed now. Acceptance means assuming the attitude, "now that we're here, let's move forward." Unfortunately, the year 2000 date problem in most cases cannot be solved in a few days or even a few months. However, the key is to start the productive problem solving phases as soon as possible. As the saying goes, "even the longest journey begins with a single step."

------------------------------------------------------------------------

•Details of some of the Year 2000 Factors

1. Incorrect century

Problems can occur when the first two digits in a year are assumed to be 19 and are:

•Ignored during data entry and update, or

•Hard coded for output.

2. Dates used as a special value

Special values of the last two digits in a year might be used for special purposes. For example 99, 365/99, or 12/31/99 (31/12/99) might be used to indicate "no expiration date", or 00 to indicate an "unknown year."

3. Incorrect field format determination

Some existing programs determine the date time format (that is, MMDDYY, DDMMYY, YYMMDD) by testing an appropriate part of the date field. For example, checking if the first two characters of the date field are values within an acceptable month, day, or year range (such as 01 to 12, 01 to 31, less than 32, etc).

4. Arithmetic calculation

The arithmetic calculations that operate on dates with 2 digit year representations might have potential exposures. For example, a person with a birthday of 15 January 1942 will be considered to be 42 years old rather than 58 years old on 15 January 2000 if the years 1942 and 2000 are represented by 42 and 00, respectively (that is 00 42 = 42).

Generally, a program that is not expecting a signed value, will ignore the sign; thus, in this example, the 42 might be interpreted as the absolute value 42. Not only is the value still incorrect, it is even less detectable than the incorrect 42. Further, if such incorrect data is then stored in a data base, it is considered a data integrity exposure.

5. Sort/Collation Sequence

When only two digits are used to represent a year, programs that collate year data will sort that data out of sequence in some cases. For example, the year 2000 (if represented as 00) will be ordered prior to the year 1999 (if represented as 99).

6. Data integrity

In programs where historical dates are used, all events occurring in, for example, 1800, 1900 and 2000 are not distinguishable when the years are represented by only 2 digits.

7. Leap year calculation

A specific year is a leap year if it is either evenly divisible by 400 OR evenly divisible by 4 and not evenly divisible by 100. For example, the years 1700, 1800, 1900 and 1995 were not leap years but the years 1600, 1996 and 2000 are leap years. Some potential exposures caused by the identification of the year 2000 as a non leap year are:

•Day in year calculations. The year 2000 has 366 days, not 365.

•Day of the week calculations. 28 February 2000 is a Monday and 1 March is a Wednesday, not a Tuesday which is 29 February 2000.

------------------------------------------------------------------------

•Other Factors which Further Complicate Matters

1. Missing Source Code or Documentation

Most IT shops will know that some software is in production and has been for some years for which no source code can be found, or for which the latest version in production does not seem to correspond with the available documentation. To recompile or rewrite may introduce totally unexpected problems, such as the return of old bugs.

2. Backed up and Archived Data

If the current systems in operation are not Year2000 Compliant, then it is extremely likely that the backed up off-site data is not either. A decision then has to be made as to whether this data is also to be converted when the current data is converted. And how far back is this done?

3. Customised Packages

Almost invariably package software in larger companies is customised to ‘fit’ the company. many of these customisations are not adequately documented. When the package software provider releases its Year2000 Compliant version, its implementation on the client’s site may overwrite the customised changes which have been made.

4. Old no-longer used Languages/Tools

Many existing production systems were created in older programming languages or older development environments. The people with the knowledge of these older languages may have retired, left the company, been down-sized (!) - and there are probably not enough left to solve every company’s problems in time. Thus the cost of these scarce resources is likely to double each year. Our estimate is that such people could command in excess of NZ$500 per hour in 1999.

5. Testing Difficulties

At some point, all software and hardware components in a system must be tested together to confirm that all interfaces are working correctly. For a 24-hour-a-day international online system, this will be an absolute nightmare and fraught with difficulties.

How can such a system be tested with any degree of confidence around the world through different time zones, bearing in mind that New Zealand will hit 1 January 2000 2 hours before Australia and 13 hours before the United Kingdom?

6. Inaction

Delaying taking action will lead to you being trampled in the rush. There are already numbers of stories circulating indicating that vendors, well aware of what has to be done, are desperately trying to convince their client base to start taking action immediately, but to no avail. As every week passes, the likelihood of a stampede increases and becomes ever more unavoidable. Don’t let it be you.

-----------------------------------------------------------------------

•External problems as well - the Domino effect

An awful realisation is now dawning on many CEOs as they begin to understand that even though thousands, even millions of dollars may be spent solving the year 2000 problems, this expenditure may be wasted as their installations are reinfected from outside. Worse still, one or more of the organisation’s suppliers, upon whom the survival of the entity depends, may collapse because of poor preparedness for the year 2000 problems and, with a terrible domino effect, cause mayhem and possible catastrophic destruction on down-stream customers (and upstream suppliers).

Rumour has it that there are over 11,000 banks in the United States, and it would be a brave person to bet that every single one will be 100% compliant by Saturday 1 January 2000. The collapse of one or more of those institutions could have wide-ranging effects, including possible impacts in New Zealand.

Thus, for a thinking organisation, a fortress strategy is an absolute requirement, blossoming out from a single room in which all electronic date-involved items are Year 2000 Compliant. The walls of the fortress are progressively expanded as each adjoining area is made totally-compliant. For this strategy to succeed, a powerful Year2000 Executive must be appointed and who is to be solely responsible for the addition of any new hardware or software into the fortress. That Executive must also ensure that any data in the fortress is compliant and remains compliant, with no non-compliant data being admitted from external (to both the fortress and/or the organisation) sources. External suppliers must be asked to commit to year 2000 compliance as soon as possible. Delays here will affect your own organisation.

------------------------------------------------------------------------

•What is the goal?

The goal is to have all information systems become fully Year2000 Compliant and cleanly tested and thus able to process all date-related material before, during and after the start of the year 2000.

As a Chief Executive or Director, when you face your shareholders who ask what has been the return to the company from this project on which you have spent some much time and money, you can respond:

"Our information technology systems and strategies are correct and accurate and in place. More importantly, our company is still in business, it is processing its invoices and statements correctly, it correctly calculates interest, accurately pays our bills and payrolls on time, and accurately calculates the values of our differently-aged inventory. Many of our competitors are unable to do the same. We have a major competitive advantage."

------------------------------------------------------------------------

•Our definition of Full Year2000 Compliance

While the following may not be easily achievable, we consider it is THE goal:

1.All date fields stored electronically in systems we run will be held as 8-digits in the ISO-8601 standard format of YYYYMMDD. This is to apply to every system operated within our company, whether they have been developed by us or are packages licensed to us by external software vendors/producers.

2.All date fields accepted electronically into our systems (with the exception of human input) will be in the same ISO-8601 format - ie files transferred or transmitted to us electronically from 3rd-parties

3.All date fields transmitted or transferred by us to outside 3rd parties will similarly be in the full 8-digit ISO-8601 format.

4.Any printed reports from these systems will, by preference, print 4-digit years. 2-digit years will only ever be printed in those cases where by context, the implied century is unambiguous.

5.Any human input of dates via screens etc must be unambiguous.

Thus the input of a 2-digit year is acceptable if and only if the context of the application makes the assumption of the century blindingly obvious. Any such dates must be stored in the full 8-digit ISO format. In all cases, unless absolutely prevented by space considerations, the entry of 2-digit year will be responded to with the display of the interpreted 4-digit year. Should the operator wish to change the century, then a 4-digit year must be able to be input.

6.All hardware and software must accurately return today’s date on any date.

7.No value for today’s date will cause any interruption in our operations.

8.Any processing involving dates will behave consistently and as expected for all dates concerned, whether before, during or after the year 2000.

9.The year 2000 is recognised as a leap year.

------------------------------------------------------------------------

Stage 2. Inventory, Assessment and Triage

Stage two entails the taking of a full inventory of hardware and software in every site within the organisation in order to determine the potential exposure and scope.

Corporate managers must conduct an exhaustive inventory of their portfolios of hardware and software, and also of other date-dependent items (such as fax machines, electronic lift control systems, electronic access systems for car parking areas, GPS systems, etc). The executive charged with this responsibility may frequently be the senior IS manager within the organisation but there is a case to be made for some other senior executive to be appointed to this vitally important role.

Sizing the Problem

This inventory stage entails itemising and recording all software (proprietary and vendor supplied), hardware, networks, databases, files, languages, utilities, and objects on a corporation-wide basis. It is important to stress, especially in the New Zealand environment, that addressing only the computer room overlooks other major errors for year 2000 problems.

This inventory should give a comprehensive view of an enterprise's mechanisms for receiving, storing, translating and transmitting data. Without such an inventory, an organisation will not be able to assess the dimensions and costs of the Year 2000 problem.

Specialist Year 2000 inventory software is available from companies such as Year2000 Ltd.

Although software is available which can help in determining where Year 2000 problems may exist in applications, this process requires significant manual time.

The inventory conducted needs to be exhaustive for although it may be that only some major hardware and application areas may be of major concern to the organisation, this cannot be known until the total problem has been at least identified in general. Most commonly this is done on a top-down organisational basis, commencing with the overall entity, and thereafter splitting down into component companies, locations, buildings, floors and then rooms.

Within each room, all items are documented initially at the hardware level and then broken down further through operating environments, applications and data.

The most complex areas will no doubt be the organisation’s data centres, but care must be taken not to overlook the issues associated with PC hardware (RTC-BIOS) inconsistencies. Huge amounts of data are held (and relied upon) unofficially in many cases by spreadsheets and the like throughout the organisation - and if the dates in these are unreliable, then ....!

As an integral part of the portfolio inventory, complete documentation must be established and, importantly, thereafter maintained (especially in the face of additional; hardware and software).

Once the inventory has been completed (although as a living document, perhaps this may never be a singular point), estimations of the complexity of the programs must take place. The more complex, the bigger the "clean-up" effort. This is a critical step, especially when it comes to budgeting. Especially in the mainframe sector of the IT marketplace, there are a multitude of vendors with tools and services who are more than willing to lend a hand and whose claims may be very hard to refute at face value. Several companies boast of man-hour saving assessment tools that not only scan your inventory, but also recommend other related tools for implementing the "perfect" solution for a particular system.

To the best of our knowledge, there is no perfect solution and the estimates we have seen from overseas indicate that probably no more than 80% of the occurrences of "date" areas will be detected and thereafter the human effort begins on the correction phase.

Assessing what is to be done

The next major part of the problem-sizing process is then to identify which items within the inventory (or hardware, software packages, in-house systems, etc) are definitely not compliant, likely to be non-compliant, are compliant or that it doesn’t matter.

To do this will involve significant testing, especially with the introduction of false dates (eg 31 December 1999 with a time of 23:58). For many organisations this will not prove to be a major hardship, particularly when considering non-mission-critical equipment and systems. But to deliberately introduce false dates leading to potential failure on a internationally-accessed production system may not necessarily be the smartest thing to do.

But each item MUST be checked for compliance, and it must be checked sufficiently far in advance such that if it does fail and if it does need to be corrected, it can be so corrected before it fails in a live environment. Fortunately, especially when considering PCs, much time can be saved once groups of like PCs and like PC-packages are identified - thus enabling one set of solutions to be replicated with reasonable ease.

Systemic Triage

Once a company has determined its inventory and assessed the states of compliance of the component items, decisions must be made as to how to allocate resources to fix the problems. Priorities must be set based on the criticality of the item.

The medical concept of triage is useful in this environment:

a.those who will survive if they get no medical treatment; b.those who may survive if they get medical treatment; c.those who will most likely die even if they do get medical treatment.

The first and last are ignored, and efforts are concentrated on the middle group.

So it is with systems, except that it is the business which is to be saved rather just the application itself.

Identify all mission critical systems upon which the business depends - this is the first group. The second group are those without which we could survive for a while but uncomfortably so; we could get by for a while. The last group are those that we don’t really need at all. Nice to have, but a bit like the fins on a 1950s DeSoto!

Ignore all but the first group. Really? Yes, correct.!

All your efforts and resources (which are very scarce and getting more and more expensive by the day) MUST be concentrated on getting your mission critical systems compliant, operational and fully tested way in advance. Any other approach should lead to your automatic dismissal for bad judgement.

Once, and only after, that task has been completed would you even consider looking at fixing the second group. To be somewhat more efficient in this changeover, consider (at least initially) reducing the functionality of the system under consideration.

It is vitally important to have tight controls in place so that valuable resources (including time) are not wasted on non critical systems.

------------------------------------------------------------------------

Stage 3. Research & Planning

Once the systems inventory has been prepared, stage three involves reviewing the results of the inventory assessment, determining what needs to be done to correct the Year 2000 problems and finding out what are the best methods for achieving this.

After the assessment and triage phases, someone within the organisation must investigate what options are available to the organisation to fix each of the critical areas so identified. In most medium-sized entities, this will be the replacement of smaller systems (those bought in a shrink-wrapped form, etc) and the upgrading of larger suites to the compliant versions (if not already done so).

Then planning, time-tabling and resource scheduling must take place.

Solving the Problem - do it In-House or use an outside Vendor's Solution?

Should an organisation fix its own Year 2000 problems or should it employ some external solution? The question is a critical one in forming a strategy to tackle Year 2000 processing. Some will not have a choice if the skills required are no longer in house (after right-sizing, down-sizing, dumb-sizing!). Others might find the cost of external resources prohibitive. For the majority, the solution will be a combination of both.

For the majority of New Zealand companies, particularly those with minis and PC network combinations, the most likely scenarios are the replacement of suspect or non-compliant items (eg older PCs) and the upgrade of software to compliant versions. In some cases, compliance may only be obtained by the switch to a new package - if such a step must be contemplated, then it must be done very soon.

There is a growing risk, if the problem is left and left and left, that suppliers will be unable to provide the hardware, software or liveware (ie staff) to do the upgrade/replacement in time.

In choosing to do the work itself, an organisation might conceivably gain better control over a custom fit solution with a reliable resource pool. However, in doing so it will forfeit the ability to leverage "ready made" solutions in the marketplace which might be cheaper and faster to implement, particularly if the organisation is in the larger group. Given their focus and experience on Year 2000 issues, many mainframe software vendors are well positioned to offer proven methodologies, conversion tools, and project management services. The opportunity cost of doing this work internally can be measured in terms of the shift of resources away from other technology projects designed to further business objectives.

Knowing the vendor's solution and the timing of that solution is critical for the enterprise canvassing outside services for support. Of course, first understanding the size and complexity of the enterprise's exposure better positions a company to judge whether to invest in new systems, upgrade old ones, outsource work, or assess vendor offerings. The optimal mix of solutions for any given enterprise will be one which affords it control over the process, efficiencies in terms of time and cost, appropriate coverage of its business exposure, and effective planning measures in meeting the Year 2000 deadline.

------------------------------------------------------------------------

Stage 4 - Conversion/Replacement & Testing

Stage four, possibly the most critical stage of all, involves the conversion of all data and software, and the testing of the fitness of those changes.

Most overseas commentators believe that organisations who have not completed the conversion/upgrade process by the start of 1999 (ie 12 months out from the turn of the century) are being needlessly put at risk by their executive teams. A full twelve months should be available to all entities to give them sufficient time to thoroughly test the new environments.

Systems can be redeveloped, replaced, renovated or retired :

1.Redevelopment

Briefly, redevelopment involves re-engineering using a new technology such as client server, and the existing system is then decommissioned. For many large systems, redevelopment should be strongly considered as some legacy systems simply aren’t worth renovating.. It can also be an opportunity to switch to newer technology now instead of sinking more maintenance dollars into systems which have limited lifespans.

2.Replacement or Upgrade

Replacement involves obtaining a new application or system, typically a competitive product to the incumbent software, to meet the Year 2000 and other competitive business needs. Upgrading means replacing the software with a newer and compliant version of the same software suite or package.

Of the two options, we expect upgrading to a compliant version of the software to be the most commonly adopted approach by the bulk of New Zealand companies, as a major problem with the replacement option is the steadily decreasing amount of time in which to undertake a proper evaluation and then installation of a major system on which the business may depend. It is probably too late for this option for the largest companies.

3.Renovation

This is also likely to be a commonly adopted year 2000 strategy, especially for these IT shops having significant custom-built software or having standard packages surrounded by custom-written reports and sub-systems. This will be an attraction option for custom-written systems as the user will notice little change between versions and no requirements analysis need take place. Renovation also preserves company assets such as its business rules and logic. Outsourcing is another reason to choose renovation as it allows third parties to complete mundane programming tasks while the organisation’s programmers can work other projects. Last but not least, renovation is the cheapest and the fastest of the possibilities (other than retirement).

4.Retirement

Retirement involves the discontinuance of outmoded or redundant applications. These systems should be identified from the inventory and assessment phases undertaken earlier in the Year 2000 project.

Testing and Validation

Restructuring, redevelopment and replacement all have substantial testing requirements associated with them to ensure that new or modified systems function correctly. For example, with restructuring, changed programs must be recompiled and tested before these systems and their converted files are moved back into the production environment.

Every modified system and its interfaces must be tested with year data before and after the year 2000. In many cases, testing and implementation is the biggest and most time consuming stage of a year 2000 project and according to some estimates, testing and implementation account for about 40% of an organisation’s total project effort.

Year 2000 industry consultants overseas estimate that testing and deployment together could account for up to 53% of the time spent. Testing particularly represents a challenge, since it must be performed in all systems, even those that have not been updated. Here, coordination is critical. Make sure all cases are checked. Deploying new code also can be difficult; the resources required to maintain test and production "regions" can easily overwhelm an organisation.

------------------------------------------------------------------------

Stage 5 - Implementation into Production

Stage five is that critical phase where all modified objects and files are introduced into the production environment.

Implementation

Whether a standardised approach is developed or not, IS managers will have to ensure their solution is part of a coordinated effort across both other parts of the organisation and external associates. Otherwise, today’s solutions may very well be tomorrow’s nightmares. For example, differing sites may implement new versions of "Year2000 Compliant" packages or software at differing times, thus leading to incompatibilities (possibly even unnoticed) at the transfer interface between those sites.

Naturally major consideration has to be given to the implementation of major applications where these cross time-zone boundaries (eg a New Zealand Head Office with branches or production facilities in Australia or Asia, etc).

------------------------------------------------------------------------

Stage 6 - Monitoring

To monitor, identify and correct any data corruption or system failure as a result of the Year 2000 effort.

Post 2000 Damage Control: Dealing With the Aftermath

Whether an enterprise's solution has been home grown or vendor supplied, contingency plans are as crucial as the implementation plan itself. Recovery from system failures must be considered on an automated as well as an operational level. An organisation will have to design corrective procedures in the event that all has not gone according to plan. Contingency plans should cover an entity's exposure with its clients, business partners, regulators, and others. Industry experts recommend that 1999 be set aside as a contingent processing year to "shake out" possible system faults. Clearly those that are not in a position to recover quickly will pay dearly in the end.