HP World Presentation:  Contingency Planning for Year 2000 - developing a framework

 

Paul Wang

 

 

Introduction

 

Due to the scope and potential impact of the Year 2000 problem, every company needs to engage in some form of contingency planning. Y2K compliance affects such broad areas as:  information systems, financial statements, information processing, manufacturing control systems, factory/production, electric/gas/water/telecom, federal/state/local government.  Thus, the Y2K problem is different than traditional disaster recovery plans, because one can’t just change the location in order to continue business operations.  With Y2K, all business locations and sectors may be affected.

 

Business continuity and maintaining organization stability are primary goals in contingency planning.  In order to plan for business continuity, organizations need to address the mission critical items, recognizing the risks.  These risks include internal issues such as infrastructure, IT and employees as well as external issues such as power, water, transportation, partners, supply chains and third-party vendors.  The key is to identify which type of failures may arise and understand how to prepare your organization to effectively deal with these failures.  The steps in risk management include:  identifying the risks, establishing the likelihood of occurrence of each risk, understanding and evaluating the associated business impact, and developing strategies for prevention, mitigation and response.  This approach enables an organization to create a level of preparedness that is acceptable to senior management. 

 

As outlined, the contingency planning process includes a broad range of business risks.  The remainder of this paper will focus on application issues within Information Technology (IT ), an area that becomes increasingly important as we approach January 1, 2000. 

 

 

IT Contingency Planning

 

At the application level, IT professionals tend to focus on a single aspect of contingency planning, mainly, what happens if they do not complete the application conversions.  However, there are three other possibilities for contingencies that should be considered.  First, the possibility that an application can handle data entry and reporting of Y2K dates, but the specific hardware and/or operating system involved will not handle Y2K dates.  Second, the hardware and/or operating system will support the Y2K dates, but it is not practical or feasible to convert the source code and the company does not plan to convert the application. Lastly, the unfortunate disaster recovery situation may result from a system crash on systems that were thought to be Y2K compliant.

 

 

The 28-year rule

 

It is widely understood that the issues involved with running a production application with a simulated date can be confusing.  The primary concern revolves around the day-of-week.  For example, March 1, 1999 is Monday, and February 29, 2000 is Tuesday.  Because many applications utilize the day of week, when using date simulation, it is important to select a year that will provide the proper day-of-week information.

 

Because many IT professionals have not had the time to consider this issue, they may be unaware of the 28-year rule.  In the date simulation environment, the 28-year rule is widely known and accepted as the best method.  The 28-year rule simply states that the simulated date must be a twenty-eight year interval from the current year to provide 100% day-of-week processing.  The 28-year rule not only provides for typical day-of-week issues, it also handles the leap-year.

 

Using the 28-year rule, if the simulated date needs to be in the 1900s, March 1, 1999 would become March 1, 1971.  February 29, 2000 would become February 29, 1972.  This method will allow the internal processing of the application to function properly.

 

 

Modifying the Dates

 

Date simulation within a production application must address the issue of modifying the internal dates.  Assuming the 28-year rule is used for an application to run with the simulated date of the 1970s, what should the end-users enter on screens or see on reports?

 

Figure 1:  Date Modifications

 

                               

 

 

Figure 1 shows the flow of data within a typical application.  There are two primary methods for an application to receive data and three primary methods for transmitting data.  For input, either an individual enters the date through a device, such as a PC, terminal or barcode reader, or the data is received electronically from another computer, like a direct deposit from a company's bank to an employee's bank.  For output, applications either store the data and re-use it later, report the data to hardcopy or to electronic mail, or feed the data to another computer.

 

When using the 28-year rule, it may be necessary to modify an incoming date, or an outgoing date.  In Figure 1, the lines represent the transfer of data from one level to another.  Following data from entry to output is represented with the five steps.  If date modification is not necessary, possibly the applications current status, then levels (2) and (4) are bypassed (represented by the solid arrow-lines in Figure 1).  If it is necessary to modify the dates, either upon receipt or transfer, levels (2) and (4) might be necessary.

 

When adequate resources are available, the best solution is to modify the dates at both levels (2) and (4).  This allows the end-users to always work with the current date.  However, in some case, resources can be saved by not modifying all of the dates.  For example, in a very old application with few end-users, all manual input and all hardcopy reports, it may be possible to never alter the date and to train the users to understand that 1971 is 1999, 1972 is 2000, 1973 is 2001, etc.  In this example, all of the date information is based on the 28- year rule.  The input, output and storage of dates will be based on the rule.  Naturally, this will not be a common solution.

 

In some applications, it may be possible to alter the date only during hardcopy output.  In this situation, the end-users who enter the data will be trained to manually enter 1971 for 1999, 1972 for 2000, and so on.  However, on the hardcopy reports, a date modification routine is implemented to add twenty-eight to the year.  The database will still maintain the data offset by the 28-year rule, and therefore will store 1971 for 1999, 1972 for 2000, etc.  When there are few end-users entering data, but many end-users reading output reports, this is a valid option.

 

Another option is to convert the dates throughout the whole process (represented by the dashed lines in Figure 1).  This requires the most time, but results in the least amount of confusion.  The end-users enter 1999, 2000, etc.  The electronic date input is 1999, 2000, etc.  The reported, stored and transferred dates are 1999, 2000, etc.  In this example, the application is surrounded by a programmatic “cocoon”, which always adjusts the dates forward or backward twenty-eight years, "protecting" the application from the year 2000.  As with the first example, this is not a commonly selected solution because of the resources required to implement.

 

As can be seen from these examples, there are several ways to implement the processing of the 28-year rule for any given application.  The important point is that the IT professional must fully consider and understand this issue when implementing a contingency plan.  If an application fails on January 1, 2000 because of a Y2K problem, it will be necessary to adjust the date.  Which of the many possible implementation methods will be chosen?

 

 

Summary

 

Date simulation tools offers many benefits for contingency planning. As January 1, 2000 draws near, contingency planning is a necessity for organizations. Using date simulation tools in the IT contingency plan allows companies to spread the Y2K risk across several months. To recap:

 

·         Date simulation is a valid and cost-effective part of any Y2K contingency plan.

·         When implementing a contingency plan, it is necessary to understand the 28-year rule and the possible effects on applications and data.

·         Date simulation tools can help with the emergency Y2K contingency by allowing quick and easy implementation should problems arise on January 1, 2000.

·         For pre-planned contingencies, date simulation tools are extremely beneficial, and allows the implementation of the contingency months before January 1, 2000, thereby spreading the Y2K risk across many months.