An enterprise architecture is a blueprint that describes the current and desired state of an organization or functional area in both logical and technical terms, as well as a plan for transitioning between the two states. Enterprise architectures are a recognized tenet of organizational transformation and IT management in public and private organizations. Without an enterprise architecture, it is unlikely that an organization will be able to transform business processes and modernize supporting systems to minimize overlap and maximize interoperability. The concept of enterprise architectures originated in the mid-1980s; various frameworks for defining the content of these architectures have been published by government agencies and OMB. Moreover, legislation and federal guidance requires agencies to develop and use architectures. For more than a decade, we have conducted work to improve agency architecture efforts. To this end, we developed an enterprise architecture management maturity framework that provides federal agencies with a common benchmarking tool for assessing the management of their enterprise architecture efforts and developing improvement plans. An enterprise can be viewed as either a single organization or a functional area that transcends more than one organization (e.g., financial management, homeland security). An architecture can be viewed as the structure (or structural description) of any activity. Thus, enterprise architectures are basically systematically derived and captured descriptions—in useful models, diagrams, and narrative. More specifically, an architecture describes the enterprise in logical terms (such as interrelated business processes and business rules, information needs and flows, and work locations and users) as well as in technical terms (such as hardware, software, data, communications, and security attributes and performance standards). It provides these perspectives both for the enterprise’s current or “as-is” environment and for 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 enterprise architectures is a basic tenet of both organizational transformation and 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 end: optimized agency operations and performance. The alternative, as our work has shown, is the perpetuation of the kinds of operational environments that burden most agencies today, where a lack of integration among business operations and the IT resources supporting them leads to systems that are duplicative, poorly integrated, and unnecessarily costly to maintain and interface. 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 the organizations’ operational and IT environments will be configured so as to optimize mission performance. 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 perspectives or “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 parts’ relationships 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 frameworks, including the Department of Defense (DOD) and the Department of the Treasury. In September 1999, the federal Chief Information Officers (CIO) Council published the Federal Enterprise Architecture Framework (FEAF), 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 FEAF described an approach, including models and definitions, for developing and documenting architecture descriptions for multi-organizational functional segments of the federal government. More recently, OMB established the Federal Enterprise Architecture Program Management Office (FEAPMO) to develop a federal enterprise architecture according to a collection of five reference models (see table 1). These models are intended to facilitate governmentwide improvement through cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration, interoperability, and integration within and across government agencies. OMB has identified multiple purposes for the Federal Enterprise Architecture, such as the following: informing agency enterprise architectures and facilitating their development by providing a common classification structure and vocabulary; providing a governmentwide framework that can increase agency awareness of IT capabilities that other agencies have or plan to acquire, so that they can explore opportunities for reuse; helping OMB decision makers identify opportunities for collaboration among agencies through the implementation of common, reusable, and interoperable solutions; and providing the Congress with information that it can use as it considers the authorization and appropriation of funding for federal programs. Although these post-Zachman frameworks differ in their nomenclatures and modeling approaches, each consistently provides for defining an enterprise’s operations in both logical and technical terms, provides for defining these perspectives for the enterprise’s current and target environments, and calls for a transition plan between the two. Several laws and regulations address enterprise architecture. For example, the Clinger-Cohen Act of 1996 directs the CIOs of major departments and agencies to develop, maintain, and facilitate the implementation of information technology architectures as a means of integrating agency goals and business processes with information technology. Also, OMB Circular A-130, which implements the Clinger-Cohen Act, requires that agencies document and submit their initial enterprise architectures to OMB and that agencies submit updates when significant changes to their enterprise architectures occur. The circular also directs OMB to use various reviews to evaluate the adequacy and efficiency of each agency’s compliance with the circular. We began reviewing federal agencies’ use of enterprise 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 (FAA) 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 enterprise architecture management at other federal agencies, including the Department of Education (Education), the Customs Service, the Immigration and Naturalization Service, the Centers for Medicare and Medicaid Services, FAA, and the Federal Bureau of Investigation (FBI). We have also reviewed the use of enterprise architectures for critical agency functional areas, such as the integration and sharing of terrorist watch lists across key federal departments and DOD financial management, logistics management, combat identification, and business systems modernization. These reviews continued to identify the absence of complete and enforced enterprise architectures, which in turn has led to agency business operations, systems, and data that are duplicative, incompatible, and not integrated; these conditions have either prevented agencies from sharing data or forced them to depend on expensive, custom-developed system interfaces to do so. Accordingly, we made recommendations to improve the respective architecture efforts. In some cases progress has been made, such as at DOD and FBI. As a practical matter, however, considerable time is needed to completely address the kind of substantive issues that we have raised and to make progress in establishing more mature architecture programs. In 2002 and 2003, we also published reports on the status of enterprise architectures governmentwide. The first report (February 2002) showed that about 52 percent of federal agencies self-reported having at least the management foundation that is needed to successfully develop, implement, and maintain an enterprise architecture, and that about 48 percent of agencies had not yet advanced to that basic stage of maturity. We attributed this state of architecture management to four management challenges: (1) overcoming limited executive understanding, (2) inadequate funding, (3) insufficient number of skilled staff, and (4) organizational parochialism. Additionally, we recognized OMB’s efforts to promote and oversee agencies’ enterprise architecture efforts. Nevertheless, we determined that OMB’s leadership and oversight could be improved by, for example, using a more structured means of measuring agencies’ progress and by addressing the above management challenges. The second report (November 2003) showed the percentage of agencies that had established at least a foundation for enterprise architecture management was virtually unchanged. We attributed this to long-standing enterprise architecture challenges that had yet to be addressed. In particular, more agencies reported lack of agency executive understanding of enterprise architecture and the scarcity of skilled architecture staff as significant challenges. OMB generally agreed with our findings and the need for additional agency assessments. Further, it stated that fully implementing our recommendations would require sustained management attention, and that it had begun by working with the CIO Council to establish the Chief Architect Forum and to increase the information OMB reports on enterprise architecture to Congress. Since then, OMB has developed and implemented an enterprise architecture assessment tool. According to OMB, the tool helps better understand the current state of an agency’s architecture and assists agencies in integrating architectures into their decision-making processes. The latest version of the assessment tool (2.0) was released in December 2005 and includes three capability areas: (1) completion, (2) use, and (3) results. Table 2 describes each of these areas. The tool also includes criteria for scoring an agency’s architecture program on a scale of 0 to 5. In early 2006, the major departments and agencies were required by OMB to self assess their architecture programs using the tool. OMB then used the self assessment to develop its own assessment. These assessment results are to be used in determining the agency’s e- Government score within the President’s Management Agenda.