DBMS, June 1996
The year 2000 is just around the corner. For many IT organizations, the dawn of a new century offers a formidable challenge. The reason is quite simple. In the early days of commercial applications development -- when memory was at a premium -- developers used as many shortcuts as possible. The shortcut that has emerged as the most important for many mission-critical applications is the use of a two-digit representa-tion for calendar years. Developers in the 1960s and '70s never anticipated that the applications they were putting into production then would still be around 20 or 30 years later. But, not only are these applications still around, they have grown larger, more complex, and less trustworthy. Historically, IT organizations have been reluctant to tackle the task of redeveloping long-enduring applications, both because of the complexity and the cost. But the arrival of a new millennium has caused a new sense of urgency for application developers.
The problems that will occur when 1900 looks exactly like 2000 to the computer system are becoming apparent. Programmers will have to take applications with hardcoded information related to calculating date-based information and translate them from two-digit to four-digit codes. If applications are reasonably well-designed and architected, the problem is not overly complex. There are already a variety of tools on the market intended to discover where date fields are and where dependencies lie. Other tools will help reconstruct such code. So, why is there so much discussion about the year 2000 problem?
The reason that the year 2000 problem is complex is related to the age and condition of many of the applications that run organizations today. Some of these applications should have been rewritten a decade ago. But even a decade ago, there was no time to rewrite applications. To make matters worse, these applications often have little or no documentation of business rules. I vividly remember one stressed IT manager who told me about a 25-year-old application that needed to be rewritten because of the year 2000 problem. Unfortunately, the application was so old that no one had any idea about the business rules that determined how payments were calculated for an annuity.
How should IT organizations approach the year 2000 problem? My recommendation may seem radical, but I believe it is the best approach. Stop wringing your hands and go to top management right away. Explain to them in business terms what happens when an application designed for the 1900s has to be massively reskilled for the next century. It should be a decision similar to those made about replacing aging industrial machinery or other equipment necessary to keep the business running. Would a CEO put off purchasing a new manufacturing system when the old one was about to die? Would a chief executive try to patch up an aging piece of equipment in order to eke out a few more years, when the company's very existence was at stake?
I believe that any intelligent CEO can understand the risks of not replacing a key corporate resource. Provide calculations about what it will cost to rewrite all of these date fields individually. At the same time, provide an alternative suggestion: Use available funds to create new modular applications that will help position the company for the future. This approach requires that you move away from the traditional approach of monolithic application development and toward an object-oriented approach that encourages developers to write smaller, better-defined services and components. Following is the approach I recommend.
First, take each application and use the tools available today to analyze what you have. There are many options on the market. For example, if you have Cobol-oriented applications, tools from companies such as Computer Associates, MicroFocus, Bachman, Intersolv, IBM, Compuware, and ViaSoft will analyze your code, isolate the date information, and help you separate code into more useful and more readable segments. There are also many organizations that offer both management consulting and assistance in helping you analyze your code. If you are dealing with a large volume of applications that need to be reworked, it may help to bring in consultants who know mainframe code and can help you more quickly get your house in order. Look for consultants who have already completed year 2000 projects for other companies -- preferably in your own industry. But don't simply dump the problem in their laps. Your own developers and managers must be involved in the process. Therefore, look for consultants that will mentor your staff and will not expect to live with you for the next millennium.
Second, once you have segregated this logic, you should begin to look at the functions performed by these applications. These should be reconstructed into application services that will be used in that specific application as well as others. For example, you may have an interest-rate calculation that will be used frequently. Use the year 2000 issue to begin organizing your development structure around a services or component model of development. This will make it much easier to deal with future unanticipated transitions. Establish a task force to look at application services from an architectural perspective. This team should be composed of both high-level development personnel who understand applications architectures and key business personnel who can provide the business-rules perspective.
Third, you must have a strategy to deal with code that is fragile and not well understood. This code should be encapsulated and used until you figure out how it can be restructured. By encapsulating this code, you will take some of the pressure off your developers. But be careful here; do not assume that you're simply going to encapsulate the entire old application and be done. Encapsulation should be used only when a piece of code includes key business logic that is impossible to rewrite. You want to ensure that the new code represents a new way of developing applications.
Fourth, use the many new tools that are intended to help you solve this problem. There are tools that will first analyze the actual code. This can help you eliminate data fields and reports that are no longer used. There are also tools that can help you understand and segregate key pieces of business logic. They can document code and even decipher some previously unintelligible business rules. Some tools can even begin reconstructing two-digit date codes into four digits.
Finally, you need to plan the testing process. Naturally, you expect developers to test the new code they are writing. But you must also enable them to test how the new code interacts with existing applications. Often, management underestimates the time and effort required for the testing process. Given that we are talking about bet-your-business software, testing must be high on the list of essential requirements.
The issue is not that the year 2000 problems are impossible to solve. The issue is the inertia caused by the magnitude of the mound of code with which you must deal. I urge you to not wait any longer to get started. Do not be shortsighted. Thinking about how much money it might cost to convert a line of code for a four-digit field is the wrong approach. It is much more appropriate to think in terms of what it will cost if you do not address this problem. Having a critical business system collapse at the turn of the century is unacceptable. Start by educating top management about the issues and problems that your organization is facing. Don't assume that they will be unwilling to help. If they are forewarned and do not allow you to act, you at least have provided the knowledge required to take action.
The issues that are arising with the year 2000 are not isolated issues. They are indicative of the way that IT has long dealt with complexities of developing software. Too often we get caught up in dealing with an immediate crisis rather than taking the time and expense to solve the source of the problem. Perhaps we can use the looming year 2000 to change many of our current IT practices.