FAA’s primary mission is to provide a safe, secure, and efficient global airspace system that promotes airspace safety in the United States and contributes to national security. The agency’s roles include regulating civil aviation, developing and operating a system of air traffic control and navigation for civil and military aircraft, and researching and developing the NAS, which consists of more than 19,000 airports, 750 air traffic control facilities, and about 45,000 pieces of equipment. FAA’s mission performance depends on the adequacy and reliability of the nation’s air traffic control system. The air traffic control system, the primary component of the NAS, is a vast network of computer hardware, software, and communications equipment. This system consists of automated information processing and display, communication, navigation, surveillance, and weather resources that permit air traffic controllers to view key information—such as aircraft location, aircraft flight plans, and prevailing weather conditions—and to communicate with pilots. These resources reside at, or are associated with, several air traffic control facilities—towers, terminal radar approach control facilities, air route traffic control centers (en route centers), flight service stations, and the System Command Center. Figure 1 shows a visual summary of the air traffic control system over the continental United States and oceans. FAA’s mission performance also depends on the skills and expertise of its work force, composed of over 50,000 staff who provide aviation services— including air traffic control; maintenance of air traffic control equipment; and certification of aircraft, airline operations, and pilots. In fiscal year 2005, FAA’s budget authority to support its mission was approximately $14 billion. According to FAA officials, approximately 95 percent of the agency’s total spending is in support of the NAS. Further, FAA estimates that it will spend $7.6 billion over the next two years to complete key modernization projects. As figure 2 illustrates, FAA has twelve staff offices to accomplish its mission—including the Office of International Aviation and the Office of Information Services/Chief Information Officer—and four lines of business—Air Traffic Organization, Commercial Space Transportation, Airports, and Regulation and Certification. Tables 1 and 2 provide additional information about the responsibilities of these offices and lines of business. Effective use of enterprise architectures, or modernization blueprints, is a trademark of successful public and private organizations. For more than a decade, we have promoted the use of architectures to guide and constrain systems modernization, recognizing them as a crucial means to a challenging goal: agency operational structures that are optimally defined in both business and technological environments. The Congress, the Office of Management and Budget (OMB), and the federal Chief Information Officer (CIO) Council have also recognized the importance of an architecture-centric approach to modernization. The Clinger-Cohen Act of 1996 mandates that an agency’s CIO develops, maintains, and facilitates the implementation of an IT architecture. Further, the E-Government Act of 2002 requires OMB to oversee the development of enterprise architectures within and across agencies. Generally speaking, an enterprise architecture connects an organization’s strategic plan with program and system solution implementations by providing the fundamental business and technology details needed to guide and constrain investments in a consistent, coordinated, and integrated fashion. As such, it should provide a clear and comprehensive picture of an entity, whether it is an organization (e.g., federal agency) or a functional or mission area that cuts across more than one organization (e.g., air traffic control). This picture consists of snapshots of both the enterprise’s current or “As Is” environment and its target or “To Be” environment, as well as a capital investment road map for transitioning from the current to the target environment. These snapshots further consist of “views,” which are basically one or more architecture products that provide conceptual or logical representations of the enterprise. The suite of products and their content that form a given entity’s enterprise architecture are largely governed by the framework used to develop the architecture. Since the 1980s, various frameworks have emerged and been applied. For example, John Zachman developed a structure or “framework” for defining and capturing an architecture. This framework provides for six windows from which to view the enterprise, which Zachman terms “perspectives” on how a given entity operates: those of (1) the strategic planner, (2) the system user, (3) the system designer, (4) the system developer, (5) the subcontractor, and (6) the system itself. Zachman also proposed six abstractions or models associated with each of these perspectives: these models cover (1) how the entity operates, (2) what the entity uses to operate, (3) where the entity operates, (4) who operates the entity, (5) when entity operations occur, and (6) why the entity operates. In September 1999, the federal CIO Council published the Federal Enterprise Architecture Framework (FEAF), which is intended to provide federal agencies with a common construct for their respective architectures, to facilitate the coordination of common business processes, technology insertion, information flows, and system investments among federal agencies. FEAF describes an approach, including models and definitions, for developing and documenting architecture descriptions for multiorganizational functional segments of the federal government. Similar to most frameworks, FEAF’s proposed models describe an entity’s business, the data necessary to conduct the business, applications to manage the data, and technology to support the applications. More recently, OMB established the Federal Enterprise Architecture (FEA) Program Management Office to develop a federated enterprise architecture according to a collection of five “reference models, and a security and privacy profile overlaying the five models.” The Performance Reference Model is intended to describe a set of performance measures for the major IT initiatives and their contribution to program performance. Version 1.0 of the model was released in September 2003. The Business Reference Model is intended to describe the federal government’s businesses, independent of the agencies that perform them. It serves as the foundation for the FEA. Version 2.0 of the model was released in June 2003. The Service Component Reference Model is intended to identify and classify IT service (i.e., application) components that support federal agencies and promote the reuse of components across agencies. Version 1.0 of the model was released in June 2003. The Data Reference Model is intended to describe, at an aggregate level, the types of data and information that support program and business line operations and the relationships among these types. Version 1.0 of the model was released in September 2004. The Technical Reference Model is intended to describe the standards, specifications, and technologies that collectively support the secure delivery, exchange, and construction of service components. Version 1.1 of the model was released in August 2003. The Security and Privacy Profile is intended to provide guidance on designing and deploying measures that ensure the protection of information resources. OMB has released Version 1.0 of the profile. Although these various enterprise architecture frameworks differ in their nomenclatures and modeling approaches, they consistently provide for defining an enterprise’s operations in both (1) logical terms, such as interrelated business processes and business rules, information needs and flows, and work locations and users and (2) technical terms, such as hardware, software, data, communications, and security attributes and performance standards. The frameworks also provide for defining these perspectives for both the enterprise’s current or “As Is” environment and its target or “To Be” environment, as well as a transition plan for moving from the “As Is” to the “To Be” environment. The importance of developing, implementing, and maintaining an enterprise architecture is a basic tenet of both organizational transformation and IT management. Managed properly, an enterprise architecture can clarify and help to optimize the interdependencies and relationships among an organization’s business operations and the underlying IT infrastructure and applications that support these operations. Employed in concert with other important management controls, such as portfolio-based capital planning and investment control practices, architectures can greatly increase the chances that an organization’s operational and IT environments will be configured to optimize its mission performance. Our experience with federal agencies has shown that making IT investments without defining these investments in the context of an architecture often results in systems that are duplicative, not well integrated, and unnecessarily costly to maintain and interface. In November 2003, we reported the results of our governmentwide survey of agencies’ progress—including FAA’s—in establishing key enterprise architecture management capabilities as described in Version 1.1 of our architecture management maturity framework. This framework associates specific architecture management capabilities with five hierarchical stages of management maturity, starting with creating enterprise architecture awareness and followed by building the enterprise architecture management foundation, developing the enterprise architecture, completing the enterprise architecture, and leveraging the enterprise architecture to manage change. Table 3 provides a more detailed description of the stages of Version 1.1 of the framework. Based on information provided by FAA, we reported that the agency had not established an architecture management foundation; as a result, we rated the agency to be at stage 1 of our framework. Specifically, we reported that it had not (1) allocated adequate resources and (2) established a framework, methodology, and automated tools to build the enterprise architecture. According to our framework, effective architecture management is generally not achieved until an enterprise has a completed and approved architecture that is being effectively maintained and is being used to leverage organizational change and support investment decision making. An enterprise with these characteristics would need to have satisfied all of the stage 2 and 3 core elements and most of the stage 4 and 5 elements. In August 2004, we reported that FAA had established most—about 80 percent—of the basic practices needed to manage its mission-critical investments, including many of the foundational practices for selecting and controlling IT investments. However, we reported that weaknesses still existed in the process.