|
A y2k repair takes a long time. Here is the story of an Air Force repair project which began in late 1995 and which is still not complete. They had almost 40 million lines of code to correct.
If a 40-million line project is run with military discipline and cannot be completed in over three years, what about even larger projects? We don't know; there has never been a successful completion of one larger than 40 million lines.
Chase Manhattan Bank has 200 million; Citicorp has 400 million; AT&T has 500 million; General Morors has two billion.
But we told not to worry, that all will be well. It's a " challenge," not a looming catastrophe.
This article is a fine example of bureaucratic reporting. The author fills page after page with technical information on various aspects of the project, but neglect one item: an assessment of exactly where they are on the road to completion. The section on "Where Are We Now?" fails to answer the question.
But valuable information does trickle out.
First, they are not finished.
Second, the testing phase was underestimated every time.
Third, they have 77 different languages to contend with.
Fourth, over 60% of the systems have to be fixed or replaced because they are not compliant and cannot be abandoned." Expected to remain in place beyond 2000, but not compliant (47.1 percent, 56 applications). . . . Expected to be rehosted, reengineered, or replaced but not compliant (16 percent, 19 applications)."
Fifth, they initially did not consider the possibility of contingency planning. Now they do. Too bad they don't tell us what the plans are. "Contingency planning, an omission perhaps in the early phases of our project, has increasingly become a concern. We now acknowledge the need to plan system-level approaches to fix Y2K problems in a system before its scheduled conversion and deployment has occurred and business area proponents began development of these plans in June 1997. The replacement system progress must also be monitored to ensure Y2K compliance before deployment."
This is taken from the Air Force's journal of software engineering, CROSSTALK (Jan. 1998).
* * * * * * * *
Defense Logistics Agency's Year 2000 Program Managing Organization-Wide Conversion and Compliance
Sarah J. Reed Defense Logistics Agency System Design Center
The Defense Logistics Agency considers the year 2000 (Y2K) problem mission-critical, and we have treated it as such in planning and executing the largest maintenance effort we have undertaken. The agency kicked off a formal Y2K project in November 1995 with nearly a full year of planning, preparation, and piloting. This article discusses our Y2K initiative and our experiences in raising awareness and in assessing, renovating, and validating our systems. Our program, built on available industry research and our experiences, has been modified as we have gained fresh insight and assimilated new lessons learned.
The Defense Logistics Agency (DLA) maintains 40 million lines of code within 125 automated information systems. Over 80 percent of our major systems make use of date data in some way; half of those date references are high impact; that is, likely to adversely affect comparisons, calculations, or sort processes. . . .
We have 77 languages, the top languages being COBOL, C, and Assembler. Top database systems are Oracle, Rdb, and Unify. We use 35 different hardware platforms, 16 operating systems, and 311 commercial software packages for application development and maintenance. . . .
Expected to remain in place beyond 2000, but not compliant (47.1 percent, 56 applications). . . . Expected to be rehosted, reengineered, or replaced but not compliant (16 percent, 19 applications). If replacement initiatives experience schedule slippage, Y2K failures could occur within the existing systems targeted for replacement. We regularly track replacement schedules so that we can recommend the initiation of renovation or contingency planning should the replacement system initiatives experience schedule slippage. Contingency planning, an omission perhaps in the early phases of our project, has increasingly become a concern. We now acknowledge the need to plan system-level approaches to fix Y2K problems in a system before its scheduled conversion and deployment has occurred and business area proponents began development of these plans in June 1997. The replacement system progress must also be monitored to ensure Y2K compliance before deployment.
Expected to remain in place beyond 2000 and compliant (33.6 percent, 40 applications). Systems thought to be compliant were perceived to be at less risk than those that were not compliant. However, we insist that system compliance statements be supported with the submission of a certification checklist that describes the system and the Y2K-related testing effort. . . .
Where Are We Now?
There were 276 products identified as lacking complete compliance information. If the lack of information was because we could not properly identify the vendor, the AIS support group was contacted to help identify the product vendor to obtain the required information. Vendor contact was established or re-established to obtain new or additional information product information.
Improve software portfolio management processes. The great discrepancies between the view of what is owned, installed, and used was of such concern to us that we launched a major software portfolio management improvement effort, wider in scope and more permanent in its legacy than the Y2K effort.
Follow up with vendors expected to provide compliant products at a future date. For these products, we notify groups who support applications integrated with these products, because the projected date of compliance may be unacceptably late. We also make them aware of product upgrade impacts upon their application. Upgrade strategies will be developed on a case-by-case basis to manage application impact and ensure timely arrival, installation, and testing of the upgraded product.
Develop independent strategy for IBM products. A planned operating system upgrade should replace several, but not all, currently held noncompliant products. It was determined that the Year 2000 Program and OS/390 upgrade project team would need to work closely together to accomplish the OS upgrade and Y2K integration testing in a timely manner.
Develop testing strategies for those products vendors have stated are compliant. Ascertaining the state of vendor products as we were from direct vendor replies to our questions, research of vendor-supplied World Wide Web statements regarding Y2K compliance, and in some cases, relying on third-party-published studies still leaves a vulnerability regarding the actual performance of the vendor product. We have determined that at least minimal spot testing of in-house versions of products stated to be compliant is prudent. . . .
Testing. Testing time and effort was underestimated for all pilots. In one pilot, test processes were lacking; for example, system and functional test plans were developed but lacked the specificity required to sufficiently address the Y2K concerns. The addition of tools and training, without effective test processes, would probably not be sufficient to ensure success of the effort. . . .
Every pilot incurred slowdowns and obstacles during the testing phase. As discussed, we discovered that variances in testing procedures within the organization affected attempts to baseline a certification process. Effort expended in defining Y2K-specific testing practices and in building adequate test environments are worth the front-end investment.
|