DOD is a massive and complex organization entrusted with more taxpayer dollars than any other federal department or agency. Organizationally, the department includes the Office of the Secretary of Defense, the Joint Chiefs of Staff, the military departments, numerous defense agencies and field activities, and various unified combatant commands that are responsible for either specific geographic regions or specific functions. (See fig. 1 for a simplified depiction of DOD’s organizational structure.) In support of its military operations, DOD performs an assortment of interrelated and interdependent business functions, such as logistics management, procurement, health care management, and financial management. As we have previously reported, the DOD systems environment that supports these business functions is overly complex and error prone, and is characterized by (1) little standardization across the department, (2) multiple systems performing the same tasks, (3) the same data stored in multiple systems, and (4) the need for data to be entered manually into multiple systems. The department recently requested about $17.3 billion for its business systems environment and IT infrastructure investments for fiscal year 2012. According to the department’s systems inventory, this environment is composed of 2,258 business systems and includes 335 financial management, 709 human resource management, 645 logistics, 243 real property and installation, and 281 weapon acquisition management systems. DOD currently bears responsibility, in whole or in part, for 14 of the 30 programs across the federal government that we have designated as high risk because they are highly susceptible to fraud, waste, abuse, and mismanagement. Seven of these areas are specific to the department, and seven other high-risk areas are shared with other federal agencies. Collectively, these high-risk areas relate to DOD’s major business operations that are inextricably linked to the department’s ability to perform its overall mission and directly affect the readiness and capabilities of U.S. military forces and can affect the success of a mission. In particular, the department’s nonintegrated and duplicative systems impair its ability to combat fraud, waste, and abuse. As such, DOD’s business systems modernization is one of the high-risk areas and is an essential enabler in 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. Effective use of a well-defined enterprise architecture is a hallmark of successful organizations and a basic tenet of organizational transformation and systems modernization. Since the early 1990s, we have promoted federal department and agency enterprise architecture adoption as an essential means to achieving a desired end: having operational and technology environments that maximize institutional mission performance and outcomes. Congress, the Office of Management and Budget (OMB), and the federal Chief Information Officers (CIO) Council have also recognized the importance of an architecture-centric approach to modernization. The Clinger-Cohen Act of 1996, among other things, requires the CIOs of federal departments and agencies to develop, maintain, and facilitate architectures as a means of integrating business processes and agency goals with IT. Further, the E-Government Act of 2002 established the OMB Office of Electronic Government and assigned it, among other things, responsibility for overseeing the development of enterprise architectures within and across agencies. In addition, OMB, the CIO Council, and we have issued guidance that emphasizes the need for system investments to be consistent with these architectures. For example, in April 2003 and in August 2010, we published a framework that emphasizes the importance of having an enterprise architecture as a critical frame of reference for organizations when they are making IT investment decisions. Also, in December 2008, OMB issued guidance that addresses system investment compliance with agency architectures. A corporate approach to IT investment management is another important characteristic of successful public and private organizations. Recognizing this, the Clinger-Cohen Act requires OMB to establish processes to analyze, track, and evaluate the risks and results of major capital investments in IT systems made by executive agencies. In response to the Clinger-Cohen Act and other statutes, OMB developed policy and issued guidance for planning, budgeting, acquisition, and management of federal capital assets. We have also issued guidance in this area that defines institutional structures (such as investment boards), processes for developing information on investments (such as cost/benefit), and practices to inform management decisions (such as whether a given investment is aligned with an enterprise architecture). An enterprise architecture provides a clear and comprehensive picture of an entity, whether it is an organization (e.g., a federal department or agency) or a functional or mission area that cuts across more than one organization (e.g., financial management). 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 environment and for its target environment, and it provides a transition plan for moving from the current to the target environment. This transition plan provides a temporal road map for moving between the two environments and incorporates considerations such as technology opportunities, marketplace trends, fiscal and budgetary constraints, institutional system development and acquisition capabilities, legacy and new system dependencies and life expectancies, and the projected value of competing investments. The suite of products adopted for a given entity’s enterprise architecture, including its structure and content, is largely governed by the framework used to develop the architecture. Since the 1980s, various architecture frameworks have been developed, such as John A. Zachman’s “A Framework for Information Systems Architecture,” and the DOD Architecture Framework. The importance of developing, implementing, and maintaining an enterprise architecture is a basic tenet of both organizational transformation and systems modernization. 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. Moreover, when an enterprise architecture is employed in concert with other important management controls, such as portfolio-based capital planning and investment control practices, the architecture can greatly increase the chances that an organization’s operational and IT environments will be configured to optimize mission performance. The alternative, as our work has shown, is the perpetuation of the kinds of operational environments that burden many 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. In February 2002 and April 2003, we issued versions 1.0 and 1.1 of our Enterprise Architecture Management Maturity Framework; in August 2010, we issued a major revision (version 2.0). The framework provides a standard yet flexible benchmark against which to determine where the enterprise stands in its progress toward the ultimate goal: having a continuously improving enterprise architecture program that can serve as a featured decision support tool when considering and planning large- scale organizational restructuring or transformation initiatives. In addition, it also provides a basis for developing architecture management improvement plans, as well as for measuring, reporting, and overseeing progress in implementing these plans. Several approaches to structuring enterprise architecture exist and can be applied to the extent that they are relevant and appropriate for a given enterprise. In general, these approaches provide for decomposing an enterprise into its logical parts and architecting each of the parts in relation to enterprisewide needs and the inherent relationships and dependencies that exist among the parts. As such, the approaches are fundamentally aligned and consistent with a number of basic enterprise architecture principles, such as incremental rather than monolithic architecture development and implementation, optimization of the whole rather than optimization of the component parts, and maximization of shared data and services across the component parts rather than duplication. Moreover, these approaches are not mutually exclusive and, in fact, can all be applied to some degree for a given enterprise, depending on the characteristics and circumstances of that enterprise. The approaches, which are briefly described here, are federated, segmented, and service-oriented. Under a federated approach, the architecture consists of a family of coherent but distinct member architectures that conform to an overarching corporate or parent architecture. This approach recognizes that each federation member has unique goals and needs as well as common roles and responsibilities with the members above and below it. As such, member architectures (e.g., component, subordinate, or subsidiary architectures) are substantially autonomous, but they also inherit certain rules, policies, procedures, and services from the parent architectures. A federated architecture enables component organization autonomy while ensuring corporate or enterprisewide linkages and alignment where appropriate. A segmented approach to enterprise architecture development and use, like a federated approach, employs a “divide and conquer” methodology in which architecture segments are identified, prioritized, developed, and implemented. In general, segments can be viewed as logical aspects, or “slivers,” of the enterprise that can be architected and pursued as separate initiatives under the overall corporate architecture. As such, the segments serve as a bridge between the corporate frame of reference captured in the enterprise architecture and individual programs within portfolios of system investments. OMB has issued guidance related to segment architectures. As part of its guidance, agencies are to group segments into three categories: core mission areas (e.g., air transportation), business services (e.g., financial management), and enterprise services (e.g., records management). A service-oriented approach to enterprise architecture is intended to identify and promote the shared use of common business capabilities across the enterprise. Under this approach, functions and applications are defined and designed as discrete and reusable capabilities or services that may be under the control of different organizational entities.