DOD is a massive and complex organization. To illustrate, the department reported that its fiscal year 2006 operations involved approximately $1.4 trillion in assets and $2.0 trillion in liabilities; more than 2.9 million in military and civilian personnel; and $581 billion in net cost of operations. Organizationally, the department includes the Office of the Secretary of Defense, the Chairman of 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. In support of its military operations, the department performs an assortment of interrelated and interdependent business functions, including 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. Moreover, DOD recently reported that this systems environment is comprised of approximately 3,100 separate business systems. For fiscal year 2006, Congress appropriated approximately $15.5 billion to DOD, and for fiscal year 2007, DOD has requested about $16 billion in appropriated funds to operate, maintain, and modernize these business systems and associated infrastructure. As we have previously reported, the department’s nonintegrated and duplicative systems contribute to fraud, waste, and abuse. In fact, DOD currently bears responsibility, in whole or in part, for 15 of our 27 high-risk areas. 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 enabler to 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 an enterprise architecture—a modernization blueprint—is a hallmark of successful public and private organizations. For more than a decade, we have promoted the use of architectures to guide and constrain systems modernization, recognizing them as a crucial means to this challenging goal: optimally defined operational and technological environments. Congress, the Office of Management and Budget (OMB), and the federal Chief Information Officer’s (CIO) Council have also recognized the importance of an architecture-centric approach to modernization. The Clinger-Cohen Act of 1996 mandates that an agency’s CIO develop, maintain, and facilitate the implementation of an information technology (IT) architecture. Furthermore, the E-Government Act of 2002 requires OMB to oversee the development of enterprise architectures within and across agencies. In addition, we, OMB, and the CIO Council have issued guidance that emphasizes the need for system investments to be consistent with these architectures. An enterprise architecture provides a clear and comprehensive picture of an entity, whether it is an organization (e.g., a federal department) or a functional or mission area that cuts across more than one organization (e.g., financial management). This picture consists of snapshots of both the enterprise’s current (“As Is”) environment and its target (“To Be”) environment. These snapshots consist of “views,” which are one or more interdependent and interrelated architecture products (e.g., models, diagrams, matrices, and text) that provide logical or technical representations of the enterprise. The architecture also includes a transition or sequencing plan, which is based on an analysis of the gaps between the “As Is” and “To Be” environments. This plan provides a temporal road map for moving between the two environments and incorporates such considerations 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 produced 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, architectures can greatly increase the chances that an organization’s operational and IT environments will be configured to optimize mission performance. Our experience with federal agencies has shown that investing in IT without defining these investments in the context of an architecture often results in systems that are duplicative, not well integrated, and unnecessarily costly to maintain and interface. One approach to structuring an enterprise architecture is referred to as a federated enterprise architecture. Such a structure treats the architecture as a family of coherent but distinct member architectures that conform to an overarching architectural view and rule set. This approach recognizes that each member of the federation has unique goals and needs as well as common roles and responsibilities with the levels above and below it. Under a federated approach, member architectures are substantially autonomous, although they also inherit certain rules, policies, procedures, and services from higher-level architectures. As such, a federated architecture enables component organization autonomy, while ensuring enterprisewide linkages and alignment where appropriate. Where commonality among components exists, there are also opportunities for identifying and leveraging shared services. A service-oriented architecture (SOA) is an approach for sharing business capabilities across the enterprise by designing functions and applications as discrete, reusable, and business-oriented services. As such, service orientation permits sharing capabilities that may be under the control of different component organizations. As we have previously reported, such capabilities or services need to be, among other things, (1) self-contained, meaning that they do not depend on any other functions or applications to execute a discrete unit of work; (2) published and exposed as self- describing business capabilities that can be accessed and used; and (3) subscribed to via well-defined and standardized interfaces. A SOA approach is thus not only intended to reduce redundancy and increase integration, but also to provide the kind of flexibility needed to support a quicker response to changing and evolving business requirements and emerging conditions. The Office of the Assistant Secretary of Defense (Networks and Information Integration)/Chief Information Officer (ASD(NII)/CIO), reports that it is developing a strategy for federating the many and varied architectures across the department’s four mission areas—Warfighting, Business, DOD Intelligence, and Enterprise Information Environment. According to ASD(NII)/CIO officials, they are drafting a yet-to-be-released strategy for evolving DOD’s Global Information Grid architecture, so that it provides a comprehensive architectural description of the entire DOD enterprise, including all mission areas and the relationships between and among all levels of the enterprise (e.g., mission areas, components, and programs). Figure 1 provides a simplified depiction of DOD’s EA federation strategy. ASD(NII)/CIO officials stated that the goal of this strategy is to improve the ability of DOD’s mission areas, components, and programs to share architectural information. In this regard, officials stated that the DOD EA federation strategy will define (1) federation and integration concepts, (2) alignment (i.e., linking and mapping) processes, and (3) shared services. The BMA federation strategy, according to these officials, is the first mission area federation strategy, and it is their expectation that the other mission areas will develop their own respective federation strategies. In 2005, the department reassigned responsibility for directing, overseeing, and executing its business transformation and systems modernization efforts to the Defense Business Systems Management Committee (DBSMC) and the Business Transformation Agency (BTA). At that time, it also adopted a tiered accountability approach to business transformation. Under tiered accountability, responsibility and accountability for business architectures and systems investment management was allocated among the DOD enterprise, component, and program levels, depending on such factors as the scope, size, and complexity of each investment. The DBSMC is chaired by the Deputy Secretary of Defense and serves as the highest-ranking governance body for business systems modernization activities. According to its charter, the DBSMC provides strategic direction and plans for the BMA in coordination with the Warfighting and Enterprise Information Environment Mission Areas. The DBSMC is also responsible for reviewing and approving the BEA and the ETP. In addition, the DBSMC recommends policies and procedures required to integrate DOD business transformation and attain cross-department, end-to-end interoperability of business systems and processes. The BTA operates under the authority, direction, and control of the DBSMC and reports to the Under Secretary of Defense for Acquisition, Technology, and Logistics in the incumbent’s capacity as the vice chair of the DBSMC. Oversight for this agency is provided by the Deputy Under Secretary of Defense for Business Transformation, and day-to-day management is provided by the director. The BTA’s primary responsibility is to lead and coordinate business transformation efforts across the department.