The Federal Aviation Administration’s (FAA) primary mission is to ensure safe, orderly, and efficient air travel in the national airspace. FAA’s ability to fulfill this mission depends on the adequacy and reliability of the nation’s air traffic control (ATC) system, a vast network of computer hardware, software, and communications equipment. Sustained growth in air traffic and aging equipment have strained the current ATC system, limiting the efficiency of ATC operations. This pattern is likely to continue as the number of passengers traveling on U.S. airlines is expected to grow from about 580 million in 1995 to nearly 800 million by 2003, an increase of 38 percent. To address these trends, in 1981 FAA embarked on an ambitious ATC modernization program. FAA estimates that it will spend about $20 billion to replace and modernize ATC systems between 1982 and 2003. Our work over the years has chronicled many FAA failures in meeting ATC projects’ cost, schedule, and performance goals. As a result, we designated FAA’s ATC modernization as a high-risk information technology initiative in our 1995 report series on high-risk programs. The ATC system of the late 1970s was a blend of several generations of automated and manual equipment, much of it labor-intensive and obsolete. In addition, FAA forecasted increased future demand for air travel brought on by airline deregulation of the late 1970s. At that time, FAA recognized that it could increase ATC operating efficiency by increasing automation. It also anticipated that meeting the demand safely and efficiently would require improved and expanded services, additional facilities and equipment, improved work force productivity, and the orderly replacement of aging equipment. Accordingly, in December 1981, FAA initiated its plan to modernize, automate, and consolidate the existing ATC system by the year 2000. This ambitious modernization program includes the acquisition of new radars and automated data processing, navigation, and communication equipment in addition to new facilities and support equipment. The modernization, including new systems, facility upgrades, and support equipment is now estimated to cost over $34 billion through the year 2003. The Congress will have provided FAA with approximately $23 billion of the $34 billion through fiscal year 1997. The ATC systems portion alone, excluding facility upgrades and support equipment, totals over $20 billion of the planned $34 billion investment. The $20 billion will provide, in total, about 170 new systems, but additional systems are being planned through the year 2015. The modernization is still far from complete as nearly $6 billion of the $20 billion still remains to be spent after 1997 on portions of 73 systems. Automated information processing and display, communication, navigation, surveillance, and weather resources 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 ATC facilities—the Air Traffic Control System Command Center (ATCSCC), flight service stations, air traffic control towers, terminal radar approach control (TRACON) facilities, and air route traffic control centers (en route centers). These facilities’ ATC functions are described below. The ATCSCC in Herndon, Virginia, coordinates operations between the en route centers by combining traffic flow information from each. This information allows the ATCSCC to provide a snapshot of the traffic flows across the United States that is in turn used to ensure that airports do not exceed capacities. About 90 flight service stations provide pre-flight and in-flight services, such as flight plan filing and weather report updates, primarily for general aviation aircraft. Airport towers control aircraft on the ground, before landing, and after take-off when they are within about 5 nautical miles of the airport, and up to 3,000 feet above the airport. Air traffic controllers rely on a combination of technology and visual surveillance to direct aircraft departures and approaches, maintain safe distances between aircraft, and communicate weather-related information, clearances, and other instructions to pilots and other personnel. Approximately 180 TRACONs sequence and separate aircraft as they approach and leave busy airports, beginning about 5 nautical miles and ending about 50 nautical miles from the airport, and generally up to 10,000 feet above the ground, where en route centers’ control begins. Twenty en route centers control planes over the continental United States in transit and during approaches to some airports. Each en route center handles a different region of airspace, passing control from one to another as respective borders are reached until the aircraft reaches TRACON airspace. Most of the en route centers’ controlled airspace extends above 18,000 feet for commercial aircraft. En route centers also handle lower altitudes when dealing directly with a tower, or when agreed upon with a TRACON. Two en route centers—Oakland and New York—also control aircraft over the ocean. Controlling aircraft over oceans is radically different from controlling aircraft over land because radar surveillance only extends 175 to 225 miles offshore. Beyond the radars’ sight, controllers must rely on periodic radio communications through a third party—Aeronautical Radio Incorporated (ARINC), a private organization funded by the airlines and FAA to operate radio stations—to determine aircraft locations. See figure 1.1 for a visual summary of the ATC facilities that control aircraft. The ability of FAA’s systems to interoperate, both within and across facilities, as one integrated system of systems is essential to ATC operations. Each of the five facilities highlighted above contain numerous interrelated systems. For example, the en route centers alone rely on over 50 systems to perform mission-critical information processing and display, navigation, surveillance, communications, and weather functions. Examples include the systems that display aircraft situation data for air traffic controllers, the system that collects and displays data from various weather sources, radars for aircraft surveillance, radars for wind and precipitation detection, ground-to-ground and ground-to-air communications systems, and systems to back-up primary systems. In addition, systems from different facilities also interact with each other so that together they can successfully execute the total ATC process. For example, controllers’ displays currently integrate data on aircraft position from surveillance radars with data on flight destination from flight planning data systems. The ability of these systems to interoperate and continually exchange data in real-time is safety critical. Figure 1.2 depicts the five key air traffic control facilities (left section), the interaction between systems both within and between facilities (middle section), and the complexity of the systems associated with just one type of facility—the en route centers (right section—these systems are described in appendix I). Over the past 15 years, FAA’s modernization program has experienced substantial cost overruns, lengthy schedule delays, and significant performance shortfalls. To illustrate, the long-time centerpiece of this modernization program—the Advanced Automation System (AAS)—was restructured in 1994 after estimated costs tripled from $2.5 billion to $7.6 billion and delays in putting significantly less-than-promised system capabilities into operation were expected to run 8 years or more. Similarly, increases in costs for three other ATC projects have ranged from 51 to 511 percent, and schedule delays have averaged almost 4 years. For example, the per-unit cost estimate for the Voice Switching and Control System increased 511 percent, and the first site implementation was delayed 6 years from the original estimate. Shortfalls in performance have affected AAS, as well as other projects. For example, the critical Initial Sector Suite System component of AAS, which was intended to replace controllers’ workstations at en route centers, faced so many technical problems that it was severely scaled back. In addition, difficulties in developing the Air Route Surveillance Radar-4 software and integrating it with other ATC systems delayed its implementation for years. GAO’s work over the years has highlighted weaknesses in FAA’s management of the modernization that have caused cost, schedule, and performance problems. First, FAA did not historically manage its acquisition of major systems in accordance with Office of Management and Budget Circular A-109 and its own acquisition policies. For example, FAA did not analyze its mission needs, did not adequately specify ATC systems requirements, and performed flawed or limited analyses of alternatives for achieving those needs. This is contrary to our finding that successful public and private organizations tie decisions on information technology investments to explicit and quantifiable mission improvements. Second, some systems did not meet agency specifications. Finally, FAA has provided inadequate oversight of contractor performance. Additionally, GAO recently reported that FAA’s organizational culture has been an underlying cause of the agency’s acquisition problems, encouraging employee behavior that did not reflect a strong commitment to mission focus, accountability, coordination, and adaptability. Because of the past problems with FAA modernization efforts, the Congress enacted legislation in October 1995 that directed FAA to design and implement a new acquisition management system. The Act directed the FAA to develop and implement an acquisition system that would address the unique needs of the agency. At a minimum, the system was to provide for more timely and cost-effective acquisitions. To help achieve this goal, the Act exempted FAA from most federal procurement and personnel laws and regulations. On April 1, 1996, in response to the act, the FAA Administrator began implementation of FAA’s new system. The new acquisition management system is intended to improve coordination and mission focus by strengthening the “front-end” of the acquisition process. Specifically, the developers and operators are expected to work together to analyze mission needs and alternatives before senior management makes capital investment decisions and assigns projects to development teams. Two major FAA organizations play key roles in the development and evolution of ATC systems—the Office of the Associate Administrator for Research and Acquisitions (ARA) and the Office of the Associate Administrator for Air Traffic Services (ATS). Briefly, ARA is responsible for developing and fielding ATC systems, while ATS is responsible for operating, maintaining, and enhancing ATC systems. Cross-functional integrated product teams (IPT) residing in ARA are responsible for ATC systems development. ARA manages the research, development, and acquisition of modernization projects. According to the Associate Administrator for ARA, only one-half of the total systems development budget is spent by ARA, while the other one-half is spent by ATS implementing system enhancements. Within ARA, two groups are responsible for acquiring systems, while the others handle cross-cutting management functions (e.g., budget formulation and program evaluation). These two groups are the Office of Systems Development (AUA) and the Office of Communication, Navigation, and Surveillance Systems (AND). Five IPTs reside in AUA and are organized by ATC business areas (i.e., en route, terminal, weather and flight service, air traffic management, oceanic). Five IPTs reside in AND and are organized by ATC functional areas (i.e., infrastructure, communications, surveillance, GPS/navigation, aircraft/avionics). IPTs are responsible for research, development, and acquisition as well as for ensuring that new equipment is delivered, installed, and working properly. For example, the en route IPT comprises product teams for the Display Channel Complex Rehost, the Display System Replacement, the Voice Switching and Control System, and several other en route systems. Each IPT includes systems and specialty engineers, logistics personnel, testing personnel, contract personnel, and lawyers as well as representatives from the organizations responsible for operating and maintaining the ATC equipment. The second major organization involved with ATC systems is ATS. ATS is responsible for directing, coordinating, controlling, and ensuring the safe and efficient utilization of the national airspace system. Organizations within ATS are responsible for planning, operating, maintaining, and enhancing ATC systems. Responsibility for managing projects is transferred from ARA to ATS once a system has been installed and is operational. The FAA Technical Center is the ATC system test and evaluation facility and supports ATC systems’ research, engineering, and development. See figure 1.3 for a visual summary of the ATC modernization management structure. The objectives of our review were to determine (1) whether FAA has a target architecture(s), and associated subarchitectures, to guide the development and evolution of its ATC systems, and (2) what, if any, architectural incompatibilities exist among systems and what is the effect of these architectural incompatibilities. To determine whether FAA has a target architecture(s), and associated subarchitectures, to guide the development and evolution of its ATC systems, we researched current literature and interviewed systems architecture experts to identify the key components of a complete systems architecture; analyzed FAA’s National Airspace System Architecture (versions 1.5 and 2.0) and interviewed officials responsible for developing this architecture to determine whether the proposed systems architecture is complete and comprehensive; reviewed additional FAA efforts to develop systems architectures, including the Corporate Systems Architecture; interviewed the 10 IPTs responsible for ATC systems development to determine how architectural considerations are incorporated in development efforts; reviewed the NAS System Requirements Specification (NAS-SR-1000), the NAS Level 1 Design Document (NAS-DD-1000), and the NAS System Specification (NAS-SS-1000) to determine whether existing guidance constitutes the components of a systems architecture; interviewed ARA organizations responsible for developing software, communications, data management, and security guidance about existing guidance and efforts to improve this guidance; interviewed FAA’s Chief Information Officer (CIO) to determine what role the CIO plays in the development of FAA’s systems architecture and whether this role is consistent with recently passed legislation; and analyzed FAA’s current structure and processes associated with architectural development and enforcement. To determine what, if any, architectural incompatibilities exist among systems and what is the effect of these architectural incompatibilities, we acquired and analyzed information on the hardware, operating systems, application languages, database management, communications, and security characteristics of seven existing and under development ATC systems to identify architectural incompatibilities; reviewed key technical documents associated with some of these systems, including interface control documents and technical briefings; analyzed the cost, schedule, and performance impacts of the architectural incompatibilities that exist among ATC systems; interviewed the Director of Operational Support to obtain ATC maintenance concerns and to obtain his opinion about system incompatibilities; and identified the application languages used in 54 operational ATC systems. We performed our work at the Federal Aviation Administration in Washington D.C., and the FAA Technical Center in Atlantic City, New Jersey, from March 1996 through January 1997. Our work was performed in accordance with generally accepted government auditing standards. Department of Transportation (DOT) and FAA officials, including the FAA Deputy Director for Architecture and System Engineering, the FAA Chief Scientist for Software Engineering, and the FAA Chief Engineer for Air Traffic Systems Development, provided oral comments on a draft of this report. Their comments have been addressed in the Agency Comments and Our Evaluation sections at the end of chapters 3 and 4 and as appropriate in the body of the report. Over the last decade, as computer-based systems have become larger and more complex, the importance of and reliance on systems architectures has grown steadily. These comprehensive “construction plans” or “blueprints” systematically detail the full breadth and depth of an organization’s mission-based modus operandi, first in logical terms, such as defining business functions, providing high-level descriptions of information systems and their interrelationships, and specifying information flows; and second in technical terms, such as specifying hardware, software, data, communications, security, and performance characteristics. Without a systems architecture to guide and constrain a modernization program, there is no systematic way to preclude inconsistent system design and development decisions, and the resulting suboptimal performance and added cost associated with these incompatible systems. This is why leading public and private sector organizations strongly endorse defining and enforcing systems architectures as an integral and vital aspect of modernizing their information systems. We found that leading organizations in the private sector and in government use systems architectures to guide mission-critical systems development and to ensure the appropriate integration of information systems through common standards. In addition, experts in academia have also championed the systems architecture approach. For example, the Software Engineering Institute (SEI) at Carnegie Mellon University includes the development and evolution of a systems architecture as a key process area in its Systems Engineering Capability Maturity Model (SE-CMM). The SE-CMM states that the systems architecture should detail both logical and technical system elements, their relationships, interfaces, and system requirements, and should guide the system design and implementation. Congress has also recognized the importance of systems architectures as a means to improve the efficiency and effectiveness of federal information systems by enacting the 1996 Clinger-Cohen Act. The act, among other provisions, requires that department-level CIOs develop, maintain, and facilitate integrated systems architectures. Reflecting the general consensus in the industry that large, complex systems development efforts should be guided by explicit architectures, in 1992, GAO issued a report defining a comprehensive framework for designing and developing systems architectures. This framework divides systems architectures into two principal components—a logical component and a technical component. The logical component is essential to ensure that an agency’s information systems support accomplishing a specific mission(s), while the technical component provides the detailed guidance needed to develop and evolve these systems. At the logical level, the architecture includes a high-level description of the organization’s mission, functional requirements, information requirements, systems, information flows among systems, and interfaces between systems. The logical architecture is derived from a strategic information systems planning process that clearly defines the organization’s current and future missions and concepts of operations. It then defines the business functions required to carry out the mission and the information needed to perform the functions. Finally, it describes the systems that produce the information. An essential element of the logical architecture is the definition of the component interdependencies (i.e., information flows, system interfaces). Once the logical architecture is defined, an organization knows its portfolio of desired systems and has a clear understanding of how these systems will collectively carry out the organization’s objectives. The purpose of the logical architecture is to ensure that the systems meet the business needs of the organization. The technical level details specific information technology and communications standards and approaches that will be used to build systems, including those that address critical hardware, software, communications, data management, security, and performance characteristics. The purpose of the technical architecture is to ensure that systems are interoperable, function together efficiently, and are cost-effective over their life cycles (i.e., including maintenance costs). Figure 2.1 displays the key logical and technical components of a systems architecture. (e.g., expandability, reliability, maintainability, fault tolerance) (e.g., reliability, testability, flexibility, maintainability, portability, reusability, adherence to open systems standards, standards for the languages to be used, institutionalized process standards or methodologies for designing, coding, testing, and documenting software projects) (e.g., reliability, availability, standards for communications protocols) (e.g., standards for data formats and naming conventions, a data dictionary) (e.g., hardware and software solutions to address security requirements that are based on a security policy and security concept of operations) (e.g., ability to meet operational requirements, response-time requirements, availability, reliability) FAA lacks a complete systems architecture to guide the development and evolution of its ATC systems modernization. While FAA has made good progress over the last 2 years in defining a logical ATC systems architecture, FAA has not adequately addressed its need for a technical ATC systems architecture. The lack of an ATC systemwide technical architecture has caused, and will continue to cause, incompatibilities among the ATC systems, such as differences in communications protocols and application languages, that require additional development, integration, and maintenance resources to overcome. The incompatibilities also make it difficult to share application software among systems and to migrate to vendor-independent operating environments, thereby effectively foreclosing two opportunities to reduce system development and maintenance costs. FAA is currently defining a logical ATC systems architecture that describes FAA’s concept of operations, business functions, high-level descriptions of information systems and their interrelationships, and information flows among systems. This high-level systems blueprint provides a roadmap that is to guide ATC systems over the next 20 years. FAA is defining a comprehensive and evolutionary logical ATC systems architecture in its National Airspace System (NAS) architecture. Among other things, the architecture provides a description of the future aviation, air traffic management, and air navigation system in terms of services, functions, and ATC systems. Specifically, it describes FAA’s concepts of operations, requirements in terms of the business functions to be performed, associated systems to be used, the relationships between these functions and systems, the information needed to perform these functions, and the flow of information among the functions and systems. In addition, it provides a roadmap for evolving the ATC systems through the year 2015. The goals of the logical architecture are to (1) provide the aviation community with a cohesive and collaborative means to influence the NAS evolution, (2) provide a foundation for FAA acquisition decisions, and (3) provide the aviation community with insight into the timing of major changes to NAS. According to FAA, the NAS architecture is intended to eliminate “stovepiped” development by defining an evolution towards target architectures that represent coordinated and integrated operational concepts and a comprehensive system of systems view. The NAS architecture is not intended to provide the details needed to actually design and build these systems (i.e., details that would be provided by the technical architecture). FAA issued version 2.0 of the NAS architecture in October 1996 and subsequently released it for industry and government comment. The first complete version of the architecture is scheduled to be completed in December 1997. The NAS architecture is divided into five key parts—concepts of operations, service and functional requirements, systems and programs, roadmap, and issues. Each is briefly discussed below. Concepts of Operations: This section describes an evolving series of concepts of operations through the year 2015 and emphasizes the migration to a free-flight environment. The current concept of operations relies on analog voice communications between controllers and pilots, and ground-based radar surveillance to control aircraft. A free-flight environment is one in which the pilots are free to select their own routes and speed in real time. In this environment, air traffic restrictions would be imposed only to ensure minimum aircraft separation, preclude exceeding airport capacity, prevent unauthorized flight through special-use airspace, and ensure safety. A free-flight environment relies less on voice communications and ground-based radar systems and more on aircraft position displays in the cockpit and satellite surveillance and navigation technologies, such as the Global Positioning System (GPS). The transition from the current to the free-flight concept of operations will be evolutionary. Mid-term concepts of operations will define FAA’s evolution methodically and gradually to a free-flight environment. Service and Functional Requirements: This section describes services and associated functional requirements that are required to carry out the concepts of operations. The service requirements include air traffic (i.e., flight planning, flight support, aircraft navigation and guidance, traffic management, separation, data information management, and communication management), airport, security, safety, certification, infrastructure, and administrative and acquisition support services. These service requirements are further broken down by functional requirements (e.g., provide forecasted weather information, provide air traffic flow information) and specify existing systems and describe future NAS systems (e.g., Host Computer System and Display System Replacement, respectively). Systems and Programs: This section describes the systems associated with each functional area (i.e., communications, weather, automation, surveillance, maintenance and support, navigation) and business area (i.e., en route, terminal, tower, oceanic, air traffic management) of the proposed architecture. For each of the functional areas the following information is provided: (1) listing of systems through the year 2015, (2) current programs and schedules from the Capital Investment Plan (CIP) and the Research, Engineering, and Development (RE&D) plan, and (3) transition strategy and diagrams. In addition, this section provides systems drawings (i.e., high-level wiring diagrams) of the various business areas for the 1995 and 2005 time frames. Appendix I provides a simplified block diagram for the near- and mid-term en route business area’s systems environment, which is very complex (i.e., includes many systems that interact in many ways). Roadmap: This section provides a transition plan for replacing systems, replacing existing infrastructure, and introducing new capabilities. The NAS architecture roadmap presents a proposed architecture in several functional areas (e.g., navigation, surveillance) and describes a transition strategy to migrate from the current systems environment to the proposed architecture. For example, for the navigation functional area, it describes a gradual transition strategy to a satellite-based navigation system. Specifically, it describes the deployment schedule for the primary system, Wide Area Augmentation System (WAAS), the schedule for decommissioning existing systems, and the additional system deployment schedules to support the far-term concept of operations. The roadmap describes the changes in ATC systems through time as they evolve to support free-flight. Issues: This section provides a collection of papers on outstanding issues whose resolutions should have the greatest potential impacts on the future of ATC systems. These issues are the “forks in the road” where a decision is needed to define a particular roadmap to the future. For example, one paper presents a series of unanswered questions on performance and backup requirements for future ATC surveillance. Another recommends the need for a free-flight action plan that is to guide FAA’s transition to a free-flight environment. The interrelationships among the NAS architecture’s services, functional areas, and associated systems are quite complex, as any one system may support multiple functional and service areas. For example, the Host Computer System (HCS) is an automation system located in the en route facilities that supports several business areas ( i.e., the en route business area by processing data from many different radar systems and air traffic management (ATM) business area by providing flight track data to select ATM systems). Figure 3.1 shows the relationships between the NAS architecture air traffic services, business areas, functional areas, and related systems. FAA’s efforts to develop and evolve its “system of ATC systems” is not guided and constrained by an ATC-wide technical architecture, and FAA does not have an effective strategy for developing one. In 1995, FAA recognized the importance of such an architecture by including the development of an FAA corporate architecture in its 1996 Capital Investment Plan. However, FAA decided to drop this effort from FAA’s 1997 plan in favor of other investment priorities. As a result, the IPTs have been left to proceed individually in setting architectural standards and developing and evolving systems. This has resulted in three IPTs cooperatively developing similar but not identical architectures for their respective areas, while others are proceeding without one. At the same time, still other FAA organizations are independently attempting to develop pieces (e.g., software guidance, security guidance) of a technical architecture, but these efforts are not coordinated and neither individually nor collectively constitute a complete ATC-wide technical architecture. Without an ATC-wide technical architecture, FAA’s ATC systems have and will continue to suffer from costly and inefficient incompatibilities. The concept of a technical systems architecture is not new to FAA. In FAA’s January 1996 Capital Investment Plan, FAA planned to develop a technical architecture, called the corporate systems architecture (CSA). According to FAA plans, the CSA was to be a blueprint for achieving an open systems environment and was to be used to “guide, coordinate, and integrate the acquisition, development and implementation of automated data processing equipment, telecommunications, automated information systems and data bases, and associated support services” across FAA. However, the CSA effort was abandoned in favor of other funding priorities. FAA’s CIO, who was tasked to develop the CSA, told us that the CSA was not funded in 1996 because its sponsors and developers could not convince FAA top management of its importance in providing benefits like cheaper development, integration, and maintenance costs, and better systems performance. In the absence of an overall ATC technical systems architecture, the IPTs are left to their own devices in formulating guidance to build systems. As a result, three IPTs have cooperatively developed similar but not identical technical architectures. The other seven IPTs are developing ATC systems, which include such major systems as the Standard Terminal Automation Replacement System (STARS) and the Wide Area Augmentation System (WAAS), without a technical architecture. (See figure 3.2 for a summary of architectural guidance used by the 10 IPTs.) With respect to the latter seven, officials for one IPT could not cite any technical architectural guidance being used, while officials for another IPT cited the NAS architecture, and officials for the other five cited the NAS “1,000-series” documents. However, neither the NAS architecture nor the NAS “1,000 series” constitutes a technical architecture. The NAS architecture is a logical architecture that provides no technical details, and the NAS “1,000 series” documents are neither a logical nor technical architecture. In fact, the Deputy Director for the Office of System Architecture and Investment Analysis, stated that the NAS “1,000 series” documents are “shelfware” and not useful in guiding future systems development. In commenting on a draft of this report, Systems Architecture and Investment Analysis officials stated that they plan to issue a revision to the NAS “1,000 series” documents in October 1997. Each of the three IPTs using their own, cooperatively developed technical architectures are described below. ATM IPT: This IPT was the first to develop a technical architecture, which is called the ATM Domain Environment Definition Document. It provides guidelines and standards for, among other things, operating systems, communication protocols, data management, security, coding, and testing. ATM officials stated that they created this document to facilitate system integration and ATM software application migration among the systems they are developing, which include the Traffic Management System (TMS) and the Center TRACON Automation System (CTAS). En route IPT: This IPT’s architecture governs development of such systems as the Display System Replacement (DSR) and the Host Interface Device/Local Area Network (HID/LAN). The architecture contains a systems development model and a standards profile, including data interchange, communications, security, and programming language standards. Infrastructure IPT: This IPT’s architecture is for its NAS Infrastructure Management System (NIMS), which is this IPT’s primary system. The NIMS architecture includes both logical and technical components. It includes a standards profile that contains the same general categories of standards as the ATM and en route technical architectures. While the three IPTs tried to achieve architectural compatibility, they have not been fully successful. For example, all three architectures specify C and C++ as acceptable programming languages, but the en route architecture also specifies Ada as an acceptable language. Also, although the ATM, en route, and infrastructure architectures all specify compliance to the Structured Query Language (SQL)-92 to access data, the en route architecture acknowledges that the SQL-92 standard will have to be modified at times to meet FAA’s real-time, mission-critical requirements. Currently, FAA has no plan for doing this consistently across all three systems environments. Further, the ATM technical architecture specifies the ethernet protocol and the en route architecture specifies the Fiber Distributed Data Interface (FDDI) protocol. These two protocols are not compatible. FAA officials told us that they are aware of inconsistencies and that they plan to resolve them, but have not defined the plan, scheduled its implementation, or allocated resources for the effort. In addition to these IPT-specific technical architectures, three other ARA offices (i.e., Office of Systems Architecture and Investment Analysis, Office of Information Technology, Acquisition Policy Branch) have initiated efforts that relate to, but neither individually nor collectively constitute a complete technical architecture. These efforts have begun to address data management, security, and software process and product standards; however, they are limited in scope, are incomplete, and will not be mandated for use across all ATC systems. Each is discussed below. The Office of Systems Architecture and Investment Analysis is adding a draft section on data management to the logical architecture that describes the current state of data exchange between ATC systems. However, this section does not define specific standards (e.g., standards for data elements and naming conventions), and FAA officials have not established milestones for doing so. This office is also planning to develop guidance addressing how security controls (e.g., hardware and software solutions) will be implemented to satisfy security requirements. However, this effort has not been approved by FAA management, and therefore remains unfunded. Also, this office has created a menu of architectural standards (e.g., data management, data interchange, communication protocol, application development, and security standards) to increase IPTs’ awareness of what standards exist for the IPTs to use at their own discretion. The Office of Information Technology is initiating efforts to improve software acquisition processes, has trained the IPTs on software process improvement, and has established a Software Engineering Process Group to champion process improvement activities. However, these initiatives do not specify software product standards, such as standard programming languages and development tools, or standards for software structure, both of which are critical to modernizing ATC systems cost effectively. Moreover, FAA cannot yet demonstrate specific and measurable process improvements. The Acquisition Policy Branch has begun an initiative to develop systems engineering guidance for IPTs’ optional use. Because this guidance is early in its development and a complete draft does not yet exist, FAA would not provide us a copy for review. The lack of a complete systems architecture has produced architectural differences and incompatibilities among ATC systems, such as different communication protocols and proprietary operating environments, and will continue to do so for future systems. (Examples of these differences for key systems in the current and near-term en route environment are provided in appendix II.) Further, the significance of these incompatibilities will increase as FAA moves to a more networked systems environment. Overcoming these incompatibilities means “higher than need be” system development, integration, and maintenance costs, and reduced overall systems performance. Additionally, because many existing systems are largely proprietary, opportunities for application software reuse among systems is effectively precluded and options for migrating applications to new hardware and software platforms are restricted. A system interface is hardware and software that acts as an interpreter to interconnect different systems and allow for the exchange of data. The more similar the communications and data features of the systems that are to communicate, the less complicated this interface. Conversely, the more disparate the systems, the more complicated the interface. Communications and data management subarchitectures are essential to standardize communication protocols and data formats, respectively, so that system interfaces are less costly and easier to implement. As described in chapter 1, system interoperability in the ATC system of systems is essential for FAA to successfully perform its mission. However, fundamental differences in how the systems communicate have made exchanging data between systems more difficult and expensive because it requires the development and maintenance of costly interfaces to interconnect systems. This can be seen in the en route business area, where a system known as the Peripheral Adapter Module Replacement Item (PAMRI) operates as a collection of systems interfaces. Specifically, PAMRI’s primary function is to convert differing protocols from feeder systems, like aircraft surveillance radars and weather detection systems, so that data from these systems can be used by the Host Computer System (HCS), the centerpiece information processing system in the en route centers. To perform this function, FAA spent over $38 million to develop PAMRI and it spends millions annually to maintain it. In addition to protocol conversion, PAMRI also performs data conversion of its disparate feeder systems. This conversion is necessary to remedy the data inconsistencies among ATC systems that feed HCS. These data inconsistencies extend beyond just those systems that interface with HCS. For example, FAA has hired a contractor to write an interface so that the Center TRACON Automation System (CTAS) can talk to the Automated Radar Terminal System (ARTS) IIIE. The cost of this interface is estimated at $1 million. In effect, this interface is a “mini-PAMRI.” Although some of the systems incompatibilities arise from the fact that FAA’s current ATC systems span several generations of computer systems, other incompatibilities are the result of FAA’s failure to adopt and enforce a systems architecture. According to a July 1996 FAA report baselining the ATC data management environment, ATC data inconsistencies have resulted from a lack of data standards and policies across the ATC systems. Systems written in many application programming languages are more difficult and expensive to modify and maintain than systems written in fewer languages. For example, for each language, programming staff must be trained and provided support software (compilers, debuggers, program libraries, etc.), and both the training and suite of support software must be updated and maintained. A software subarchitecture is essential to standardize the languages to be used and to institutionalize process standards or methodologies for designing, coding, testing, and documenting software projects. Software applications associated with 54 operational ATC systems have been written in 53 programming languages (these 53 include 19 assembly languages). Since most of the ATC languages are obsolete, there is no readily available cadre of newly trained programmers and current and future maintenance becomes even more difficult and costly. For example, the Automated Radar Terminal Systems (ARTS) are written in Ultra, an obsolete assembly language. Furthermore, no restrictions are currently being placed on application language choices for new systems development. For example, a new system that is currently being developed, the Display System Replacement (DSR), is to be written in three programming languages—Ada, C, and assembly. Ada is not used in any other existing ATC system. AUA officials told us that the five AUA IPTs are primarily using C, C++, and Ada to develop new ATC systems. However, we found three additional languages and several versions of assembly language also being used to develop new ATC systems. Software maintenance is a significant FAA expense. To illustrate, the software for the Host Computer System (HCS), its backup—the Enhanced Direct Access Radar Channel (EDARC)—and PAMRI cost $63.6 million annually to maintain. Until a software subarchitecture is developed that is based on a systematic analysis of the needs of current and planned operating environments and defines the languages to be used in developing ATC systems, FAA will continue to experience language proliferation and be faced with difficult and costly software maintenance. FAA plans to migrate its highly proprietary ATC systems to open operating environments. An open environment is one that is based on vendor-independent, publicly available standards. If properly planned and implemented, an open system environment supports portable and interoperable applications through standard services, interfaces, data formats, and protocols. Although the plan to evolve to an open environment is a wise one, important choices have to be made consistently across ATC systems to derive the expected benefits (e.g., portable applications, system interoperability). In particular, the open system standards for the collective system of systems must be carefully and thoroughly analyzed in light of systemwide requirements, and the most appropriate standards must be selected. The rigor associated with developing a systems architecture can ensure such analysis. Currently, this systemwide analysis is not occurring. Instead, most of the IPTs that are implementing open systems standards are doing so independently. Such a nonstandard migration approach may result in different open system options being selected, perpetuating architectural incompatibilities that require additional costs to overcome. For example, future FAA systems are to provide information to controllers through networked workstations. Two open systems protocol standards that IPTs could independently choose for passing information—ethernet and token-ring—are incompatible. Evolution to an open systems environment would also allow FAA to share software among systems with common functionality. For instance, FAA officials told us that 40 percent of the en route flight data processing (FDP) functionality is identical to the oceanic FDP functionality. This 40 percent equates roughly to about 60,000 lines of code. To their credit, FAA officials told us that the oceanic and en route IPTs have agreed to look at opportunities to share software between the replacement systems that perform FDP functions. However, without a guiding systems architecture that specifies specific open systems standards, FAA will likely not develop the oceanic and en route replacement systems that are to perform the FDP functions to common standards, thus precluding the opportunity to share software components. Because it has no complete and comprehensive systems architecture to guide and constrain the ATC systems modernization program, FAA continues to spend nearly $2 billion annually on “stovepipe” systems in an environment where system interoperability is an absolute necessity. To achieve interoperability, FAA is forced to develop and maintain costly system interfaces and incurs higher than need be system development and maintenance costs and reduced systems performance. We recommend that the Secretary of Transportation direct the FAA Administrator to ensure that a complete ATC systems architecture is developed and enforced expeditiously and before deciding on the architectural characteristics for replacing the Host Computer System. In commenting on a draft of this report, DOT and FAA officials generally agreed with our recommendation, which requires FAA to define and enforce a complete ATC-wide systems architecture. At the same time, however, the officials stated that (1) FAA’s informal mechanisms for attaining system compatibility (e.g., informal communication among system development teams and circulation of individual system specifications among these teams for review and comment) are sufficient and are working well; and (2) the architectural definition efforts underway within individual development teams and these teams’ parent organizations, once completed, will effectively augment these informal processes. The many examples provided in the report in which FAA incurs added costs to compensate for system incompatibilities arising from the lack of an ATC architecture provide clear evidence that FAA’s informal mechanisms are neither sufficient nor working well; and there is no logical rationale to support or explain FAA officials’ view that the efforts of the individual teams will somehow coalesce into an effective approach to ATC-wide architectural definition and enforcement. It is clear that effectively modernizing a system of systems as technologically complex, expensive, interdependent, and safety-critical as the ATC system requires more than stovepipe architectures linked and enforced by informal communications. Accordingly, we strongly recommend that FAA formally define and enforce an ATC-wide systems architecture. The officials also stated that most of FAA’s legacy systems pre-date the advent of architectural standards, and that it is thus system age rather than FAA’s lack of a systems architecture that is primarily to blame for existing system incompatibilities. As stated explicitly in the report, some incompatibilities exist because some systems pre-date currently available technology and standards. However, other system incompatibilities are the result of FAA’s failure to adopt and effectively enforce a technical architecture. Furthermore, until FAA completes and enforces its systems architecture, similar incompatibilities will recur in new ATC systems. The officials also commented that formally prescribed and enforced architectural standards could inhibit product team flexibility and creativity in acquiring ATC systems. They added that while they support the use of standards and are trying to move in that direction, they prefer a less formal approach to standards implementation and enforcement. This position has no merit. A well planned architecture that is enforced in a thoughtful and disciplined manner ensures compatibility and interoperability among different systems without unduly constraining internal system characteristics. The lack of such an architecture fosters not innovation but incompatibility and waste. FAA’s current approach to ATC architectural development, maintenance, and enforcement is not effective. The office that is responsible for developing and maintaining the NAS, or logical systems architecture, has no budgetary or organizational authority to enforce it, and no FAA organizational entity is responsible for developing and enforcing an ATC-wide technical architecture. As a result, ATC projects can be funded that do not comply with the ATC logical architecture (deviations are not supported by a documented waiver justifying the noncompliance) and there is no complete ATC technical architecture. Until FAA assigns a single organizational entity the responsibility and authority needed to develop, maintain, and enforce an ATC logical and technical systems architecture, FAA will not effectively address ATC system incompatibilities. If a complete systems architecture is to be effectively developed, maintained, and enforced, some organizational entity must (1) be assigned the responsibility and be held accountable for doing so, (2) be given sufficient resources to accomplish the task, (3) have expertise in information technology, and (4) have organizational and/or budgetary authority over all systems development and maintenance activities. One model for implementing this is embodied in the Clinger-Cohen Act, which requires that major federal departments and agencies establish CIOs that report to the department/agency head and are responsible for developing, maintaining, and facilitating the implementation of systems architectures. FAA does not have an effective management structure for developing, maintaining, and enforcing a logical ATC systems architecture. The Office of Systems Architecture and Investment Analysis, which is under the Associate Administrator for Research and Acquisitions, is responsible for developing and maintaining the logical ATC architecture (i.e., the NAS architecture), and has made good progress over the last 2 years in developing and maintaining one (see chapter 3). However, this office is not responsible for enforcing the logical architecture and cannot enforce it because it has neither organizational nor budgetary authority over the IPTs that develop ATC systems or the units that maintain them. (See figure 4.1 for the Office of Systems Architecture and Investment Analysis’ organizational position in relation to the Administrator, CIO, IPTs, and maintenance activities.) FAA officials say that they use the capital investment planning process to enforce the logical architecture. Under this process, various FAA organizations, including the CIO, evaluate and compare competing NAS projects and choose projects to be funded. Four criteria are considered in scoring competing investment options and deciding among them: (1) sponsor (i.e., user) support; (2) mission importance; (3) technology maturity/NAS architecture conformance; and (4) cost effectiveness. Each criterion carries a standard weighting factor that is to be consistently applied to all proposed projects in producing a project score: sponsor support and technology maturity/NAS architecture conformance each carry a weight of 20 percent, while mission importance and cost effectiveness each carry a weight of 30 percent. According to FAA, projects that do not conform to the NAS architecture can be approved under this process. While deviations from the architecture may sometimes be warranted, the decision to waive the requirement for architectural conformance should be made only after careful, thorough, and documented analysis. FAA’s investment process does not require such analysis. FAA has drafted new acquisition management guidance that modifies the above described capital investment planning process. FAA officials stated that the new process will require that ATC projects conform to the logical architecture and that waivers to this requirement will be granted only with convincing and documented justification. This is not the case. The draft guidance permits each team to choose its investment criteria and does not even require that architectural conformance be among them. As a result, this draft guidance does not constitute an effective approach to architectural enforcement. FAA also lacks an effective management structure for developing, maintaining, and enforcing a technical ATC systems architecture. No organization in FAA is responsible for technical ATC architecture. Instead, FAA has permitted a “hodge podge” of independent efforts scattered across its ATC modernization organization to emerge with no central guidance and coordination. For example, the Office of Systems Architecture and Investment Analysis is developing systems security guidance and a menu of architectural standards, while other offices have initiated efforts to develop additional technical architecture guidance (see chapter 3). As a result, there is no ATC-wide technical architecture, and it is unlikely that FAA will produce one in the near future. Until the authority, responsibility, and resources to develop, maintain, and enforce a complete ATC systems architecture are clearly assigned to a single FAA organizational entity, FAA will continue to build incompatible and unnecessarily expensive and complex ATC systems. We recommend that the Secretary of Transportation direct the FAA Administrator to establish an effective management structure for developing, maintaining, and enforcing the complete ATC systems architecture. Specifically, the Administrator should (1) assign the responsibility and accountability needed to develop, maintain, and enforce a complete ATC systems architecture to a single FAA organizational entity, (2) provide this single entity with the resources, expertise, and budgetary and/or organizational authority needed to fulfill its architectural responsibilities, and (3) direct this single entity to ensure that every ATC project conforms to the architecture unless careful, thorough, and documented analysis supports an exception. Given the importance and the magnitude of the information technology initiative at FAA, we recommend that a management structure similar to the department-level CIOs as prescribed in the Clinger-Cohen Act be established for FAA. In commenting on a draft of this report, DOT and FAA officials generally agreed with our conclusions and recommendations. However, the FAA Deputy Director for Architecture and System Engineering stated that FAA is drafting a revision to its investment management policy that, once approved, will change the capital investment planning process and associated investment decision criteria described in our report. Our review of this draft guidance disclosed that it does not require that every ATC project conform to the logical architecture. Instead, the draft guidance permits each team to choose its investment criteria and does not require that architectural conformance be among them. (NARACS) Collects surface observations data from AWOS and ASOS and distributes these data to weather processing and display systems. Provides capability for real-time and nonreal-time monitoring of en route center systems, remote control of equipment and facilities, communications/coordination, and system security. Provides backup air-to-ground radio voice communications service in the event of a failure of the primary or secondary air-to-ground radio system. Provides flight data input/output print capability. Provides display capability that will be replaced by DSR. Provides display capability that will be replaced by DSR. Provides display capability that will be replaced by DCCR, which will in turn be replaced by DSR. Provides display capability that will replace DCC. Provides character and image display capability that will be replaced by DSR. Provides an inter-facility multiplexed data transmission network. Down-Scoped Radio Control Equipment Controls local and remote air-to-ground radios. Make legal recordings of all voice communications between air traffic controllers and pilots. Enhanced Direct Access Radar Channel Provides a backup to HCS for radar processing, and radar track and display processing. Provides flight data input/output capability by transferring flight data inter-/intrafacility. Provides the processing capability to support AFSS workstations and automated pilot briefings, and maintains a national flight service database. Processes radar surveillance data, associates flight plans with tracks, processes flight plans, performs conflict alerts, and processes weather data. Provides capability for data entry and display and provides a standard serial data interface to connect to a RMS. Provides capability for real-time monitoring and alarm notification, certification parameter data logging, automatic record keeping and information retrieval, and trend analysis, failure anticipation, remote control of equipment and facilities, diagnostic and fault isolation, remote adjustments, and system security. Provides weather data processing and display. Make legal recordings of all voice communications between air traffic controllers and pilots. (continued) National Radio Communications System Provides minimum essential command, control, and communications capabilities to direct the management, operation, and reconstitution of the National Airspace System during a national or local emergency. Provides interfacing capability to HCS. Provides communication network for transmitting data via addressed packets. Provides the capability to request and display NEXRAD weather data. Provides aircraft situation display capability for the controller that is to be replaced by DSR. Controls local and remote air-to-ground radios. Provides FDIO remote print capability. Provides National Radio Communications System emergency communications essential during and after earthquakes, hurricanes, and tornadoes. Provides air-to-ground and voice communication services and ground-to-ground voice communication services between controllers, other ATC personnel, and others at the same and different en route centers and other ATC facilities. Provides track generation and traffic display as part of the Oceanic Traffic Planning System. Oceanic system that displays aircraft position based on extrapolations from flight plans. Provides a display showing the location of aircraft across the country that is used for strategic planning purposes. Provides national level management and monitoring of the airspace system, including air traffic flow, aircraft operations, and en route sector and airport utilization and loading. WMSCR (NAWPF) To Navaid Mon. EDARC Repl. MIP (ASR) (Sur. Fusion) FAA Transmis. Facil. Collects surface observation data from AWOS and automated surface observing system (ASOS) and distributes these data to weather processing and display systems. Provides the capability to transfer data in digital form between the aircraft and the ground or between aircraft by means other than voice communications. Maximizes use of airport capacity by providing decision aids to en route and terminal controllers. This is the area in the en route center where the meteorologists perform their functions using the various systems that provide them with weather information. Supports networked aeronautical telecommunications services within United States domestic and oceanic airspace. Calculates departure sequence, from push-back to time over fix, and includes runway configuration, gate position, aircraft performance, and flow restrictions, for a group of airports. Displays departure sequence lists in towers and at the Traffic Management Unit (TMU). Provides modern ATC workstations to support programs like Weather and Radar Processor (WARP), Automated En Route Air Traffic Control (AERA), CTAS, and Data Link. Provides new controller data entry and display devices. Provides an interface capability with the Host computer and system and the Enhanced Direct Access Radar Channel (EDARC). Provides the pilot with convenient access to pre-flight aeronautical and weather information to plan the flight. Also allows pilots to input instrument flight rules (IFR), International Civil Aviation Organization (ICAO), or Visual Flight Rules (VFR) flight plans into the system . Enhanced Direct Access Radar Channel Provides a backup to the host computer system (HCS) for radar processing, and radar track and display processing. Provides national monitoring, prediction, planning, re-routing, “ground hold”, and flow management. Provides satellite-based air-to-ground and ground-to-ground communications capability. Provides global navigation signals for use in determining 4-D (dimensional) time/position data. Communications system interface between the En Route Center and external systems. Will process radar surveillance data, associate flight plans with tracks, process flight plans, perform conflict alerts, and process weather data. Provides voice communication services between controllers and aircraft (air-to-ground), and between controllers and other personnel within or among different ATC facilities, such as towers, TRACONs, and Flight Service Stations (ground-to-ground). (continued) Provides integration of terminal area weather products and displays. Provides addressable-beacon interrogation and reply. Provides the capability for digital communications between aircraft, various air traffic control functions, and weather databases through a digital interface with the ATC automation system. Provides capabilities for real-time monitoring and alarm notification, certification parameter data logging, automatic record keeping and information retrieval and trend analysis, failure anticipation, remote control of equipment and facilities, diagnostic and fault isolation, remote adjustments, and system security. National Airspace Data Interchange Network (Packet Switch Network) Provides a packet-switched wide-area data communications network which interconnects major ATC facilities. Provides precipitation, wind velocity, and turbulence data sensing and processing. Replaces several systems, (the Flight Service Automation System, Aviation Weather Processor, and the Flight Service Data Processing System). Provides line-of-sight ultra high frequency (UHF) bearing and range data to aircraft. Provides communciations system for ATC traffic flow managment personnel responsible for management and monitoring of current air traffic flow, aircraft operations, en route sector and airport utilization and loading, and future system utilization. ATC facilities that sequence and separate aircraft as they approach and leave busy airports, beginning about 5 nautical miles and ending about 50 nautical miles from the airport, and generally up to 10,000 feet above the ground, where en route centers’ control begins. Host computer system interface device and en route center local area network that establishes a common interface to the host computer and an updated telecommunications infrastructure. Provides digital communications capability using the VHF radio band. The VOR supports determination of aircraft position and airway definition by transmitting azimuth signals. The DME provides slant range between the aircraft and the DME locations. Provides a voice communications system which performs the intercom, interphone, and air/ground voice connectivity and control functions needed for ATC operations in an en route center. Transmits wide area differential corrections for GPS signals. Provides the capability to use GPS for precision runway approach guidance. Collects, processes and disseminates NEXRAD and other weather information to controllers, traffic management specialists, pilots, and meteorologists. It will provide a mosaic product of multiple NEXRAD information to DSR for display with aircraft targets. FAA unique (Custom Raytheon product) FAA unique (Custom Raytheon operating system) FAA unique (Custom Raytheon language) FAA unique (Custom Raytheon data management software) FAA unique (running prototype of HCS operating system) FAA unique (Custom data management software) FAA unique (Custom made Raytheon product based on Motorola 68000 processors) FAA unique (Custom Raytheon operating system) FAA unique (Custom Raytheon language) FAA unique (Custom Raytheon data management software) Sun Solaris (at least version 2.5) PAMRI is a hardware/firmware data/protocol converter. Randolph C. Hite, Senior Assistant Director Keith A. Rhodes, Technical Assistant Director Madhav S. Panwar, Senior Technical Advisor David A. Powner, Senior Information Systems Analyst Robert C. Reining, Senior Information Systems Analyst The first copy of each GAO report and testimony is free. Additional copies are $2 each. Orders should be sent to the following address, accompanied by a check or money order made out to the Superintendent of Documents, when necessary. VISA and MasterCard credit cards are accepted, also. Orders for 100 or more copies to be mailed to a single address are discounted 25 percent. U.S. General Accounting Office P.O. Box 6015 Gaithersburg, MD 20884-6015 Room 1100 700 4th St. NW (corner of 4th and G Sts. NW) U.S. General Accounting Office Washington, DC Orders may also be placed by calling (202) 512-6000 or by using fax number (301) 258-4066, or TDD (301) 413-0006. Each day, GAO issues a list of newly available reports and testimony. To receive facsimile copies of the daily list or any list from the past 30 days, please call (202) 512-6000 using a touchtone phone. A recorded menu will provide information on how to obtain these lists.

Summary: GAO reviewed the Federal Aviation Administration's (FAA) air traffic control (ATC) modernization effort, focusing on: (1) whether FAA has a target architecture and associated subarchitectures, to guide the development and evolution of its ATC systems; and (2) what, if any, architectural incompatibilities exist among ATC systems and the effect of these incompatibilities. GAO found that: (1) FAA lacks a complete systems architecture, or overall blueprint, to guide and constrain the development and maintenance of the many interrelated systems comprising its ATC infrastructure; (2) FAA is developing one of the two principal components of a complete systems architecture, the "logical" description of FAA's current and future concept of ATC operations as well as descriptions of the ATC business functions to be performed, the associated systems to be used, and the information flows among systems; (3) however, FAA is not developing, nor does it have plans to develop, the second essential component, the ATC-wide "technical" description which defines all required information technology and telecommunications standards and critical ATC systems' technical characteristics; (4) the lack of a complete and enforced systems architecture has permitted incompatibilities among existing ATC systems and will continue to do so for future systems; (5) overcoming these incompatibilities means "higher than need be" system development, integration, and maintenance costs, and reduced overall systems performance; (6) because there are no standards for programming languages or open systems, ATC systems' software has been written in many different application programming languages, often exhibiting proprietary system characteristics; (7) this not only increases software maintenance costs but also effectively precludes sharing software components among systems; (8) without a technical architecture specifying the information technology standards and rules, the opportunity to share software will likely be lost; (9) in some cases, system incompatibilities exist because the technology and standards now available to permit system integration and interoperability did not exist or were only emerging when the systems were designed and developed; (10) other system incompatibilities are the result of FAA's failure to adopt and effectively enforce a technical architecture; (11) by failing to formulate a complete systems architecture, FAA permits and perpetuates inconsistency and incompatibility; (12) as a result, future ATC system development and maintenance will continue to be more difficult and costly than it need be and system performance will continue to be suboptimal; (13) FAA's management structure for developing, maintaining, and enforcing an ATC systems architecture is not effective; and (14) instead, processes now in place permit the acquisition of architecturally non-compliant systems without special waiver of architectural standards.