| The Y2K issue was itself a huge project and drained resources from the IT budgets of most companies, forcing a lot of them to put new developments and projects on hold until all systems and applications were deemed to be Y2K-compliant. Even then, businesses were reluctant to start new developments because of the uncertainty surrounding the millennium rollover. Y2K was unique in that the deadline was immovable , and businesses ran the risk of collapsing if their systems were incapable of functioning correctly. In January 2000, comments in the media suggested that the Y2K issue was a hoax, a no-show, and a waste of huge amounts of money in which contractors and IT specialists effectively took industry for a ride. As a Y2K test environment manager for two and a half years , I believe that without the work done by Y2K programs throughout the world, there would have been serious disruption to businesses and the environment. It should be remembered that Y2K wasn't strictly limited to computer systems and associated software ”there were also components that contained embedded processors, with examples being fire detection systems, intruder detection systems, motor cars , aircraft, process control devices, weapon control systems, and life- sustaining medical equipment. Companies had to investigate these devices and either ensure compliance or have them replaced . People and businesses took the Y2K issue seriously. Dedicated programs of work were initiated, and professional test teams verified compliance. Y2K was such a success because all this was done properly ”it wasn't luck! Y2K also produced a number of supplementary issues: -
The need for better testing ”Y2K testing did not always just reveal noncompliance ; it also revealed other failings within applications. It highlighted the need for a more comprehensive testing strategy, with a test team devoted entirely to the testing process instead of testing as part of the development function. Another important factor was quality assurance (QA) ” specifically , that no one should QA his own work; it should always be done by someone else. These issues were brought to light by the intense testing carried out as part of Y2K. -
A dedicated test environment ”Many companies realized that a completely separate test environment was necessary to carry out compliance testing. It often proved impossible to use development environments because of the regular changing of system dates and the disruption to normal services that this caused. A dedicated test environment has the advantage of being capable of restoring the entire system(s) to a known configuration and state. Before testing each application, the system should be reinstated to ensure that it is clean. This is not an option in a development environment, but it was a significant factor in verifying Y2K compliance. The Y2K-compliance issue made companies aware of the benefits of having a separate, independent test environment. -
Prioritization of applications ”Because of the immovable deadline of Y2K, businesses had to prioritize the applications to be converted, due to the risk of not being capable of completing them all within the time allowed. The focus on business-critical applications made companies aware (indirectly) of applications that were not as critical as previously thought. Indeed, some applications were dropped from service instead of being made compliant. -
Patching strategy ”Companies were forced to review the strategy for applying patches to live systems. A large number of operating systems in use required patches to be applied to the system to achieve Y2K compliance. Some decided to install only the patches that were absolutely necessary; others installed them all. My own recommendations were to install all the patches, after checking that there were no obvious conflicts. The advantage of doing this was that if a patch was released late in 1999, then the systems were in a state of readiness to apply it immediately and would not be missing any dependencies. Also, the issue of support from the vendor was relevant. For example, if a support call was logged because of a problem, one of the first things that would have been asked was to confirm the patch status. It was possible that the resolution of the problem could be delayed while the patches were installed. -
Removal or upgrade of legacy systems ”Old legacy systems and applications that were clearly not Y2K-compliant had to be either upgraded or disposed of. A large number of these systems were still in production because they worked! Y2K focused the attention clearly on these systems, forcing decisions to be made regarding their future. The subject of data migration also arose during Y2K. Vast amounts of stored data had been amassed over the years, so companies had to decide whether to migrate the data to compliant platforms or to risk the data becoming unreadable. Data migration was of magnitude significant enough to warrant entire projects being created to deal with it. Some running systems contained only static reference data, often on noncompliant databases. After the data had been migrated to a compliant database, the legacy system could be switched off and decommissioned. -
An inventory of applications ”The large number of applications that some companies were utilizing meant that a full inventory had to be taken before an accurate assessment could be made of the time needed to achieve full Y2K compliance. It was noted regularly that several different versions of the same application were in production simultaneously , leading to confusion and the potential for unnecessary duplication of effort. An inventory had the advantage of not only cataloging the entire application library, but also assigning a current target version that all users should be adopting. The result was a much tidier application library, tighter version control, and a greatly reduced administration and support overhead. -
Standards awareness ”Standards laid down by various authorities regarding Y2K compliance heightened the awareness of standards in general. Companies were still developing noncompliant applications as late as 1999, mainly because they were not following established standards. The Y2K issue raised the visibility of standards for application development and the importance of adhering to properly defined procedures and conventions. -
Investigation into the application delivery and integration process ”The question of how applications were delivered to the user 's desktop was another fallout of Y2K. Previous methods had been too unstructured, causing unnecessary support and maintenance, with administrators often having to visit each user's machine to install or modify an application. Central delivery of applications was moved up the agenda of priorities as a potential solution to the vast range of software available on different users' desktop workstations. Additionally, companies looked at standard workstation builds so that each user had exactly the same software configuration. Solaris has made this possible by the use of JumpStart, which brings clusters of workstations up to a standard configuration. -
Third-party compliance statements ”The Y2K problem demonstrated that statements of compliance from third-party suppliers were occasionally misleading or incomplete. Some applications were strictly only Year 2000-compliant: I personally came across one application that, when the system clock was set to rollover to 2001, displayed 1901, even though it had worked successfully throughout the year 2000. Technically, it was Y2K compliant in that it would work in the year 2000! Note The vast majority of third-party supplier statements were indeed accurate and comprehensive. The issue stated previously highlighted the need to ensure that the correct questions were asked and that any possible ambiguities or interpretations were properly addressed.
It is interesting to note from this previous list that a number of the items have nothing to do with Y2K, but they were prompted by the sheer scale of the compliance task. Y2K proved to be an excellent mechanism for companies to carry out housekeeping on a large scale ”of course, a further advantage for system managers during this time allowed anything Y2K- related to be charged to a corporate Y2K budget. A large number of companies are in much better shape following Y2K than they were before Y2K. The streamlining that was necessary to complete everything in time has had a much more permanent effect on companies, many of whom indirectly benefited as a result of the whole exercise. |
