Establishing a Year2000 Program

Executive Summary
Background
1. Origins of the Year2000 Problem
2. Why the Y2K problem is still with us (or why is 'software' so hard)
Different Perspectives on the Year 2000 Problem
Year2000 Program Considerations:
Sources of Help
1. Year 2000 Information web pages
2. Vendor web pages

Executive Summary
Business is dependent upon computer technology -- in many places the staff no longer remember how to work without it and would be unable to handle the volumes if they did. Over the next few years as the end of the century is approached and passed some programs that store and manipulate dates using certain obsolete techniques will begin to break down and produce incorrect results. It is not unreasonable to expect that some businesses will not survive if unable to manage receivables or schedule production as a result of this issue. Many will be associated with the turn of the century -- for this reason the problem is known as the Year2000 problem.
Simplistically, correcting the Year2000 problem requires modifying date handling and sometimes expanding databases. While many of the coding changes required are minor, finding the places to fix can be a major effort. And upgrading very large databases to change date field sizes can be very difficult and time-consuming. Testing the changes afterwards can easily be as much as half of the total effort.
Program age is no determinant -- even new code could use these shortsighted techniques. Because of their ubiquity it is likely that not all Year2000 problems will be caught and corrected in time - so it is important that an organization identify and manage their exposures. And the worse part is that only a fraction of the code that may need correction is accessible -- the rest is buried in smart fax machines, point of sale devices, routers, elevators, building environment and power management systems.
Background
1. Origins of the Year2000 Problem
  Data storage space has always been a premium. Early commercial programs were carefully designed to minimize both persistent and transient storage requirements -- which from the perspective of the 1960's and 1970's meant that discarding the century to save two character positions per date entry was very desirable. This easily led to doing date arithmetic assuming that year numbers would always increase -- not true after Dec. 31, 1999 if one only uses the last two digits. Special codes such as '99' or even '98' were also used to indicate such things as 'never' or 'unknown'. Programs using this type of special code in date fields could start failing well before the end of the century. Or to look at in in another way, the Year2000 'problem' is really the end of the road for some of the old space saving techniques that were once essential to make commercial computing viable but are now liabilities.
2. Why the Y2K problem is still with us (or why is 'software' so hard)
  No one would have believed that code written in the 1960's and 1970's would still be around at the end of the millennium and that these space-saving approaches would still be present. But it is often easier to migrate an old but functioning program to new hardware than to rewrite it using contemporary techniques -- indeed some vendors maintain a whole series of emulators to ensure that old code can still function. The millennium date problem has its roots here but with two additional aspects: these coding and storage techniques became 'the way to handle dates' well outside the arena for which they were developed. And these approaches were picked up by designers writing low level code on the new microprocessors. As a result, date-challenged logic extends far outside the original domain.
Different Perspectives on the Year 2000 Problem
1. Year2000 is an Inventory Management Problem
  Effective technology inventory management is essential to addressing the Year2000 issue. It is necessary to know where every piece of technology is, who supports it and where it came from. Once an inventory is built it must be maintained -- in most organizations technology content changes constantly, keeping the inventory current can be a significant challenge. It is unlikely that this can be done without the express cooperation of the procurement and development areas. It is helpful to enumerate all avenues of change flowing through the organization and ensure that checkpoints are established on each.
2. Year2000 is a Business Organization Problem
  It is necessary to understand the functional organizational structure and the relative importance of each business function in delivering the product or service and producing a return for the shareholders to effectively prioritize Year2000 issues. For example, while a sales organization or senior management group may be important from an organizational perspective, a business that cannot process receivables correctly will cease to be a business very quickly. Understanding core functions and relationships is helpful in prioritizing Year2000 efforts and developing contingency plans for the inevitable failures and incomplete conversions.
3. Y2K is a software maintenance problem with a hard deadline
  From a software perspective the year2000 issue can be reduced to a maintenance problem - errors in program logic to be corrected, database file storage space to be enlarged and restructured or other approaches adopted. What is unique about Y2K is that unlike most other software maintenance problems it is tied to an immovable key date -- that is very, very close. For owned applications the level of effort required could vary widely -- depending upon the programming language, degree of modularity and many other factors. For older programs there could be the additional complexity in that the necessary source files might not be available. For programs embedded in 'smart' devices such as routers, fax machines, building management systems and the like -- the issue becomes a support issue and vendor management problem to ensure that any necessary fixes are installed in time.
4. Why Your Business Partners are Involved
  Electronic commerce is a thing of relationships -- computers exchanging messages with other computers which represent funds transfers, orders, acknowledgments, etc. Many of these messages have embedded dates -- which must be consistent across the trading relationship for the transaction to 'work'. Application changes visible at this interface needs to be coordinated with the partners using it to ensure that the corrections do not 'break' the process. Some industries have already established schedules for coordinated testing to ensure that the entire relationship will work correctly - SIA on Wall Street, for example, has designated several weekends in 1999 for member firms to test their systems in an integrated manner.
5. Expect that external professional organizations and the legal profession will get involved eventually
  Many professional organizations and industry groups are becoming active in the Year2000 area due to the potential impact of the issue and the need for coordinated activities among business partners within the industry. The legal profession is becoming involved as disputes over software performance and responsibility for year2000 changes arise -- is the Y2K problem a bug fixable under existing support relationships, or is it a requested enhancement or something else? And as awareness of potential liability increases, some firms have turned to their lawyers to draft Y2K statements to satisfy their customers while positioning to avoid future legal exposures.
6. But take heart, Jan 1, 2000 is a Saturday so your staff has the whole weekend to fix stuff.
  Seriously, the extensiveness of the issue suggests that a firm choosing to wait to this point to address Year2000 issues may not survive.
Year2000 Program Considerations:
1. Year2000 can be a 'bet the business issue', don't delegate the problem to the information areas and forget it.
  While at first look this is a computer problem which seems to belong in a systems area, the potential impact to the organization suggests that senior management attention is merited. For any organization an initial assessment and impact analysis is warranted. Once the nature and extent of exposure has been evaluated and presented, senior management will be able to establish the organizational priorities to enable the systems staff to elicit the necessary cooperation of the business units and their external partners.
2. Watch the calendar - analysis paralysis can be a real danger with this problem.
  It is important to do the initial assessment as quickly as possible, then go back and do further investigation of critical items. The closeness of the deadline and probable extent of the technology inventory suggests that not everything will be addressed in time, so it is vital to attack the critical items first. Code reviews and testing can be very time consuming and should only be initiated when the relative priorities of a component are understood.
3. Form a task force with representatives from business, information services, facilities and procurement and appoint a project manager.
  The issue potentially affects every area of the business -- form a working group composed of representatives from each major area of the business. This will helpful in quickly establishing the key business functions, dependencies, relative priorities and start a technology inventory.
  1. If you have an existing contingency planning function this process can be accelerated -- there is a lot of overlap between the information needs of contingency planning and year 2000 problem management.
    The information gathered to build a corporate contingency plan is very similar to that needed to establish a Year2000 project. Both activities require that business functions be identified and prioritized, supporting services catalogued and strategies developed. But a Year2000 project must not only know what technologies are required to support a business function but must ascertain whether those technologies are affected by the Year2000 date problem. And if problematic then contingency plans need to be developed and alternatives investigated -- tasks that a contingency function should have some familiarity with.
4. Ascertain the size and seriousness of the problem
  Exposure assessment and risk analysis is critical to establishing the scope of the Year2000 exposure. This requires a technology inventory and a quick assessment of potential Year2000 issues. The inventory and its assessment is applied to the business function list and a prioritized list of technologies that could affect the business is produced.
  A technology inventory is a list cataloging all computing equipment, software packages, internal applications and external business services. It will be essential to track where within the firm the component was used and note how it is supported and if available, where it was purchased from. The facilities area will need to inventory things like elevator controls, intelligent environmental controls, power conditioners, security systems and the like. Getting compliance information back from vendors can be time-consuming but inventory items can be prescreened by asking questions about date intelligence in the item. If the item does something with dates (even time stamps in logs) it should be investigated further. The same applies to software packages and computing equipment -- but anything containing a microprocessor probably does something with dates. In-house applications should be screened for date handling, aging and use of special codes. Business power users may have written spreadsheets, macros or private databases that need to be inventoried and examined as well.
  1. Obtain or develop a high level business process model
    A sketch of how information (and work) flows within the organization will be useful in determining how to approach the problem.
    1. Catalogue business functions and their respective priorities.
      Making a catalogue of the different functions within each business unit and reviewing with upper management the relative priorities of each function will also be useful for organizing the problem. It is important to note that the perspective for assigning priorities should be relative to the survival of the firm - i.e. how essential to the continued operation of the firm is a function. Things like receivables processing tend to rate pretty high.
    2. Determine business dependencies between functions.
      Try to understand how the information (orders, etc.) flow from one areas functions to the next. It will be along these lines of information flow that systems which should be changed together are identified.
    3. Document information flows among the business units.
      Capture the flow information some how - write it down, diagram it, whatever.
    4. Document interactions with external services (content, mediation and direction)
      Do a similar thing for external services to be sure at least that all computer data exchanges are documented. Understand the transmission data formats and whether information is received, sent or both. This is critical for all computer to computer interchanges. It is much less so for external applications (such as market data displays) where the interface within the firm is human.
  2. Establish a business and technology inventory
    1. Inventory supporting technologies
      As the business function inventory is being constructed, catalogue what is used to perform the operations of the business. For example, a purchasing department may use a PC with an Excel spreadsheet for determining economic order quantities for procurement. In this example, the PC, Windows and Excel would be supporting technologies in that they are used to support and enable the business function.
    2. Don't ignore user-written tools such as spread sheets or mini-databases
      Many businesses are dependent for their day to day operation on small applications and databases developed by their employees. It is not unusual for such purpose-developed applications to become critical to the daily operation of a business. As such, it is important to identify them and (if possible) the tools that were used to develop them.
    3. Prioritize the technology according to business significance
      When the business function and technology inventory is complete, a management team should rank order the functions according to their significance to the ongoing operation of the business. This prioritized list should be used to direct the order in which technologies are reviewed for Y2K issues. The assumption here is that not everything will be reviewed and corrected prior to year2000, so a prudent manager will ensure that the most important functions are addressed first.
    4. Amend the inventory based on known plans for replacement systems, new services and discontinued technologies (project what the technical environment will be like in 2-3 years).
      Future business and technology plans should be reviewed to identify systems and functions scheduled for replacement prior to the end of the end of the century. Desktop computers, for example, are often replaced every two or three years so it may be unlikely that any of the present desktop inventory will still be in use by Jan 1, 2000. The superseded systems can in all likelihood be red circled and excluded from subsequent analysis. It is prudent, however, to identify key dates past which implementation of the replacement system in time to avoid a Y2K issue becomes unlikely. This decision point then becomes the start point for evaluating the old system anyhow. Some analysis even of red circled systems is helpful, if for no other reason to estimate the effort required to fully investigate and correct Y2K problems. It is possible that this analysis would suggest that the critical review date, based on the corrective effort, might be earlier than one based solely on the implementation curve of the new system - this becomes an exercise in risk management.
    5. Catalog information exchange business partners - they will be an integral part of the process
      Very few businesses today do not exchange electronic information with their business partners. Every interchange is potentially a failure point and should be inventoried and reviewed. EDI record formats containing 2 digit years may likely change prior to the end of the century. It is prudent to cooperate closely with business partners to ensure that any changes necessary for Y2K are mirrored in a timely an orderly manner on both sides of the relationship.
    6. Upon completion, review dependencies and assigned priorities
      Business dependencies cause priorities to be inherited and perhaps diminished but never increased. That is to say that an unimportant function may be dependent upon more important functions -- but important functions should not wait for unimportant ones. So in effect the priority of an item is that of its most critical dependent.
    7. Identify compliance strategies and target dates for external vendors - many publish this one their web pages
      For packaged software and many other technologies, the original vendor is likely to have a web site in which they may describe their Y2K compliance strategy and status. The URLs for a number of major vendors are listed below. It is useful during an initial assessment to confirm the status of external packages. In some environments it may not be possible to test applications without compliant versions of all needed products. If these are not readily available, alternate test strategies and contingency plans may be necessary. In the PC environment it is not unusual for vendors to incorporate Y2K fixes in a future release or state that the current release as of some future date will be compliant. For most other platforms, software corrections may be available as patches that would need to be applied to the firms' computers by support staff. Embedded systems such as intelligent building management systems or elevator controls may require hardware upgrades to incorporate any compliance fixes.
  3. Do an initial exposure assessment
    1. Examine applications, looking for dates and special codes
      Once the inventory has been assembled and prioritized, it must be reviewed. Products that do not make use of dates can be tagged as such, although if external, it is prudent to contact the vendor and ensure that there are no hidden dates embedded within. External applications most likely become vendor management issues, where the vendor is contacted and the compliance date (if applicable) managed. Internal applications should be examined for two digit date formats in databases, date calculations using two digit years and built-in date entry ranges. Microsoft Access databases are almost always suspect in that this product treats dates as text, meaning that there are few constraints on manipulation. Special codes, embedded within date fields, such as '99' or even '98' are suspect. In the 1960's these were not unreasonable short term flags, but as the end of the century approached, alternate tags must be found. Do not forget to question applications with built-in date limits, some are legitimate, like expiration checks on postal code tables; others may be Y2K problems, such as some accounting programs refusing to accept dates past 1999.
    2. Review identified problems with the Year2000 assessment team
      Any issues or discrepancies identified by the application review, contact with with business partners or vendors, should be discussed with the business team and a business impact ascribed. The team should work towards understanding the cascading effect of problems on the organization to ensure that the significance of each issue is correctly understood. Business significance assessments should be documented and used to guide the conduct of the Y2K program. It will be useful to review these assessments periodically throughout the program to ensure that resources are allocated for optimal business impact.
    3. Discriminate between controllable and uncontrollable
      Not al date problems will be controllable - establish contingency plans that if key uncontrollable functions become problematic, that alternate sources can be established. Control functions that affect global services such as electricity, water or gas are potential liabilities -- hopefully their service providers are already terrified. Building services are another potential source of uncontrollable exposure -- the 'smarter' the building is, the more potential exists for y2k problems.
    4. Determine critical event horizons
      Understand the pattern of date usage within the application - the critical event horizon is the point at which program logic begins to break down. Programs with extensive future date references, like bond calculators, have probably already encountered the problem, programs using 2 digit years with special codes like '99' (which often used to mean undefined) may become problematic prior to the end of the century. Calculation of settlement dates (if affected by the Y2K bug) will probably not start to die until the last week of 1999. Sept. 9, 1999 is sometimes a critical date if the entire date (not just the year) was used as a special code. Receivables aging programs should similarly start to break down within the 'net' distance to the end of the century.
      Many businesses and governments use fiscal periods that do not align with the common calendar. Canada and Japan begin fiscal Year2000 in April, 1999. Many states and businesses begin fiscal Year2000 in July, 1999. The U.S.Government begins fiscal 2000 in October, 1999. Program logic around fiscal years should be considered in the evaluation of event horizons as well.
    5. Establish a project plan identifying key dates
      Understanding internal critical event horizons (times where applications can be expected to break down) and the availability of fixes for external packages enables the group to draft a rough project plan. This should also include dates for testing with business partners or external services.
    6. Summarize the exposure assessment
      Summarize the results of the assessment by affected business function. Be as specific as possible as to the nature of the Y2K defect found and its likely result. Identify whether this application or product was developed internally or externally.
5. Have contingency plans for everything important -- and identify the timeframes when they must be invoked.
  It is prudent to assume that not all vendors will deliver corrected versions on time (or at all) and that some internal projects will be delayed (or even fail). If the business impact of these delays or failures would be significant, it would be prudent to consider alternative solutions or workarounds. Implementation times and capital requirements should be estimated and critical start dates determined. Y2K efforts for any function requiring this level of planning should of course be managed closely -- the critical start date becomes the point where management must commit to the alternative (even as a parallel effort). Most capital approval processes can impose substantial delays on project initiations so it is prudent to pre-approve or incorporate the approval process in the contingency implementation lead time. The objective of this is to ensure that key business processes are operational at the required point -- even if some corrective efforts fail.
6. Establish a vendor management process
  Many of the Y2K corrections needed by businesses will come as updates or new versions for existing packaged software. These needs will have been identified in the inventory and subsequent follow-up with their vendors. Availability dates for these corrections need to be tracked to ensure that everything necessary is obtained. It will be helpful to maintain contact with vendors to ensure that their targets will be met and that any changes are reflected in the Y2K plans.
  A letter exchange with vendors and customers is helpful in raising awareness of the Year2000 issue. But it is not a substitute for testing of critical interrelationships. Regardless of how a vendor may respond, legal retribution after a Year2000 incident is a poor substitute for a failed business process.
7. Establish a change control process
  Over time, the technology content of most businesses can be expected to change. Performing a technology inventory is often not easy and it will be most valuable if it can be kept current. This is most easily done by means of a change management process -- establishing control points on every source of change in the organization. It most businesses there are three main paths -- purchasing, internal software development and business partners. Purchasing buys things to satisfy requirements from the business; development changes existing systems and creates new ones; business partners impose changes through alterations to their own systems. These sources can be coordinated most conveniently if a formal process is established to update the Year2000 inventory.
  1. Manage new stuff coming in - ensure that liability for compliance is established up front
  2. Putting riders on purchasing contracts for y2k compliance may be helpful
  3. Ensure that the users are in the program and do not do an end run around the controls
  4. Manage changes to existing technologies
  5. Educate developers and power users to ensure that Y2K problems are not reintroduced
  6. Be honest about discontinued systems - establish cutoff dates to ensure that they are validated if not replaced soon enough
8. Recognize that some things will still break so be prepared.
  An old definition of a trivial program is that it has no bugs. Bugs, or errors in program logic that cause the program to do things other than the programmer intended,
  are an all too common feature of any computer program. And even the most talented programmers may find it difficult to repair bugs without introducing new ones
  due to both the complexity of the software and the extent to which multiple programs interact to deliver services to the user. Year2000 analysis and remediation is not exempt from this fact. Year2000 scanning tools may miss some invalid program constructs. Conversion tools may break other things or fail to convert all of the Year2000 problems. Remediation may be incomplete or may introduce other problems. And testing may not exercise all possible paths through the program or incorrectly identify what occurred. These problems are not unique to Year2000 -- despite what some critics may say. The system interactions that occur with the actual date change will be far more complex than any possible simulation. And contingency planning must include essential external services as well as the internal technology environment in its scope. The MITRE web sites' year2000 resource and the articles database in the Year2000 information center can provide useful information around these issues.