DOD is a massive and complex organization. To illustrate, the department reported that its fiscal year 2007 operations involved approximately $1.5 trillion in assets and $2.1 trillion in liabilities, more than 2.9 million military and civilian personnel, and $544 billion in net cost of operations. In support of its military operations, the department performs an assortment of interrelated and interdependent business functions—using thousands of business systems—related to major business areas such as weapon systems management, supply chain management, procurement, health care management, and financial management. The ability of these systems to operate as intended affects the lives of our warfighters both on and off the battlefield. As we have previously reported, the DOD systems environment that supports these business functions is overly complex; error-prone; and characterized by little standardization across the department, multiple systems performing the same tasks, the same data stored in multiple systems, and the need for data to be entered manually into multiple systems. Moreover, DOD recently reported that this systems environment is comprised of approximately 3,000 separate business systems. For fiscal year 2007, Congress appropriated approximately $15.7 billion to DOD; for fiscal year 2008, DOD has requested about $15.9 billion in appropriated funds to operate, maintain, and modernize these business systems and the associated infrastructures, of which approximately $11 billion was requested for the military departments. DOD’s pervasive business system and related financial management deficiencies adversely affect its ability to assess resource requirements; control costs; ensure basic accountability; anticipate future costs and claims on the budget; measure performance; maintain funds control; prevent and detect fraud, waste, and abuse; and address pressing management issues. In fact, DOD currently bears responsibility, in whole or in part, for 15 of the 27 federal government’s program areas that we have designated as high risk. Eight of these areas are specific to DOD and the department shares responsibility for 7 other governmentwide high-risk areas. DOD’s business systems modernization is one of the high-risk areas, and it is an essential component for addressing many of the department’s other high-risk areas. For example, modernized business systems are integral to the department’s efforts to address its financial, supply chain, and information security management high-risk areas. A well-defined and effectively implemented enterprise architecture is, in turn, integral to the successful modernization of DOD’s business systems. An enterprise architecture (EA) is a blueprint that describes an organization’s or a functional area’s current and desired state in both logical and technical terms, as well as a plan for transitioning between the two states. As such, it is a recognized tenet of organizational transformation and IT management in public and private organizations. Without an EA, it is unlikely that an organization will be able to transform business processes and modernize supporting systems to minimize overlap and maximize interoperability. For more than a decade, we have conducted work to improve agency architecture efforts. To this end, we developed the Enterprise Architecture Management Maturity Framework (EAMMF) that provides federal agencies with a common benchmarking tool for assessing the management of their EA 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 or homeland security). An architecture can be viewed as the structure (or structural description) of any activity. Thus, EAs are systematically derived and captured descriptions depicted in models, diagrams, and narratives. 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, 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, and it provides a transition plan for moving from the “as-is” to the “to-be” environment. The importance of EAs 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 saddle many 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. 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 to optimize mission performance. The concept of EAs originated in the mid-1980s; various frameworks for defining the content of these architectures have been published by government agencies and the Office of Management and Budget (OMB). Moreover, legislation and federal guidance requires agencies to develop and use architectures. (See appendix III for a brief description of architecture frameworks and related legislation and management guidance.) In 2002, we developed version 1.0 of the EAMMF to provide federal agencies with a common benchmarking tool for planning and measuring their efforts to improve enterprise architecture management, as well as to provide OMB with a means for doing the same governmentwide. We issued an update of the framework (version 1.1) in 2003. This framework is an extension of A Practical Guide to Federal Enterprise Architecture, Version 1.0, published by the Chief Information Officers Council. Version 1.1 of the framework arranges 31 core elements (practices or conditions that are needed for effective enterprise architecture management) into a matrix of five hierarchical maturity stages and four critical success attributes that apply to each stage. Within a given stage, each critical success attribute includes between one and four core elements. Based on the implicit dependencies among the core elements, the EAMMF associates each element with one of five maturity stages (see fig. 1). The core elements can be further categorized by four groups: architecture governance, content, use, and measurement. Stage 1: Creating enterprise architecture awareness. At Stage 1, either an organization does not have plans to develop and use an architecture, or it has plans that do not demonstrate an awareness of the value of having and using an architecture. While Stage 1 agencies may have initiated some enterprise architecture activity, these agencies’ efforts are ad hoc and unstructured, lack institutional leadership and direction, and do not provide the management foundation necessary for successful enterprise architecture development as defined in Stage 2. Stage 2: Building the enterprise architecture management foundation. An organization at Stage 2 recognizes that the EA is a corporate asset by vesting accountability for it in an executive body that represents the entire enterprise. At this stage, an organization assigns architecture management roles and responsibilities and establishes plans for developing architecture products and for measuring program progress and product quality; it also commits the resources necessary for developing an architecture—people, processes, and tools. Specifically, a Stage 2 organization has designated a chief architect and established and staffed a program office responsible for EA development and maintenance. Further, it has established a committee or group that has responsibility for governance (i.e., directing, overseeing, and approving architecture development and maintenance). This committee or group membership has enterprisewide representation. At Stage 2, the organization either has plans for developing or has started developing at least some architecture products, and it has developed an enterprisewide awareness of the value of enterprise architecture and its intended use in managing its IT investments. The organization has also selected a framework and a methodology that will be the basis for developing the architecture products and has selected a tool for automating these activities. Stage 3: Developing the enterprise architecture. An organization at Stage 3 focuses on developing architecture products according to the selected framework, methodology, tool, and established management plans. Roles and responsibilities assigned in the previous stage are in place, and resources are being applied to develop actual products. At this stage, the scope of the architecture has been defined to encompass the entire enterprise, whether organization-based or function-based. Although the products may not be complete, they are intended to describe the organization in terms of business, performance, information/data, service/application, and technology (including security explicitly in each), as provided for in the framework, methodology, tool, and management plans. Further, the products are to describe the current (“as-is”) and future (“to-be”) states and the plan for transitioning from the current to the future state (the sequencing plan). As the products are developed and evolve, they are subject to configuration management. Further, through the established enterprise architecture management foundation, the organization is tracking and measuring its progress against plans, identifying and addressing variances, as appropriate, and then reporting on its progress. Stage 4: Completing the enterprise architecture. An organization at Stage 4 has completed its architecture products, meaning that the products have been approved by the EA steering committee (established in Stage 2) or an investment review board and by the Chief Information Officer (CIO). The completed products collectively describe the enterprise in terms of business, performance, information/data, service/application, and technology for both its current and future operating states; the products also include a plan for transitioning from the current to the future state. Further, an independent agent has assessed the quality (i.e., completeness and accuracy) of the architecture products. Additionally, evolution of the approved products is governed by a written EA maintenance policy approved by the head of the organization. Stage 5: Leveraging the enterprise architecture to manage change.