Chapter 1
Background

Why do I think some of this happened?…I think there was a lack of context given to the Y2K problem. We did a great job of telling everybody that there was a Y2K problem, and we did a terrible job of putting it in context. (AMC/SCA)

The lessons from the Year 2000 (Y2K) are not obvious solutions to straightforward problems, nor are they based on clear choices among distinct options. These lessons generally involve subtle distinctions and the balancing of complex, rational, though often competing, needs and aims. This chapter provides the background and context to help you understand these difficult but critical lessons. It is presented in two parts: (1) a review of the complexities of information and communication technology (ICT) management, for the world in general and for the United States Air Force (hereafter simply USAF, or Air Force) in particular, and (2) a review of the complexities of the Y2K challenge, primarily as a problem to be addressed but also as a research opportunity from which to learn. These areas provide the context for the lessons presented in Chapters 2, 3, 4, and 5: “Managing ICT Complexity,” “Aligning Organizational and ICT Strategies,” “Managing ICT Risk,” and “Technology Risk as a Socially Embedded Issue.”

This chapter does not provide a detailed, chronological account of the diverse and dynamic response to Y2K, which lasted more than five years, either within the Air Force or around the world. Instead, we present numerous response details here and within the discussion of results and lessons learned in the following three chapters. Over the course of this report, you are given a clear picture of the Air Force’s complex Y2K activities within the context of the events occurring around them. For a chronological, top-down description of the Air Force Y2K response, as well as details of the legislation, congressional funding, corporate approach, management structure, and preparation for Y2K, refer to the Air Force Year 2000 Office (AFY2KO) Final Report (USAF 2000). Much of the discussion in the following section (and the lessons learned) is relevant not only to the Air Force or the military but also to a wide range of private and public organizations. It covers general aspects of the ICT world and specific aspects of ICT in the Air Force. It also describes general aspects of the Y2K problem and basic trends in the response to this problem. These trends played out in the Air Force and in the world at large.

1.1
RESEARCH ON Y2K

This report is perhaps the most detailed publicly available case study of the Y2K response in a single organization and the lessons learned from that response. Although a great deal was written about Y2K before the event, surprisingly little analysis was conducted after January 1, 2000 (see Box 1-1). The fact that Y2K did not result in widespread catastrophic failures led many people, particularly those outside the ICT field, to label it a nonevent or a hoax—and doubtless prevented extensive analysis after the fact.

At the same time, the report should be read in the context of the broader field of information systems management, where many of the generic lessons arising from the Air Force experience of Y2K have already been documented in other settings. The



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K Chapter 1 Background Why do I think some of this happened?…I think there was a lack of context given to the Y2K problem. We did a great job of telling everybody that there was a Y2K problem, and we did a terrible job of putting it in context. (AMC/SCA) The lessons from the Year 2000 (Y2K) are not obvious solutions to straightforward problems, nor are they based on clear choices among distinct options. These lessons generally involve subtle distinctions and the balancing of complex, rational, though often competing, needs and aims. This chapter provides the background and context to help you understand these difficult but critical lessons. It is presented in two parts: (1) a review of the complexities of information and communication technology (ICT) management, for the world in general and for the United States Air Force (hereafter simply USAF, or Air Force) in particular, and (2) a review of the complexities of the Y2K challenge, primarily as a problem to be addressed but also as a research opportunity from which to learn. These areas provide the context for the lessons presented in Chapters 2, 3, 4, and 5: “Managing ICT Complexity,” “Aligning Organizational and ICT Strategies,” “Managing ICT Risk,” and “Technology Risk as a Socially Embedded Issue.” This chapter does not provide a detailed, chronological account of the diverse and dynamic response to Y2K, which lasted more than five years, either within the Air Force or around the world. Instead, we present numerous response details here and within the discussion of results and lessons learned in the following three chapters. Over the course of this report, you are given a clear picture of the Air Force’s complex Y2K activities within the context of the events occurring around them. For a chronological, top-down description of the Air Force Y2K response, as well as details of the legislation, congressional funding, corporate approach, management structure, and preparation for Y2K, refer to the Air Force Year 2000 Office (AFY2KO) Final Report (USAF 2000). Much of the discussion in the following section (and the lessons learned) is relevant not only to the Air Force or the military but also to a wide range of private and public organizations. It covers general aspects of the ICT world and specific aspects of ICT in the Air Force. It also describes general aspects of the Y2K problem and basic trends in the response to this problem. These trends played out in the Air Force and in the world at large. 1.1 RESEARCH ON Y2K This report is perhaps the most detailed publicly available case study of the Y2K response in a single organization and the lessons learned from that response. Although a great deal was written about Y2K before the event, surprisingly little analysis was conducted after January 1, 2000 (see Box 1-1). The fact that Y2K did not result in widespread catastrophic failures led many people, particularly those outside the ICT field, to label it a nonevent or a hoax—and doubtless prevented extensive analysis after the fact. At the same time, the report should be read in the context of the broader field of information systems management, where many of the generic lessons arising from the Air Force experience of Y2K have already been documented in other settings. The

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K critical need to align organizational and ICT strategies has been a concern of the information systems community for decades. Box 1-1. Overview of Research and Commentary on Y2K Popular Literature and News Media During the late 1990s, in the run up to the millennium rollover, a substantial popular and business literature on Y2K appeared. Although these sources provide context for the Air Force’s effort to address the Y2K problem, most of this popular literature is not relevant to the issues discussed here. Reporting in the general news media on Y2K was also extensive in the run up to January 1, 2000, along with reporting in the immediate aftermath on the generally smooth transition and the relatively few problems that did occur. American RadioWorks produced a useful retrospective report on Y2K in 2004 (website address provided in the bibliography). Government and Private Sector Reports The efforts of governments, international bodies, multinational corporations, and other organizations such as professional societies were very important to the ultimate success of Y2K remediation and contingency planning. One prominent example is the President’s Council on Year 2000 Conversion. The regular status reporting of federal efforts by the General Accounting Office is also a valuable resource (GAO 1997, 1998a, 1998b, 1998c, 1999). These reports provide information about the extensive efforts undertaken across the U.S. government to coordinate remediation efforts across agencies. The efforts of the Department of Defense and the military services, in particular, complemented efforts of the Air Force as described in this report. In 2000, GAO performed a top-down, retrospective evaluation of Y2K. One of GAO’s main recommendations—that the capabilities created within and across organizations to deal with Y2K should be leveraged to address other ICT risks—is consistent with this report. In a retrospective report for the Office of Science and Technology Policy, Mussington (2002) examines efforts to address Y2K and the implications for research and development in the area of critical infrastructure protection. Mussington’s focus on the interactions between organizations and the broad ICT infrastructure complement this report’s findings drawn from the examination of a single enterprise. Mussington also emphasizes the importance of decentralized information-sharing efforts that crossed organizational and national borders. Academic Literature The existence and functioning of ICT systems in their social and organizational contexts raise a number of research questions and issues that are interdisciplinary in nature and, taken together, might be termed “social informatics” (Kling 1999). This field has a long history (Kling and Scacchi 1982). The conclusions of this report are broadly consistent with this literature, work from which is selectively referenced. Journal articles in management, information systems, and software engineering contributed perspectives to Y2K planning or drew lessons from the experience after the fact. The Journal of Clinical Engineering, for example, which deals with medical equipment engineering, devoted most of its July-August 1999 issue to Y2K preparation, including case studies of particular health care institutions (for example, Mercado 1999). Information Systems Frontiers devoted its August 1999 issue to exploring the ethical, legal, and risk management aspects of Y2K. Included in this issue is a very useful piece on how to leverage capability created to address Y2K in the service of ongoing ICT management tasks (Isaacs 1999). In the September-October 1998 issue of the Journal of Software Maintenance: Research and Practice, Marcoccia provides a case study of how one organization built infrastructure to effectively deal with Y2K.

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K In contrast to what appeared before the Y2K rollover, retrospective, objective analysis of organizational responses to Y2K has been more limited. One exception is an article in the September 2006 issue of Management Science that shows how companies that invested heavily in ICT in advance of Y2K were better positioned to take advantage of e-business opportunities following the rollover than were companies that invested less (Anderson et al., 2006). 1.2 ICT GENERAL BACKGROUND In March 2000, after a day of Y2K interviews at Scott Air Force Base, the National Research Council (NRC) research team met with the commander of the 375th Air Wing for a briefing. As the team settled in, the colonel pointed across the street and described some problems he was having with a roof repair that had resulted from a construction project that did not meet code. He explained how the project funding complicated the situation: there were three or more groups involved, and it was not clear who was responsible for addressing the code problem. As with the roof repair, funding issues had a significant impact on ICT systems on the colonel’s base. However, the roof was a physical object whose use was visible and therefore obvious, and the components of the roof that did not meet specifications could be observed. Moreover, changes to the roof across the street would not affect all the other roofs on the base. With the ICT systems, it was far from obvious where a given system was located, where it began and ended, and even what it consisted of. In addition, it was far more difficult to identify the things that needed to be checked or repaired, or how those repairs would impact other ICT systems on the base. It was not even clear who was using an ICT system and what they were using it for. Funding is only one of numerous complexities that greatly complicate management issues in the ICT world. Following is a discussion of some of the most important of these additional ICT complexities. 1.2.1 ICT Is Pervasive Another complicating factor…is the very pervasiveness of information technology. Practically everybody in the Air Force has a computer…that is connected to a network from which they access information from everywhere in the world, and most people tend to take a somewhat parochial view of it. … So determining who actually is responsible for taking care of the various pieces of information technology can be a difficult and sometimes challenging process. (AMC/HQ) ICT is everywhere, yet it is nowhere in particular. Most people work with only a small piece of the overall system. Because the information they receive from this system is essential to their work, people usually seek to maintain some control over their piece. Yet when problems such as Y2K occur, pervasiveness can work in reverse. Rather than seeking to control their piece of the system, people view others as responsible for addressing an issue that exists only partially in the environment they control. The pervasiveness of ICT can create confusion not only for system users but also for policy makers and managers. Who owns what, and how do one manager’s actions affect another’s? Who is responsible for the network? For firewalls? For operating

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K environments? For data? For information in electronic form? For work practices and measures of success? For ICT policy and long-term strategy? Uncertainty in these areas can lead to multiple lines of guidance and authority. “IT is too available and redundant. There are too many ways to be tasked. Too many parallel worlds” (374th AW/XP). The pervasiveness of ICT makes it more like an environment than a discrete machine. 1.2.2 ICT Is Multipurpose ICT is both pervasive and multipurpose. Within an ICT system, it is not obvious who is using it or what they are using it for. This is true at many levels of the ICT system. At the content level, for example, designers of electronic information are keenly aware of the potential for multiple uses. “A wide variety of users can access a hypermedia with different purposes; thus, it is important to have different task models for different types of users” (Paterno and Mancini 1998). Since different people can use the same system for different purposes, even dedicated and intelligent people who share the same overall strategic objective can disagree on the basic priorities for design and use of an ICT system. The honest differences that can exist over what constitutes the best ICT system extend beyond use and content design to management issues at many other levels of the system. At the operating environment level, for example, features that make ICT systems easier to field and maintain may at the same time make them more difficult to protect from outside threats. Compare the following statements: We need to do a lot of work on…common operating environments. Because we are finding out that servers have different disk drives on them, different versions of Oracle, different versions of the operating system. And as a result of that we can’t distribute software in a rational manner. (SSG) From the information warfare perspective, diversity is not such a bad thing. If every piece of software is absolutely standardized, one hole gets you in everywhere. When an adversary has to figure out which executable is on which computer among 1,300 possible options, that makes his targeting problem hugely more difficult. (AF/XOIWD) Just as end users have honest differences of perspective on the most desirable features of an ICT system, so do managers and ICT professionals. 1.2.3 ICT Elements Are Diverse and Often Dynamic As the previous section mentioned, ICT infrastructure consists of a wide diversity of levels and elements, each with unique attributes and issues. Even a narrow view of these system elements includes such diverse elements as computer hardware, communication devices, operating systems, application software, and data and database management systems. A fuller view of the ICT infrastructure, however, includes even more diverse elements, such as ICT policies and best practices, relevant personnel and job categories, training and continuity plans, consequence management, security and information

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K assurance strategies, funding mechanisms, and the organization’s culture of communication. System elements differ in many ways. One significant difference is in their rate of change. Hardware and operating software change at a tremendous rate, driven by a dynamic information technology (IT) industry that lives off rapid innovation and accompanying sales. However, as the Y2K situation highlighted, data and databases change only with tremendous effort, if at all. Meanwhile, such complex interdisciplinary elements as ICT funding mechanisms and an organization’s communication culture may extend beyond a given organization’s control or have a life of their own. Thus, diversity and change are ongoing ICT issues. Each [personal computer] has its own distinct version [of the operating environment]. If you compare what you have versus someone else in the office, you’ll find out they are different. …And in fact if you made them the same, your machines will not always work. Because if you buy your machines at different times—different times is just months apart—from the same vendor configured with the same basic software, they will have changed to a new version of the BIOS (Basic Integrated Operating System) and they will have incorporated whatever is the latest in terms of the dynamic libraries and so on. That’s the industry and that’s the realm we’re in. (AMC/SCA) While this statement is about one small element of the overall ICT infrastructure (personal computer [PC] platforms), it gives a good sense of the tremendous impact of diversity and change, particularly as driven by the IT industry. ICT diversity and change issues involve organizational as well as system elements. Different units within an organization generally experience different rates and directions of change, often driven by differing functions and goals. For example, “AMC is usually much better organized about their information technology than ACC…because AMC is information or commission driven. AMC is constantly deployed…ACC is getting better” (AFCIC/SY). Diversity and change issues at the system and organizational levels play important roles in the forthcoming discussion of lessons learned from the Y2K experience. 1.2.4 Traditional IT Is Less Reliable than Traditional Infrastructure The Air Force is familiar with high-reliability software such as that used in avionics systems. However, this high reliability comes at a great cost that is not compatible with the economics and pace of the mass-market software industry. For a number of reasons, high-reliability software is the exception rather than the rule. There is a much higher likelihood of error and downtime in the logistics software that tracks cargo than in the planes, trucks, runways, and roads that actually move it. A key reason for this is that software in general, and commercial off-the-shelf (COTS) software in particular, is not really engineered, at least not in the way that engineers design, build, and maintain traditional infrastructure. Software development tends to have more in common with art than with engineering. As a former Microsoft vice president said, “Programmers are like artists. …It’s like a play—there’s motion, things work, it’s not static. You know where you’re going. …Things just flow” (Corcoran).

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K However, it would be unfair to simply blame programmers or profit-driven software companies for the reduced reliability of ICT systems. These systems are incredibly complex and, in some cases, perhaps the most complex entities ever created by human beings. They can develop a life of their own and evolve in ways that resemble the evolution of any complex organism. History books indicate that the infrastructure for the industrial revolution took 300–500 years to fully develop. We are about 50 years into the information age, so these systems are still not fully understood and developed. Whatever the cause, the end result is that users must learn to adjust to a lower level of reliability from their ICT systems than from the power in their buildings and the sound in their telephones. Managers, too, need to distinguish between the reliability of their traditional infrastructure and that of the new information infrastructure. As an Air Force software manager put it, “We don’t have any programs that don’t have something wrong with them.” During Y2K the lower reliability of information infrastructure as compared to traditional infrastructure led some people to see a need for new and different organizational tactics for developing, operating, and maintaining ICT. “The same system is used for buying planes and tanks as is used for buying IT and software. But IT is more difficult to manage. The development, operation, and maintenance modes are more difficult to determine for IT and software” (AMC/SCA). Many of these management difficulties stem from interdependencies among elements of ICT. 1.2.5 ICT Elements Are Interdependent The considerable complexity of ICT stems, in part, from its ubiquitous and multipurpose nature, the diverse perspectives of ICT users and professionals, the diverse elements that constitute ICT systems, and the ways in which those elements are developed and evolve. Yet, probably the most complex and confounding aspect of ICT is the extensive interdependency of the various system elements. ICT interdependency issues are manifested at many levels, from the compatibility of hardware and software to the highest levels of intersystem interaction. This highest level of ICT interdependency is often called the “system-of-systems” perspective. From this perspective, any given system can be seen as being composed of other interdependent systems and being a part of still others. Interdependency at the system-of-systems level often extends beyond any given organization (not just users or units). Therefore, this is an extremely difficult perspective for an individual or organization to maintain on a daily, operational basis. For instance: We treat our systems today…on a system-by-system basis and usually not on a system-of-systems or mission basis. And so there are disconnects, not necessarily within…any one system, but where it affects the system of systems. …We really don’t understand the configuration of our system of systems. That problem is exacerbated by the way systems are viewed and, more importantly, by the way systems are funded. They’re funded individually as a system and so there is no real impetus to look at it as a system of systems. (MSG)

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K As with the 375th Air Wing’s roof repair, funding contributes to management difficulties, but with ICT the funding issue is interwoven with numerous other complexities, such as those presented here. ICT management is a special challenge, and there is no magic formula for any given organization to meet this challenge. That is because in addition to general ICT complexities, each organization must consider unique issues that are intimately connected to its particular mission, strategic objectives, environment, and culture. For this reason, it is particularly helpful to continue the ICT background within the context of a specific organization. As faced by the Air Force, the ICT management challenge is particularly illustrative and intriguing. The Air Force is a large, multifunctional organization that relies heavily on its new information infrastructure to accomplish a complex global mission. It has particularly high requirements for ICT flexibility, security, and information assurance. The following focus on the USAF is intended to make this discussion of particular use to that organization. However, the availability of the Air Force’s experience with Y2K also increases the value of this work for anyone interested in strategic ICT management. 1.3 United States Air Force ICT Like any modern organization, the Air Force must meet the general challenges of managing its ICT resources within the context of more specific challenges associated with its unique mission, strategies, and organizational environment. For the Air Force, these more specific ICT challenges stem largely from the nature of its mission and functional objectives heightened security and information assurance considerations particular organizational makeup, establishment of policy, and decision-making practices special personnel and training issues large size and geographical dispersion 1.3.1. Mission and Functional Objectives The current Air Force vision for its national security mission is closely tied to successful management of its ICT assets. “Information superiority” is a central building block of this vision (USAF 2000b). Leadership recognizes that successfully managing ICT and related interdependent systems means establishing, maintaining, and evolving a general, flexible capability rather than achieving a specific objective. We have been thinking a lot about the future of the Air Force in the twenty-first century. The next two decades will present many unknowns. Our challenge will be to create a system of integrated aerospace systems that will be able to meet the full spectrum of future national security requirements—without being able to predict today precisely what those requirements will be. (Peters 2000)

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K To accomplish its mission of readiness in the face of uncertainty, the Air Force must maintain a multifunctional organization. ICT and the information it provides are critical to almost all of those functions. Perhaps most obvious is the actual combat activity. “With advanced integrated aerospace capabilities, networked into a system of systems, [the Air Force will] provide the ability to find, fix, assess, track, target and engage anything of military significance, anywhere.… Information superiority will be a vital enabler of that capability” (USAF 2000b). Less visible but more complex to manage are the wide range of Air Force logistic and support activities. These have always been vital activities, but they are becoming even more critical and complicated with the Air Force restructuring around an expeditionary force concept. Aerospace Expeditionary Forces (AEFs) present numerous advantages for readiness and rapid deployment, but support capabilities are not organically assigned to these forces. In the logistics area, this means an even greater reliance on ICT systems for flexible, just-in-time support activities. “Effective, efficient logistics will be key to sustaining expeditionary forces. [The Air Force] will harness information technology, rapid transportation and the strengths of both the organic and industrial logistics base to ensure responsive, dependable, precise support” (USAF 2000b). However, logistics systems (an increasing number of which are COTS) are not engineered to the level of reliability of avionics or special purpose weapons systems (see Section 1.1.4). This further complicates the challenges faced by the people and units who field, use, and maintain Air Force logistics and support systems. AEFs may present special considerations that make Air Force logistics ICT particularly challenging, but the logistics challenge is shared by all the military branches (as well as any organization that incorporates just-in-time delivery into its operational and information strategy). For example, a recent Pentagon study of the Gulf War revealed the need for faster ways of deploying Army logistics and support units. Logistics was “hard-pressed to keep up with the rapid pace,” and if victory had not been so swift, “maneuver forces would have outrun their fuel and other support” (Rosenberg 2001). ICT is the backbone of the effort to rapidly deploy logistics support. Despite the many challenges associated with achieving and maintaining information systems that are reliable, timely, flexible, and secure, the national security mission of organizations like the Air Force leaves little margin for error. It's all about information. The need to provide war fighters the information they need—information they can trust—is a key component of the Expeditionary Aerospace Force concept. How effective we will be in the future is derived from our ability to rapidly collect, process, analyze, disseminate, retrieve and protect information while denying these capabilities to our adversaries. (Commander AFCIC, reported in USAF 2000c) Therefore, the conduct of information warfare, both defensive and offensive, is a unique part of the Air Force ICT management challenge.

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K 1.3.2 Security and Information Assurance The critical value provided by Air Force ICT systems comes with an accompanying serious risk. Military operations today are heavily dependent on globally shared critical infrastructures. Technological advances have interconnected these infrastructures, better enabling mission accomplishment anywhere in the world. While this connectivity better enables mission accomplishment, it also increases our vulnerability to human error, natural disasters, and physical or cyber attack. (USAF 1999a) While this statement focuses on the communications component, the recognition that increased complexity leads not only to increased mission capabilities but also to increased risk holds for all of ICT’s many diverse elements. Incompatible data or ineffective practice can lead to mission failure as quickly as bad communications, as the lost Mars Climate Orbiter vividly demonstrated. A wide range of issues is associated with ICT risk, including risk to systems from the outside and risk from internal system complexities. As a military organization, the Air Force must address intentional threats stemming from the deliberate acts of people intending to harm Air Force information capabilities. These threats may be physical (for instance, destroying communication lines) or may occur in cyberspace (for instance, denial-of-service attacks), and they may arise from the political motivations of an enemy state or simply the adolescent demonstrations of a hacker’s ability. These security issues are generally covered under the term critical infrastructure protection, or CIP (EOP 1998a). For the Air Force and other high security organizations, there is a special challenge to maintaining secure operations while simultaneously achieving the full capabilities of ICT systems. The functional strength of modern ICT systems often depends on an environment where information flows freely, fostering the innovative combination of data from disparate sources to create new information value. Security and CIP considerations generally run counter to this functional ideal: “The tension is between continuing IT management for usability and not giving your adversary the keys to your kingdom” (AF/XOIWD). To take advantage of its ICT assets, the Air Force must link people, units, and their systems, both within and outside the service. These linkages introduce security concerns, but they also introduce another critical class of ICT risk. This second class of risk stems not from the intentional actions of an adversary but, rather, from the very system complexity and interdependency required to accomplish the mission. As stated earlier, most people see and touch only a small piece of the overall system. This means that as people and systems are increasingly linked, they can increasingly do things that, while sensible from their perspective, may have unintended impacts on others or the mission. These impacts may not be felt immediately, but they may play out over time and in concert with a sequence of other actions and modifications. Y2K is a member of this class of systemic problems (as was the loss of the Mars spacecraft mentioned earlier). There are clear differences between security and systemic issues. While security focuses on outside threats to functionality, systemic risks are often an aspect or cost of that functionality. While security involves deterrence of an outside adversary, addressing

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K systemic risks involves effective management, communication, and coordination among those within the system. For this reason, some people see these two classes of ICT risk to be distinct, even competing, priorities. Despite these differences, systemic and security risk share important commonalities. Specifically, systemic risk represents weak points in the system that can be exploited by those seeking to do harm. In addition, efforts to make ICT systems more robust through improved continuity and consequence management must consider both types of ICT risk. Perhaps most importantly, efforts to increase confidence in the output of ICT systems, often called “information assurance,” must consider and even integrate both security and systemic risk since the causes of data and information corruption are both intentional and unintentional. As discussed in Chapter 4, there are lessons from the Air Force Y2K experience not only for general information assurance efforts but also for addressing ICT security issues. 1.3.3 Organization, Policy, and Decision Making Where are the organizational homes of Air Force ICT, and how do they contribute to policy and practice? Air Force leadership recognizes the importance of these and related issues that constitute part of the extended ICT infrastructure: “We will ensure [that] technological innovations continue to be accompanied by innovations in doctrine, organization, and training” (USAF 2000b). Achieving this vision, however, will not be easy. The complexities of Air Force organizational structure and of ICT can greatly complicate organizational and policy issues. The Clinger-Cohen Act of 1996 called for each federal agency to designate a Chief Information Officer (CIO) with three general responsibilities: providing advice and other assistance to the head of the executive agency and other senior management personnel of the executive agency to ensure that information technology is acquired and information resources are managed [appropriately] developing, maintaining, and facilitating the implementation of a sound and integrated information technology architecture for the executive agency promoting the effective and efficient design and operation of all major information resources management processes for the executive agency, including improvements to work processes of the executive agency. (IMTRA 1996) While, in one sense, final responsibility for ICT policy and practice lies with the CIO’s office, the language of the act is focused on advising and improving the executive agency. In a large and diverse organization such as the Air Force, there is a wide gap between the executive agency and the distributed, frontline operational management and use of ICT. In addition, the act’s language about technology acquisition and architecture may not be interpreted as including responsibility for more human issues such as best ICT practices and alignment between ICT management and organizational strategy.

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K During Y2K and as of the writing of this report, the Air Force CIO’s office was divided among the Secretary of the Air Force and Department of the Air Force, the CIO in acquisitions (SAF/AQ), and the Deputy CIO in communications (HQ/SC). Units under acquisitions and communications, with a central focus on ICT, include: the Electronic Systems Center (ESC) and (under ESC) the Standard Systems Group (SSG) under AQ; the Air Force Communications Agency (AFCA) and the Air Force Communications and Information Center (AFCIC) under SC. Additional background for non–Air Force readers will help them understand the lessons-learned sections. At the operational level, the Air Force is organized into nine major commands (MAJCOMs). Seven of these are functional (combat, space, mobility, materials, special operations, education and training, and reserves) and two are geographical (Europe and the Pacific). ESC and SSG are under the materials command (AFMC); AFCA and AFCIC are attached directly to HQ/SC. Another unit with particular focus on ICT is Information Warfare Defense (IWD), which is attached directly to operations in headquarters (HQ/XO). Bases are attached to MAJCOMs and can house various tenants. For example, AFCA is a tenant at Scott Air Force Base (AFB), which is attached to the mobility command (AMC), while the 630th Air Mobility Squadron is an AMC tenant on Yokota Air Base in Japan, which is attached to the Pacific Command (PACAF). Base tenants may also be joint command units that serve the combined military services; for example, Scott AFB houses the U.S. Transportation Command (USTRANSCOM) and Yokota AFB houses the headquarters for joint services in Japan (USFJ). CINC refers to combined service units or operations under the Commander in Chief. The overall Air Force management strategy can be summed up as centralized management with decentralized execution. In practice this means that central guidance from Air Force headquarters is interpreted by each MAJCOM for its particular functional situation. This continues down the line as bases receive guidance from their MAJCOM or a headquarters unit and interpret these orders for their local situation. The goal is a single point of contact (POC) for any given activity. But as this brief overview of relevant Air Force units implies, a single POC can be difficult to achieve for cross-functional activities such as ICT. At times it is not easy, even for those directly responsible, to explain precisely where Air Force ICT policy resides within the organization and how it actually is managed. For instance, during the Air Force Y2K Lessons Learned Workshop, the facilitator asked, “Who sets IT policy, for example, the creation of a certificate to operate?” Because each participant’s response was different, the conclusion was that “the answer is very complicated” (AFCA). Specifically, “where the policy starts and who owns it are two different things” (SSG), “especially when an organization always operates across boundaries” (AFCA). The cross-functional nature of ICT makes it particularly difficult to manage within an organization that is primarily organized along functional lines. Funding is another complicating factor in Air Force ICT organization and policy management. The funding necessary to implement system modifications does not generally accompany the central guidance calling for those modifications. This issue is further complicated by the fact that changes to ICT systems do not occur in isolation. Rather, they require that an appropriate infrastructure be in place. This infrastructure

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K 1.3.5 Geographic Dispersion A final important set of Air Force ICT issues stem from the wide geographical dispersion of units and systems. These issues include important differences between the ICT situation at continental United States (CONUS) bases and at outside the continental United States (OCONUS) bases. Many differences between CONUS and OCONUS ICT are the result of general differences in non-ICT areas, such as organization, mission priorities, and dependency on local foreign infrastructure. CONUS bases are attached to functional MAJCOMs, while OCONUS bases are attached to geographical MAJCOMs. This does not mean that the functional activities represented by the MAJCOMs do not occur on OCONUS bases. It does mean, however, that tenant functional units on OCONUS bases may be treated differently from their CONUS counterparts. There may be funding differences, or, as occurred during Y2K, functional MAJCOMs reaching out to their bases may reach only to the CONUS level. In the ICT realm, these organizational differences can significantly impact the effect of central guidance, for example, efforts to establish common operating environments and to clear POCs and lines of authority. “The A[ir] F[orce] is moving towards having one IT [organizational structure]. The CONUS IT structure looks like the AF wants it. The OCONUS IT structure falls under the host unit” (AMC/SCP). In the ICT area, OCONUS units tend to have greater local autonomy than CONUS units, and this can lead to an even more idiosyncratic ICT infrastructure. Because they are geographically and politically separated, OCONUS ICT personnel face additional challenges to fielding and maintaining state-of-the-art systems. There can be an almost rural aspect to OCONUS bases. Training is more costly and difficult to obtain, funding may be more difficult to obtain, and existing base infrastructure may be less up to date. “We’re at the end of the…chain. Our computer systems are way behind those at stateside bases” (374th AW/CS). Some of this difficulty is mission related. Being closer to the front lines, Air Force personnel at OCONUS bases see themselves as under greater operational urgency, with an accompanying reduction in time and attention for what can be perceived as secondary activities. “Operationally, a CONUS base is not that close to the enemy. The sense of urgency is greater at an OCONUS base because there is less time to do things, such as inventory” (374th AW/XP). In an OCONUS environment, ICT security issues are also complicated by geographical and political separation, which may mean less attention and fewer resources for other aspects of system maintenance and evolution. Some OCONUS ICT challenges stem from base interdependencies with the local infrastructure of a foreign country. It is much easier to interact with the state government of Illinois, for instance, than with the government of Japan or Korea. Interdependencies with foreign systems most obviously involve power, transportation, and other traditional infrastructure elements, but technical elements of the ICT system itself can be affected as well. For example, in Japan, personnel cannot use the handheld scanners other bases use because they cannot get a frequency assigned (630th AMSS). Some of the most difficult challenges for an OCONUS base involve cultural and political differences with the host country. These were especially visible during the Y2K experience and are discussed, along with other CONUS/OCONUS issues, in Chapter 3.

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K 1.4 The Y2K Challenge Just as ICT systems are complex, so was the challenge presented by Y2K. During Y2K there were a variety of perceptions as to what was occurring, and after Y2K the variety of perceptions persisted. To many people, Y2K was a pervasive threat to all ICT activities, with a firm deadline for averting that threat. “The difference between Y2K and normal day-to-day operations and software roles was that Y2K presented a problem that was going to affect everybody at the same time, whereas in the day-to-day world, random problems affect different people at different times” (MSG). To others, Y2K was more like a heightened state of the usual ICT activity. “These problems were not unique to Y2K. …They exist as part of the normal information technology day-to-day business. They just became more obvious under the intense spotlight that we saw with Y2K” (AMC/HQ). Whatever the relationship between Y2K perceptions and realities, efforts to address Y2K challenged organizational ICT management in ways that it had never been challenged previously. For the Air Force, it was the equivalent of a test flight of their evolving prototype system for strategic and operational ICT management. To understand the lessons of this unique test, it is necessary to better understand the Y2K challenge itself. 1.4.1 The Y2K Problem In Uruguay in the late 1960s, power engineers had trouble managing their power output, in part because of uncertainties in the water levels and flow of the river on which the power depended. They decided to write a software program to help predict river flow. In the Montevideo city records, the engineers discovered a wealth of historical data on river levels, weather conditions, and so forth, dating back to 1890. Unfortunately, their database used just two digits to represent the year. If they did not want to discard a decade of useful data, they needed a way of using two digits to distinguish between the years that began with an “18” and those that began with a “19.” They did this using a coding scheme (for example, 01 = 1890) and created a useful predictive tool. Then they went about their business of power production and management. The point is that in the late 1960s in Montevideo, Uruguay, a group of power engineers faced and addressed (for their situation) an instance of what, three decades later, came to be called the Y2K problem. In this case, it had nothing to do with the year 2000 or the closing seconds of a passing millennium. However, as with Y2K, it had everything to do with a range of dates that crossed a century barrier (in this case, the 19th) and a date representation scheme that used only two digits because it (incorrectly) assumed the two digits were preceded by 19. Despite the hundreds of billions of dollars spent on the problem and intensive media coverage of it, Y2K was a highly misunderstood event. Much of the misunderstanding stemmed from the popular linking of this event with the new

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K millennium. Such names as “The Millennium Bug” and “The Year 2000 Problem” were misleading, since they incorrectly implied a single, once-every-thousand-year event occurring at a specific point in time. People pictured a time bomb ticking away within computers and other date-dependent machines. Whatever the accuracy of these perceptions, they became an important aspect of the Y2K challenge. The omission of the century digits in the representation of a year was neither unusual nor tied to technology. People always rely on assumed knowledge in the representation and interpretation of dates and time. For example, in the United States the date “10/02/00” is October 2, 2000; in other countries, it is February 10, 2000. To know what 10/02/00 represents, you need to know the country you are in and the schema that country uses to represent day, month, and year. To know what date is referred to in the phrase “The Spirit of ’76,” you need to know something about the American Revolution. Humans created computers, and humans working around the middle of a century did not see the need to keep repeating the obvious century digits. As introduced in Section 1.1.3, an ICT system comprises a wide diversity of elements. Because dates can occur within any of these elements, Y2K was actually a set of different potential problems (see Figure 1-1). For example, such system elements as chips and operating systems are concerned with system time (that is, What time is it now?). These elements might experience a Y2K problem when “now” changed in such a way that the assumed 19 was no longer correct, that is, when 1999 rolled over to 2000 (namely, midnight December 31, 1999). However, system elements such as applications and databases are concerned with functional time (that is, What time range do I need to understand to conduct my business?). These elements might experience a Y2K problem whenever they needed to process a date that crossed the century barrier, whether that date was in the future—as with projected cargo scheduling—or in the past—as with the power engineers in Montevideo. Figure 1-1. System Layers and Y2K Problems

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K The most difficult of the set of related potential problems that were called Y2K was concerned with sharing data among interdependent systems. This was especially true when those linked systems resided in different units, organizations, or even countries. In this case, the source of the date misinterpretation could reside not within any of the individual systems but between them. Since data shared between systems could include dates, what was correctly understood by one system might be misinterpreted when translated by another. Even more problematic, a change in date representation by the maintainers of one system, perhaps in response to a Y2K issue, could result in a problem within another system, even though there had been no previous problem with that system and nothing within that system had been changed. The only sure solution was careful understanding of and coordination across the system of systems. (The Mars Climate Orbiter failure, which resulted from the different interpretation of distance data across systems created by two different organizations, was similar to this type of Y2K problem.) These and other complexities of the Y2K problem were not always understood. It was particularly difficult to craft a response that discriminated among the different types of Y2K problems, especially within the context of ICT management complexities and perceived insufficient time and resources. The following section provides a brief overview of various trends that played out over the course of the Y2K response period. 1.4.2 Y2K Response Trends During the multiyear period during which organizations and governments were recognizing and responding to the Y2K challenge, the problem changed in several ways, in terms of both general perceptions and response strategies. Four significant trends could be seen in the world at large and in the Air Force in particular. There were shifts in focus from: (1) computers and ICT to chips and traditional infrastructure, (2) a technological to a mission perspective, (3) fixes to continuity planning, and (4) technology to political and legal issues. 1.4.2.1. From Computers and ICT to Chips and Traditional Infrastructure For decades, selected computer professionals had recognized two-digit years as a potential problem. On January 27, 1988, the Federal Information Processing Standards (FIPS) Publication (PUB) 4-1 superseded the FIPS PUB 4, which had been established on November 1, 1968. The new FIPS PUB 4-1 stated that “for purposes of electronic data interchange in any recorded form among U.S. Government agencies, NIST [National Institute of Standards and Technology] highly recommends that four-digit year elements be used. The year should encompass a two-digit century that precedes, and is contiguous with, a two-digit year-of-century (for example, 1999, 2000, etc.).” Why the previous FIPS PUB 4 had specified a two-digit year is part of another story. What is important here is that more than five years before most

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K organizations—including the Air Force—had a formal Y2K program, the issue had been clearly identified, at least as a need for a four-digit standard for date representation when sharing data. For most organizations, however, the cost of adjusting their data (and therefore the databases and processing software and the systems that shared the data) seemed to far exceed the threat. Generally, computer professionals working on specific systems first brought to light the urgency of the two-digit date issue (at least in their immediate environments). In the Air Force, this happened in late 1993 at Cheyenne Mountain and again in early 1995 with the Airborne Warning and Control System (AWACS). As computer professionals recognized the complexity of changing what had been a widespread data standard, they were forced to seek additional resources from managers who neither understood the problem nor saw an immediate benefit to the bottom line or mission in addressing it. In 1995 at the Air Force level…there were three people working the issue…from the point of view of [researching] what industry was saying about it; not from what the Air Force mainly had to do. … We felt [as if] we were vacuum cleaner salesmen. …[We would say to leadership] “We’ve got a problem here and this is what the problem is.” And most of the leadership [viewed it as just] another program to throw on the burner. …It took quite a while, even within the SC community, to raise it to a level of the number one [issue]. … It was a very interesting mushrooming experience all along. (AFCA) As awareness increased and the search for potential date-related problems gathered momentum, people realized that dates existed at many levels of the system, all the way down to hardwired dates on computer chips. The chips issue seemed particularly compelling: they could not be fixed, only replaced, and there were so many of them. The tiny time bomb, hidden in any machine with a date component, became the image of Y2K for many people. In the first half of 1996, the Government Reform and Oversight Committee and the Science Committee began a joint review of the “Year 2000 Computer Problem,” but by mid-1997 the focus was already shifting beyond the computer to a more traditional infrastructure. In her opening statement at a joint hearing on July 10, 1997, Chairwoman Constance Morella listed four specific concerns, the fourth being “that inadequate attention government-wide is being paid to other date-sensitive systems, such as the embedded computer chip problem.” The media in particular was attracted to this issue, and soon these “other” systems became the major focus for many IT people, particularly those at the facilities level. For ICT professionals this was a double-edged development. On the one hand, major attention was brought to the Y2K problem that might otherwise not have occurred. On the other hand, the focus on a more traditional infrastructure could be a major distraction from what they viewed as the central data issue. In August 1998 the first guidance was to look at computer-type equipment. …Three months later there was a shift from looking at interfaces to opening things up and looking for chips. …Not only did it increase workload but [also] it was another realm. (AMC/HQ) The chip was the focus. …When we shifted away from the IT side…we put everything on the inventory that could possibly have a date problem with it. We had the traffic lights on

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K it. We had railroad crossings outside the main gate. “Are the bars going to come down?” They had to test for that. (375th AW/Y2K) Generals had questions about embedded chips from what they had seen on 20/20, 60-Minutes. …That’s what increased the workload—these kinds of external factors coming in. (AFCA) There needs to be a difference between IT and [traditional] infrastructure in the way they are handled. …There are 1,000 times more infrastructure items. AMC units were advised to let the bases worry about the infrastructure. (AMC/HQ) The ICT-versus-chip issue is relevant to a number of the lessons learned presented in Section 2.5. 1.4.2.2. From a Technological to a Mission Perspective Even as the increasing focus on chips took the Y2K response deeper inside the machines (though away from ICT), another trend was taking the Y2K response away from the technology itself and toward the organization and its mission. In part, this occurred because Y2K was getting too complicated for any one functional area, including the computing and communications people, to handle. We started out doing business as usual. “It’s a COMS problem. Let the computer people deal with it.” And as gradual knowledge came in of just how big this thing was turning out to be, we then started getting more people on-line and eventually we got operations to …look at it as an operational type of problem. (AMC/HQ) Many computer professionals backed away from Y2K as their problem. They did not see it as being primarily about their systems (that is, computers and how they operated or were connected). Instead, many computer professionals saw Y2K as being about operational data and how it was stored and used or about chips in cars and alarm systems or about legal and political issues. To some people, this was an unexpected narrowing of the computer community’s field of responsibility. For instance, “As we went through the Y2K process, I found that the original owners of equipment or policy or procedures or issues within the COM community were backing away from what I saw as their area of expertise. Once Y2K came into place, they stepped back from the area they were working on or their area of responsibility” (375th AW/CG). Additional impetus for the shift from a technological to a mission perspective came from political and legal pressures (see Section 1.3.2.4.). “Prior to the Air Force Audit Agency coming through, it was a COMS squadron problem; after the AFAA came through, it was an operational problem because that’s what the AFAA highlighted” (374th AW/CS). Perhaps most importantly, the shift from a technological to an operational perspective occurred as part of a learning process. In response to the Y2K threat, more people than ever before were forced to face the complexities of ICT and the ways it is increasingly interwoven into the accomplishment of an organization’s mission. Initially, most organizations attempted to address Y2K through a “technology first” approach. A

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K typical first step was to conduct an inventory of all information and communication technology with the goal of determining whether that technology was Y2K compliant or not. However, the limitations of this approach quickly became clear. For example, identifying all the ICT that was used in a large organization was no trivial matter, and even more difficult were complications of system complexity and ownership and responsibility for compliance. Who says whether it’s compliant or not? If it wasn’t owned by the Air Force, we called the vendor. …We have stacks upon stacks of compliance data from manufacturers. And they all say the same thing on the very bottom, “This is just what our compliance testing has proven. We in no way confirm that this product will continue as functional after the rollover.” (375th AW/Y2K) As the required testing phase approached, the impossibility of testing all systems for all possible glitches became increasingly clear, and operational test boundaries became necessary. Given these issues, most organizations changed from a technical to an operational perspective over the course of their Y2K efforts. Instead of asking what technology they had and whether it was at risk, they asked what the critical activities of their organization were and what the role of information and communication technology was in those activities. Instead of placing a technical person in charge of Y2K, they placed an operating officer. By early 1999, as stated in the Air Force Assessment Master Plan for Operations in the Year 2000, “preparations for the year 2000 have now shifted to focusing on ‘missions’ rather than systems” (USAF 1999b). We return to this trend in other lessons-learned sections, particularly in Chapter 2. 1.4.2.3. From Fixes to Continuity Planning Related to the shift from technological to mission perspective was a shift of focus from fixing problems to preparing for continued function in the face of uncertain impact. For U.S. government organizations, this shift began in early to mid-1998 and gained momentum as both the complexities of the problem (particularly testing) and the demands of starting up contingency plans for ICT-dependent mission-critical activities became clear. The evolving official government five-phase plan (Awareness, Assessment, Renovation, Validation, and Implementation) for managing a Y2K response program was initially developed in 1996; critical input came from Air Force planners at the ESC and the MITRE Corporation. The plan was disseminated in early 1997 by the Year 2000 Interagency Committee of the CIO Council (on an Air Force website) and by the General Accounting Office (GAO, now the Government Accountability Office) (OMB 1997 and GAO 1997). While contingency planning was mentioned, the plan initially focused heavily on the “massive undertaking” of finding, fixing (converting, replacing, or retiring), and testing all mission-critical systems, and perhaps even more. “Agencies must determine what systems are mission-critical and must be converted or replaced, what systems support important functions and should be converted or replaced, and what

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K systems support marginal functions, and may be converted or replaced later” (GAO 1997). The early 1997 GAO assessment guide focused on project management and organized the five-phase plan into 52 key processes. Of those, only two (2.16, under Assessment, and 5.6, under Implementation) related to developing contingency plans. One year later, the situation was already viewed quite differently. GAO released a guide devoted entirely to business continuity and contingency planning that began, “Time is running out for solving the Year 2000 problem” (GAO 1998b). As the Y2K response moved into its final year, complex efforts to complete and validate system renovations began to run up against equally complex efforts to develop and prepare viable contingency plans: “When we did the original studies in the spring of 1999, we realized the difficulty of fixing a serious, mission-critical problem within the time constraint for initiating the contingency plan” (Air Force Y2K Lessons Learned Workshop speaker). Many organizations shifted their primary focus from fixing and testing code to developing and monitoring contingency plans, or continuity of operations plans (COOPs) as they were called in the Air Force. (We return to the issue of COOPs in the lessons-learned sections, particularly in Chapter 4.) 1.4.2.4. From Technology to Political and Legal Issues For ICT professionals, Y2K first came to light as a technology issue concerning date representation. For the many other people who were increasingly drawn into the Y2K process, however, the primary motivators were more likely to be legal and, especially for government agencies, political. This was particularly true for corporate executives, agency administrators, and their staffs. For the AFY2KO, the impetus was not from the scientific community. Instead, “it came from the political side. Senator Bennett and others had the foresight to make this thing the issue that it became” . Given the huge potential for liability, early in the Y2K process corporations began sending queries about the readiness of their products through their legal rather than technical staff. By early 1998 this practice, in conjunction with the growing realization that Y2K preparation often called for high levels of coordination and cooperation across organizations, led to serious concerns that legal pressures would inhibit the flow of information vital to the success of these efforts. For example, the 375th AW/Y2K could not get any information from the vendors: “They just wouldn’t say yes or no to the compliance status of anything because they didn’t want to be held liable.” On July 30, 1998, at the request of the White House, Sen. Robert Bennett (R-Utah) introduced the Year 2000 Information Disclosure Act. This bill, passed early in October, provided liability protection from inaccurate statements made by organizations acting in good faith when sharing Y2K information. While no additional federal Y2K legislation was passed, many organizations extended the focus on good faith beyond information disclosure to general Y2K response activities. The perception was that if good faith precautions were taken in addressing Y2K risks, legal protection would follow. There were calls for due diligence in

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K addressing Y2K, though the meaning of this term was not always clear. For example, it often was interpreted as “if you saw something you could do, you had better do it.” The mandate came down under due diligence. … This was interpreted to mean that almost anything anybody could mention, you had to do that. … Because of the fear of being legally responsible… the only way you could not do something was if you could guarantee zero probability that there would be the possibility of an error. … Nobody could do that. (AMC/SCA) In many cases, this trend led to the use of auditing agencies and other legally focused means of monitoring Y2K response efforts. “We did whatever we could but then we thought, what if they ask whether we have done enough? Well, we could call out the audit agency, which we did on three different occasions. … Then of course the DOD IG (Inspector General) [wanted] to get involved” (AFCA). Government agencies were especially impacted by the increased political scrutiny of Y2K. In September 1997, Rep. Stephen Horn (R-Calif.) began issuing a congressional Y2K report card that produced such headlines as “Year 2000 Report Flunks 3 Agencies” and continued to get considerable attention throughout the Y2K effort, from the media and the agencies themselves (Barr 1997). The Department of Defense [DOD] received a C- on the first report. “Representative Horn probably did more to spur this whole process on than anybody” (AFCA). GAO reports also had a major impact. While these reports often focused on technical aspects of the problem, they also emphasized the legal and legislative motivations. For example, “DOD’s quarterly readiness reports do not fulfill the legislative reporting requirements under 10 U.S.C. 482 (the section of the U.S. Code that mandates such reporting) because they lack specific detail on deficiencies and remedial actions; as a result, these reports do not provide information needed for effective oversight of military readiness” (GAO 1998a). As might be expected, there was a wide range of reactions to congressional involvement in the Y2K response effort including, among others, the following: A large part of what you are talking about…wasn’t driven by any sort of need other than the political pressure. (AMC/SCA) External pressures caused us to have to report a lot of things we had never reported before. Some of which, now that we’ve come to grips with it, is not a bad thing. (AFCA) Is it rationally needed from a technical standpoint? No. But the measure of merit, in many cases, is you’re doing things to satisfy the political institution and the political pressures. …Political pressure is why we spent our time looking at everything as opposed to looking at the really important things. (AMC/HQ) Politics is part of the environment. It’s a reality of the environment that should not be put in pejorative terms. You know political leaders are not technologists; therefore, when these sorts of things happen, they naturally are not going to react with what is the engineering rational response. They are going to react with what is the politically rational response. It’s just as rational in their decision-making frameworks. (AFXO/IWD) We return to political and legal issues in other lessons-learned sections, particularly under the discussion of risk and response in Chapter 4.

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K 1.4.3. How the Research Opportunity Changed Just as perceptions of and responses to Y2K changed over time, so did Y2K as a phenomenon to be studied and an opportunity through which to learn important lessons. The NRC, working with the Air Force and with the support of the IEEE, began early in 1998 to position itself for a before-and-after study of lessons to be learned from the Y2K experience. Many of the early study aims were based on the assumption that there would be a number of critical, highly visible Y2K infrastructure failures. For example, one Air Force study aim was to use Y2K disruption as a surrogate for information warfare attacks. The hope was to develop a better understanding of how interdependent systems fail and then use that understanding to help make those systems more resistant to outside attack. The level of disruption assumed for this study goal did not occur. (Why it did not occur is addressed in Chapter 4 under lessons related to minimizing risk.) Interestingly, that Y2K did not produce major sustained disruption to critical infrastructure actually makes it a more valuable source of long-term lessons for the operational and strategic management of complex ICT systems. Y2K studies evolved from a focus on fundamental flaws and cascading effects into an analysis of impact on overall strategic management of information and communication technology. This analysis included issues such as maintenance and modernization, life-cycle management of systems and software, functional interdependency and continuity, guidance policies and certification, system ownership and responsibility, training and organizational roles, and security and information assurance. The worldwide Y2K response effort was of incredible magnitude and evolved over many years. It confronted organizational systems for managing ICT with situations they had never faced. People who played significant roles in this Y2K effort were changed in significant ways. Yet because little happened, the tendencies to return to business as usual were strong. We hope that people and organizations do not ignore the valuable, if difficult, lessons gained from the expenditure of hundreds of billions of dollars and countless hours of human effort. We also hope the following sections of this report contribute significantly to the useful dissemination and application of these lessons.

OCR for page 13
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K This page intentionally left blank.