The concept of using an architecture to describe an enterprise emerged in the mid-1980s, and over the years, the field of enterprise architecture has continued to evolve and mature. In the early 1990s, we identified an architecture as a critical success factor in allowing organizations to effectively apply IT to meet mission goals. Since then, we have worked with the Congress, OMB, and the CIO Council to promote the importance of architectures and assist agencies in developing, maintaining, and using them. In our reviews of selected agency IT management practices and major systems modernization programs, we have consistently identified the lack of an architecture as a major management weakness and made recommendations to address this important area. To help oversee and budget for federal IT investments, OMB began developing the FEA in 2002, and has since issued versions of four of its five major parts. According to OMB, the FEA is to provide a common, governmentwide framework for agency enterprise architectures and IT investments. Thus far, OMB reports that it has begun using the FEA to identify and address interagency duplication of effort and to launch interagency projects. In simplest terms, an enterprise is any purposeful activity, and an architecture is the structural description of an activity. Building on this, we can view enterprise architectures as systematically derived and captured structural descriptions—in useful models, diagrams, and narrative—of the mode of operation for a given enterprise, which can be either a single organization or a functional or mission area that transcends more than one organizational boundary (e.g., financial management, homeland security). The architecture can also be viewed as a blueprint that links an enterprise’s strategic plan to the programs and supporting systems that it intends to implement to accomplish the mission goals and objectives laid out in the strategic plan. As such, the architecture describes the enterprise’s operations in both logical terms (such as interrelated business processes and business rules, information needs and flows, and work locations and users) and technical terms (such as hardware, software, data, communications, and security attributes and performance standards). Moreover, it provides these perspectives both for the enterprise’s current (or “as-is”) environment and for its targeted future (or “to-be”) environment, as well as for the transition plan for moving from the “as-is” to the “to- be” environment. The importance of enterprise architectures is a basic tenet of IT management, and their effective use is a recognized hallmark of successful public and private organizations. For over a decade, we have promoted the use of architectures, recognizing them as a crucial means to a challenging goal: that is, agency operational structures that are optimally defined, in terms of both business and technology. The alternative, as our work has shown, is perpetuation of the kinds of operational environments that saddle most agencies today, in which the lack of integration among business operations and the IT resources that support them leads to systems that are duplicative, not well integrated, and unnecessarily costly to maintain and interface. Managed properly, an enterprise architecture can clarify and help 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 IT management controls (such as portfolio-based capital planning and investment control practices), architectures can greatly increase the chances that organizations’ operational and IT environments will be configured so as to optimize mission performance. Enterprise architectures are integral to managing large-scale programs in federal departments and agencies, as well as initiatives that span several agencies, such as those currently being undertaken to support OMB’s electronic government (e-government) and “Line of Business” efforts. During the mid-1980s, John Zachman, widely recognized as a leader in the field of enterprise architecture, identified the need to use a logical construction blueprint (i.e., an architecture) for defining and controlling the integration of systems and their components. Accordingly, Zachman developed a structure or framework for defining and capturing an architecture, which provides for six “windows” from which to view the enterprise. Zachman also proposed six abstractions or models associated with each of these perspectives. Zachman’s framework provides a way to identify and describe an entity’s existing and planned component parts, and the relationships between those parts, before the entity begins the costly and time-consuming efforts associated with developing or transforming itself. Since Zachman introduced his framework, a number of frameworks have emerged within the federal government, beginning with the publication of the National Institute of Standards and Technology (NIST) framework in 1989. Since that time, other federal entities have issued enterprise architecture frameworks, including the Department of Defense (DOD) and the Department of the Treasury. In September 1999, the federal CIO Council published the Federal Enterprise Architecture Framework, which was intended to provide federal agencies with a common construct for their architectures, thereby facilitating the coordination of common business processes, technology insertion, information flows, and system investments among federal agencies. The Federal Enterprise Architecture Framework describes an approach, including models and definitions, for developing and documenting architecture descriptions for multiorganizational functional segments of the federal government. In February 2002, OMB established the Federal Enterprise Architecture Program Management Office to develop the FEA, which, according to OMB, is intended to facilitate governmentwide improvement through cross-agency analysis and identification of duplicative investments, gaps, and opportunities for collaboration, interoperability, and integration within and across agency programs. The FEA is composed of five “reference models” describing the federal government’s (1) business (or mission) processes and functions, independent of the agencies that perform them, (2) performance goals and outcome measures, (3) service delivery means, (4) information and data definitions, and (5) technology standards. The reference models are intended to inform agency efforts to develop their agency-specific enterprise architectures and enable agencies to ensure that their proposed investments are not duplicative with those of other agencies and to pursue, where appropriate, joint projects. The FEA reference models are summarized in table 1. Although these post-Zachman frameworks differ in their nomenclatures and modeling approaches, most provide for defining an enterprise’s operations in both logical terms and technical terms, provide for defining these perspectives for the enterprise’s current and target environments, and call for a transition plan between the two. Several laws and regulations have established requirements and guidance for agencies’ management of architectures, beginning with the Clinger-Cohen Act in 1996, which directs the CIOs of major departments and agencies to develop, maintain, and facilitate the implementation of IT architectures as a means of integrating agency goals and business processes with IT. OMB Circular A-130, which implements the Clinger-Cohen Act, requires that agencies document and submit their initial enterprise architectures to OMB and updates when significant changes to their architectures occur. The circular also directs the OMB Director to use various kinds of reviews to evaluate the adequacy and efficiency of agency compliance with the circular. OMB was given explicit responsibility for overseeing government enterprise architectures by the E-Government Act of 2002, which established the Office of Electronic Government within the office. More specifically, it gives OMB the responsibility for facilitating the development of enterprise architectures within and across agencies and supporting improvements in government operations through the use of IT. We began reviewing federal agencies’ use of architectures in 1994, initially focusing on those agencies that were pursuing major systems modernization programs that were high risk. These included the National Weather Service systems modernization, the Federal Aviation Administration air traffic control modernization,and the Internal Revenue Service tax systems modernization. Generally, we reported that these agencies’ enterprise architectures were incomplete, and we made recommendations that they develop and implement complete enterprise architectures to guide their modernization efforts. Since then, we have reviewed architecture efforts at other federal agencies, including the Department of Education, the former Customs Service, the former Immigration and Naturalization Service, the Centers for Medicare and Medicaid Services, the Department of Defense (DOD), the Federal Bureau of Investigation, and the National Aeronautics and Space Administration. These reviews have identified the absence of complete and enforced enterprise architectures, which has led to agency business operations, systems, and data that are not integrated and that are duplicative and incompatible. These conditions, in turn, have either prevented agencies from sharing data or forced them to do so through inefficient manual processes or costly, custom-developed system interfaces. To contribute to the evolution and maturity of the enterprise architecture discipline, in 2002, we published version 1.0 of our Enterprise Architecture Management Maturity Framework (EAMMF) as an extension of A Practical Guide to Federal Enterprise Architecture, Version 1.0, published by the CIO Council. By arranging core elements from the practical guide into a matrix of five hierarchical stages and four critical success attributes, this framework provides a common benchmarking tool for planning and measuring enterprise architecture efforts. In April 2003, we published version 1.1 of this framework, which reflects changes and additions that are based on comments we received on the initial version, as well as on our experiences in reviewing enterprise architecture programs. EAMMF version 1.0 is made up of five stages of maturity, each of which includes an associated set of elements along with all the elements of the previous stages. In addition to the maturity stages, each core element is associated with attributes that are critical to the successful performance of any management function. Figure 1 shows a summary of version 1.0 of the framework and shows the key elements with the associated stages and attributes. Version 1.1 of this framework was released in April 2003. Like the initial version, Version 1.1 is based on the CIO Council guidance, augmented by our experience in reviewing agency architecture programs. Changes and additions to the framework were also based on comments received from federal agencies on the initial version. Figure 2 shows a summary of Version 1.1.