Is history destined to repeat itself?
THE APPROACH OF THE YEAR 2000 (Y2K) has firms scrambling to become compliant or at least demonstrate the appearance of being so. Many firms will become completely compliant and will deserve congratulations. Others will become partially compliant and will also deserve kudos. Others will lack any semblance of compliance, but they, too, should be thanked—for demonstrating what should have been done but was not.
Regardless of the degree of compliance, all three categories of firms will have provided some invaluable Y2K lessons to apply to systems development and maintenance that should be remembered throughout the next century There are 10 lessons that business managers in general and information technology (IT) professionals in particular can learn.
1. Documenting systems is absolutely necessary For a long time, IT professionals have recognized the need for documenting the development and maintenance of systems. Yet, as Y2K demonstrates, many systems were either not documented or only partially documented. Worse, many programs even lacked comments in the source code. Even with the advent of “silver bullets” like development methodologies and tools, documentation remains in a dismal state. Y2K only revealed the seriousness of the situation.
2. Building obsolescence protection is necessary. Modern computing is only about a half-century old. You would think that IT professionals and business management would have had the foresight to account for the changeover to a new century in their code. Sadly, there was no foresight or forethought.
Ralph L. Kliem is president of Practical Creative Solutions Inc., a Redmond, Wash., consulting and training firm. He is the co-author of Just-in-Time Systems for Computing Environments [Quorum], The Practical Project Management Methodology [Marcel Dekker], Reducing Project Risk [Gower], and Project Management Practitioner's Handbook.
Y2K is a perfect example of systems development and maintenance rooted in the “here and now.”
3. Applying some type of formal methodology is necessary. The lack of modularity, documentation, and general system understandability revealed by Y2K compliance reflects the need for having a formal methodology to address such deficiencies. This lesson becomes even more imperative as the size of the system and its external interfaces increase.
4. Performing asset management is critical. The mad rush to become Y2K compliant has revealed the extent of self-knowledge firms have about their computing assets, such as quantity and condition. It is fair to say that if Y2K were not approaching, many firms would have no idea of the quantity and kinds of software under their purview.
5. Relying on one vendor is foolhardy. While striving to become compliant, many companies have wondered what happened to all the vendors. Some vendors have fallen by the wayside; others have merged. Whatever their fate, it soon became clear that a Y2K fix would not be coming from a vendor. As a result, many companies are scrambling for a solution that they thought the original vendor would provide.
6. Recognizing that most systems are not islands onto themselves. Y2K has shown that sooner or later systems become interconnected with other systems, especially as the IT environment gets more distributed and decentralized. Client/server and Internet technology have augmented the interrelationships among systems throughout the supply chain in most firms. Y2K compliance efforts have revealed the degree and complexity of their interrelationships once a change is made—a change to code is made to one system and has an impact on others. Clearly, in today's IT environment, no system can operate in a vacuum.
7. Accepting the fact that legacy systems will be around for a long time. Many professionals thought that Y2K would force the development of replacement systems or that vendors would provide new ones. In many respects, that did happen. In other cases, just the opposite occurred—tightened IT budgets, staff shortages, and a narrower window of opportunity to build a replacement system. The result is a frantic effort to make quick-and-dirty fixes to legacy systems, but we won't know if they are effective until sometime in the next century.
8. Understanding that maintenance is your responsibility. As mentioned earlier, many managers are expecting the vendor to provide the necessary fix. This may or may not occur, based upon their legal obligation to do so and the very existence of the vendor. Some firms are outsourcing compliance. Others are building replacement systems. The commonality here is that firms are not waiting for some silver bullet provided by a vendor. They are taking action because they recognize that action can only come from within.
9. Recognizing that systems are an integral part of running a business. Y2K fixes brought the long-awaited appreciation of the strategic and tactical role that IT plays in an enterprise's success. Despite the track record, many executives see IT as a cost incurred to keep the “techies” happy. Y2K has made it clear that noncompliance could bring devastating results to a firm. From the very start of the supply chain to its very end, business can literally grind to a halt.
10. Performing disaster recovery and planning is important. Many firms are realizing that no or inadequate Y2K compliance can cause monumental problems. This situation elevates the importance of disaster recovery and planning. In the past, disaster recovery and planning was one of those nice-to-address-topics-when-time-permits. But time no longer permits—the end of this century and the start of the new one is almost here. When the Year 2000 arrives, firms will know how compliant they really are. Those firms that are fully compliant will likely have a good backup and recovery plan, too; others will not.
THE KEY QUESTION WILL BE, “Did we really learn anything from Y2K?” The words of the famous philosopher-historian George Santayana ring loudly in my ears: “Those who cannot remember the past are doomed to repeat it.” Will future generations of systems developed and maintained during the next century reflect our ignorance and erroneous actions of the past? Will Y3K be a repeat of Y2K? Let's hope that IT professionals and business managers won't find themselves muttering the derivative words of that great baseball player-philosopher Yogi Berra: “It's Y2K all over again.”
Reader Service Number 054
November 1999 PM Network