United States Government Accountability Office

GAO Report to Congressional Committees

BUSINESS SYSTEMS 

MODERNIZATION 

Strategy for Evolving 

DOD’s Business 

Enterprise 

Architecture Offers a 

Conceptual Approach, 

but Execution Details 

Are Needed 

April 2007 

 

GAO-07-451 
What GAO Found

United States Government Accountability Office

Why GAO Did This Study

Highlights

Accountability Integrity Reliability

April 2007

BUSINESS SYSTEMS MODERNIZATION

Strategy for Evolving DOD's Business 

Enterprise Architecture Offers a 

Conceptual Approach, but Execution 

Details Are Needed 

Highlights of GAO-07-451, a report to 

congressional committees 

In 1995, we first designated the 

Department of Defense’s (DOD)

business systems modernization 

program as “high risk,” and we 

continue to designate it as such

today. To assist in addressing this 

high-risk area, Congress passed 

legislation consistent with prior 

GAO recommendations for Defense 

to develop a business enterprise 

architecture (BEA). In September 

2006, DOD released version 4.0 of 

its BEA, which despite 

improvements over prior versions, 

was not aligned with component 

architectures. Subsequently, 

Defense issued a strategy for 

extending its BEA to the 

component military services and 

defense agencies. To support 

GAO’s legislative mandate to

review DOD’s BEA, GAO assessed 

DOD’s progress in defining this 

strategy by comparing it with prior

findings and recommendations

relevant to the strategy’s content.

What GAO Recommends

To assist DOD in its efforts to 

evolve and extend its BEA, GAO is 

augmenting a prior 

recommendation to the Secretary 

of Defense for developing an 

architecture development 

management plan by

recommending that this plan

incorporate details needed to 

execute DOD’s Business Mission 

Area federation strategy. In 

comments, DOD largely disagreed 

with GAO’s recommendation, 

noting that elements of it were

either unnecessary or not 

appropriately focused. 

DOD’s Business Mission Area federation strategy for extending its BEA to 

the military departments and defense agencies provides a foundation on 

which to build and align the department’s parent business architecture (the 

BEA) with its subordinate architectures (i.e., component- and program-level 

architectures). (See figure.) In particular, the strategy, which was released in 

September 2006, states the department’s federated architecture goals; 

describes federation concepts that are to be applied; and explains high-level 

activities, capabilities, products, and services that are intended to facilitate 

implementation of the concepts. 

Simplified Diagram of DOD’s Business Mission Area Federated Architecture 

Source: GAO analysis of DOD data.

Enterprise Shared Services and System Capabilities

Enterprise Rules and Standards for Interoperability

Army Navy AF TRANS

COM

DLA DFAS

Enterprise Shared Services and System Capabilities

Enterprise Rules and Standards for Interoperability

Enterprise Shared Services and System Capabilities

DOD BEA and Enterprise Transition Plan

Enterprise Rules and Standards for Interoperability

Army Navy AF

Component Layer DOD-Enterprise 

Layer

Business

Transformation 

Agency

United States

Transportation 

Command

Defense 

Finance and 

Accounting

Service

Defense 

Logistics

Agency

Army Navy Air Force

Programs Programs Programs Programs Programs Programs

However, the strategy does not adequately define the tasks needed to 

achieve the strategy’s goals, including those associated with executing highlevel activities and providing related capabilities, products, and services. 

Specifically, it does not adequately address how strategy execution will be 

governed, including assignment of roles and responsibilities, measurement 

of progress and results, and provision of resources. Also, the strategy does 

not address, among other things, how the component architectures will be 

aligned with the latest version of the BEA and how it will identify and 

provide for reuse of common applications and systems across the 

department. According to program officials, the department intends to 

develop more detailed plans to execute the strategy. This means that much 

remains to be decided and accomplished before DOD will have the means in 

place to create a federated BEA that satisfies GAO’s prior recommendations 

and legislative requirements. Without one, the department will remain 

challenged in its ability to minimize duplication and maximize 

interoperability among its thousands of business systems. 

www.gao.gov/cgi-bin/getrpt?GAO-07-451.

To view the full product, including the scope 

and methodology, click on the link above. 

For more information, contact Randolph C. 

Hite at (202) 512-3439 or hiter@gao.gov. 
Contents 

Letter 1

Results in Brief 3

Background 5

DOD Is in the Early Stages of Federating Its BEA and Much 

Remains to Be Decided and Accomplished 15 

Conclusions 24

Recommendation for Executive Action 24 

Agency Comments and Our Evaluation 25 

Appendix I Objective, Scope, and Methodology 30 

Appendix II Comments from the Department of Defense 31 

Appendix III GAO Contact and Staff Acknowledgments 38 

Tables 

Table 1: Number of Framework Elements That Were Fully, 

Partially, and Not Satisfied by the Military Departments 14 

Table 2: High-level Steps for Achieving Operational and Systems 

View Federation 18 

Figures 

Figure 1: Simplified Depiction of the DOD Enterprise Architecture 

Federation Strategy 10 

Figure 2: Simplified Diagram of DOD’s Business Mission Area 

Federated Architecture 17 

Page i GAO-07-451 Business Systems Modernization
Abbreviations 

ASD(NII)/CIO Assistant Secretary of Defense (Networks and 

 Information Integration)/Chief Information Officer 

BEA business enterprise architecture 

BMA Business Mission Area 

BTA Business Transformation Agency 

CIO Chief Information Officer 

DBSMC Defense Business Systems Management Committee 

DISA Defense Information Systems Agency

DLA Defense Logistics Agency

DOD Department of Defense 

EA enterprise architecture

ETP enterprise transition plan 

IT information technology 

OMB Office of Management and Budget 

SOA service-oriented architecture 

This is a work of the U.S. government and is not subject to copyright protection in the 

United States. It may be reproduced and distributed in its entirety without further 

permission from GAO. However, because this work may contain copyrighted images or 

other material, permission from the copyright holder may be necessary if you wish to 

reproduce this material separately. 

Page ii GAO-07-451 Business Systems Modernization
United States Government Accountability Office

Washington, DC 20548 

April 16, 2007

Congressional Committees 

For decades, the Department of Defense (DOD) has been challenged in 

repeated attempts to modernize its timeworn business systems.1 In 1995, 

we designated DOD’s business systems modernization program as “high 

risk,” and we continue to designate it as such today.2

 As our research on 

public and private sector organizations has shown, one essential 

ingredient to a successful systems modernization program is having and 

using a well-defined enterprise architecture (EA).3

Accordingly, we made recommendations to the Secretary of Defense in 

May 2001 that included the means for effectively developing an EA.4

 In July 

2001, the department initiated a business management modernization 

program to, among other things, develop one. Between 2001 and 2005, we 

reported that the department’s business management modernization 

program was not being effectively managed, concluding in 2005 that 

hundreds of millions of dollars had been spent on a business enterprise 

 1

Business systems are information systems that include financial and nonfinancial systems

and support DOD’s business operations, such as civilian personnel, finance, health, 

logistics, military personnel, procurement, and transportation. 

2

GAO, High-Risk Series: An Update, GAO-07-310 (Washington, D.C.: January 2007). 

3

An EA, or modernization blueprint, provides a clear and comprehensive picture of an

entity, whether it is an organization (e.g., federal department or agency) or a functional or

mission area that cuts across more than one organization (e.g., financial management).

This picture consists of snapshots of the enterprise’s current “As Is” operational and 

technological environment and its target or “To Be” environment, as well as a capital 

investment road map for transitioning from the current to the target environment. These 

snapshots further consist of “views,” which are one or more architecture products that 

provide conceptual or logical representations of the enterprise. 

4

GAO, Information Technology: Architecture Needed to Guide Modernization of DOD’s 

Financial Operations, GAO-01-525 (Washington, D.C.: May 17, 2001). 

Page 1 GAO-07-451 Business Systems Modernization
architecture (BEA) that had limited use.5

 Accordingly, we made additional

architecture-related recommendations. 

To assist DOD in addressing its modernization management challenges, 

Congress included provisions in the Ronald W. Reagan National Defense 

Authorization Act for Fiscal Year 20056

 that were consistent with our 

recommendations, including those for developing a BEA and associated 

enterprise transition plan (ETP). In 2006,

7

 we reported that, among other 

things, DOD had made important progress in developing its BEA, but that 

much remained to be accomplished relative to the act’s requirements and 

relevant guidance. For example, we reported that the BEA was not 

adequately linked to the military departments and defense agency 

architectures. To address these shortfalls, DOD issued a strategy for 

“federating” or extending its architecture. 

To support GAO’s legislative mandate to review DOD’s BEA and as agreed 

with your offices, the objective of this review was to determine DOD’s 

progress in defining its Business Mission Area (BMA) federation strategy. 

To accomplish our objective, we compared the federation strategy and 

associated plans with prior findings and recommendations relative to the 

content of the strategy, and interviewed DOD officials regarding the 

strategy’s executability. We performed our work at DOD headquarters in 

Arlington, Virginia, from August 2006 through March 2007 in accordance

 5

See, for example, GAO-01-525; GAO, DOD Business Systems Modernization: 

Improvements to Enterprise Architecture Development and Implementation Efforts 

Needed, GAO-03-458 (Washington, D.C.: Feb. 28, 2003); Information Technology: 

Observations on Department of Defense’s Draft Enterprise Architecture, GAO-03-571R 

(Washington, D.C.: Mar. 28, 2003); Business Systems Modernization: Summary of GAO’s 

Assessment of the Department of Defense’s Initial Business Enterprise Architecture, 

GAO-03-877R (Washington, D.C.: July 7, 2003); DOD Business Systems Modernization: 

Important Progress Made to Develop Business Enterprise Architecture, but Much Work 

Remains, GAO-03-1018 (Washington, D.C.: Sept. 19, 2003); DOD Business Systems 

Modernization: Limited Progress in Development of Business Enterprise Architecture 

and Oversight of Information Technology Investments, GAO-04-731R (Washington, D.C.: 

May 17, 2004); DOD Business Systems Modernization: Billions Being Invested without 

Adequate Oversight, GAO-05-381 (Washington, D.C.: Apr. 29, 2005); and DOD Business 

Systems Modernization: Long-standing Weaknesses in Enterprise Architecture

Development Need to Be Addressed, GAO-05-702 (Washington, D.C.: July 22, 2005). 

6

Ronald W. Reagan National Defense Authorization Act for Fiscal Year 2005, Pub. L.

No. 108-375, § 332, 118 Stat. 1811, 1851-1856 (Oct. 28, 2004) (codified in part at 

10 U.S.C. § 2222). 

7

GAO, Business Systems Modernization: DOD Continues to Improve Institutional 

Approach, but Further Steps Needed, GAO-06-658 (Washington, D.C.: May 15, 2006). 

Page 2 GAO-07-451 Business Systems Modernization
with generally accepted government auditing standards. Additional details 

on our objective, scope, and methodology are contained in appendix I. 

DOD’s BMA federation strategy, which was released in September 2006, 

provides a foundation on which to build and align the department’s parent 

business architecture (the BEA) with its subordinate architectures (i.e., 

component- and program-level architectures). In particular, this strategy 

states the department’s federated architecture goals; describes federation 

concepts that are to be applied; and explains high-level activities, 

capabilities, products, and services that are intended to facilitate 

implementation of the concepts. 

Results in Brief 

However, the strategy does not adequately define the tasks needed to

achieve the strategy’s goals, including those associated with executing

high-level activities and providing related capabilities, products, and 

services. Specifically, it does not adequately address how strategy 

execution will be governed, including assignment of roles and 

responsibilities, measurement of progress and results, and provision of 

resources. In addition, the strategy does not clearly describe the 

relationships, dependencies, and touch points with other federation 

strategies. Also, the strategy does not address, among other things, how 

the architectures of the military departments will align with the latest 

version of the BEA and how DOD will identify and provide for sharing of 

common applications and systems across the department. Moreover, the 

strategy does not include milestones for executing the activities and 

related capabilities, products, and services. 

According to program officials, the department is in the early stages of 

defining and implementing its strategy and intends to develop more 

detailed plans. As a result, much remains to be decided and accomplished 

before DOD will have in place the means to create a federated 

architecture, and thus be able to satisfy both our prior recommendations 

and legislative requirements aimed at adopting an architecture-centric 

approach to departmentwide business systems investment management. 

To assist DOD in its efforts to evolve and extend its BEA, we are 

augmenting our prior recommendation to the Secretary of Defense to 

develop an integrated architecture development management plan8

 by 

 8

GAO-06-658. 

Page 3 GAO-07-451 Business Systems Modernization
recommending that this plan provide for effective execution of its BMA 

federation strategy. 

In written comments on a draft of this report, signed by the DOD Deputy 

Chief Information Officer and the Deputy Under Secretary of Defense 

(Business Transformation) and reprinted in appendix II, the department 

largely disagreed with our recommendation for two primary reasons. 

First, the department stated that three of the five elements in our 

recommendation have either already been addressed through policy or are 

embedded in a prior recommendation. Specifically, it said that the element 

relating to ensuring alignment with other federation strategies is not 

needed because the DOD EA federation strategy is the single architecture 

federation strategy for the department and the other architecture 

federation strategies supplement this overarching strategy. We do not 

question the department’s comment about the relationships among the 

strategies. However, we believe that this element of our recommendation 

is needed because its intent is to recognize these relationships by 

promoting collaboration and ensuring linkages among the various 

strategies. DOD also stated that the element of our recommendation 

relating to component architecture alignment with incremental versions of 

the BEA has been implemented both in policy and execution to comply 

with legislative requirements, to include DOD’s development and use of 

the Architecture Compliance and Requirements Traceability tool. We 

disagree. While we recognize DOD’s efforts to align programs to the BEA, 

our recommendation focuses on the lack of a discussion in the BMA 

federation strategy on how component architectures will be linked to the 

BEA, including the lack of component architecture alignment guidance,

criteria, and tools. Lastly, DOD stated that the element of our 

recommendation relating to milestones for gauging progress is and will 

continue to be monitored in the department’s enterprise transition plan. 

While we have previously recognized that the transition plan provides 

information on the progress of major investments over the last 6 months—

including key accomplishments and milestones attained, this element of 

our recommendation is intended to address the lack of measures (e.g., 

return on investment of service reuse) or specific completion dates for the 

activities and related capabilities, products, and services associated with 

the BMA federation strategy. 

Second, the department stated that while it agreed with the core intent of

the remaining two elements of our recommendation, these elements 

should be sufficiently specific to permit reasonable implementation and 

should be directed to the appropriate parties within the department. Our 

Page 4 GAO-07-451 Business Systems Modernization
recommendation is not intended to dictate who should develop the 

policies or guidance for managing architectures within a federated 

environment. Rather it is focused on developing plans that describe how 

the BMA will adopt and implement the policies and guidance relating to 

federation governance and service orientation. To further ensure that our 

recommendation is properly interpreted and implemented and to address 

DOD’s comments about directing the recommendation to the appropriate 

parties, we have slightly modified it. 

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. 

Background 

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,9

 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. 

 9

GAO-06-658. 

Page 5 GAO-07-451 Business Systems Modernization
As we have previously reported,10 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.11 Eight of these areas are specific to DOD12 and the department 

shares responsibility for 7 other governmentwide high-risk areas.13 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. 

Enterprise Architecture Is 

Critical to Achieving 

Successful Business 

Systems Modernization 

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 199614 mandates that an agency’s 

CIO develop, maintain, and facilitate the implementation of an information 

technology (IT) architecture. Furthermore, the E-Government Act of 200215

requires OMB to oversee the development of enterprise architectures 

 10See, for example, GAO, Defense Inventory: Opportunities Exist to Improve Spare Parts

Support Aboard Deployed Navy Ships, GAO-03-887 (Washington, D.C.: Aug. 29, 2003);

Military Pay: Army National Guard Personnel Mobilized to Active Duty Experienced

Significant Pay Problems, GAO-04-89 (Washington, D.C.: Nov. 13, 2003); and DOD Travel 

Cards: Control Weaknesses Resulted in Millions of Dollars of Improper Payments, 

GAO-04-576 (Washington, D.C.: June 9, 2004).

11GAO-07-310. 

12These high-risk areas include DOD’s overall approach to business transformation, 

business systems modernization, financial management, the personnel security clearance

program, supply chain management, support infrastructure management, weapon systems 

acquisition, and contract management. 

13The 7 governmentwide high-risk areas are as follows: (1) disability programs, (2) ensuring 

the effective protection of technologies critical to U.S. national security interests, 

(3) interagency contracting, (4) information systems and critical infrastructure, 

(5) information-sharing for homeland security, (6) human capital, and (7) real property.

14The Clinger-Cohen Act of 1996, 40 U.S.C. § 11315(b)(2).

15The E-Government Act of 2002, Pub. L. No. 107-347 (Dec. 17, 2002). 

Page 6 GAO-07-451 Business Systems Modernization
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.

16

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. 

Enterprise Architecture: A 

Brief Description 

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”

17 and the DOD 

Architecture Framework.18

The importance of developing, implementing, and maintaining an 

enterprise architecture is a basic tenet of both organizational 

transformation and systems modernization. Managed properly, an 

 16GAO, Information Technology Investment Management: A Framework for Assessing

and Improving Process Maturity, GAO-04-394G (Washington, D.C.: March 2004); CIO 

Council, A Practical Guide to Federal Enterprise Architecture, Version 1.0 (February 

2001); and OMB Capital Programming Guide, Version 1.0 (July 1997). 

17John A. Zachman, “A Framework for Information Systems Architecture,” IBM Systems

Journal 26, No. 3 (1987). 

18DOD, Department of Defense Architecture Framework, Version 1.0, Volume 1 (August 

2003) and Volume 2 (February 2004). 

Page 7 GAO-07-451 Business Systems Modernization
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.19

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 

 19See, for example, GAO, Homeland Security: Efforts Under Way to Develop Enterprise 

Architecture, but Much Work Remains, GAO-04-777 (Washington, D.C.: Aug. 6, 2004); 

GAO-04-731R; Information Technology: Architecture Needed to Guide NASA’s Financial

Management Modernization, GAO-04-43 (Washington, D.C.: Nov. 21, 2003); GAO-03-1018; 

GAO-03-877R; Information Technology: DLA Should Strengthen Business Systems 

Modernization Architecture and Investment Activities, GAO-01-631 (Washington, D.C.: 

June 29, 2001); and Information Technology: INS Needs to Better Manage the Development 

of Its Enterprise Architecture, and GAO/AIMD-00-212 (Washington, D.C.: Aug. 1, 2000). 

Page 8 GAO-07-451 Business Systems Modernization
different component organizations. As we have previously reported,20 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 selfdescribing 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. 

DOD’s Efforts to Adopt a 

Federated Approach to 

Architecting All of Its 

Mission Areas 

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,21

Business,22 DOD Intelligence,23 and Enterprise Information Environment.24

According to ASD(NII)/CIO officials, they are drafting a yet-to-be-released

strategy for evolving DOD’s Global Information Grid architecture,25 so that 

it provides a comprehensive architectural description of the entire DOD 

 20GAO, Information Technology: FBI Has Largely Staffed Key Modernization Program, 

but Strategic Approach to Managing Program’s Human Capital Is Needed, GAO-07-19 

(Washington, D.C.: Oct. 16, 2006). 

21The Warfighting Mission Area focuses on transforming how DOD achieves its mission 

objectives by addressing joint warfighting capabilities and providing life-cycle oversight to 

applicable DOD component and combatant command IT investments. 

22The Business Mission Area is responsible for ensuring that capabilities, resources, and 

materiel are reliably delivered to the warfighter. Specifically, the BMA addresses areas 

such as real property and human resources management. 

23The DOD Intelligence Mission Area is focused on establishing advanced capabilities to 

anticipate adversaries and includes IT investments within the military intelligence program 

and defense component programs of the National Intelligence Program. 

24The Enterprise Information Environment Mission Area enables the functions of the other 

mission areas (e.g., Warfighting Mission Area, Business Mission Area, and National 

Intelligence Mission Area) and encompasses all communications, computing, and core

enterprise service systems, equipment, or software that provides a common information

capability or service for enterprise use. 

25According to DOD, the Global Information Grid consists of a globally interconnected,

end-to-end set of information capabilities, associated processes, and personnel for 

collecting, processing, storing, disseminating, and managing information on demand to 

warfighters, policymakers, and support personnel, and as such represents the department’s

IT architecture. 

Page 9 GAO-07-451 Business Systems Modernization
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. 

Figure 1: Simplified Depiction of the DOD Enterprise Architecture Federation Strategy 

Global Information Grid

Warfighting

 Mission Area

Business

Mission Area

Intelligence

Mission Area

Service Agency Combatant

Command

Enterprise

Information

Environment

Mission Area

Mission 

Area Layer

Component

Layer

Program

Layer

Department 

Layer

Source: GAO analysis of DOD data.

Warfighting

Enterprise

Architecture

Business

Enterprise

Architecture

Intelligence

Enterprise

Architecture

Enterprise 

Information 

Environment

Enterprise

Architecture

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, 

Page 10 GAO-07-451 Business Systems Modernization
(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. 

DOD Roles and 

Responsibilities for BEA 

Development and Use 

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.

26

Under tiered accountability, responsibility and accountability for business 

architectures and systems investment management was allocated among 

the DOD enterprise,27 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 

 26Under a tiered accountability approach, the BEA describes the envisioned processes, 

systems, and standards and components are responsible for defining a component-level 

architecture associated with their own tier of responsibility in alignment with the BEA’s 

enterprisewide standards and requirements. 

27The DOD enterprise is comprised of the entities in the Office of the Secretary of 

Defense—the DBSMC, the BTA, and the Investment Review Boards. 

Page 11 GAO-07-451 Business Systems Modernization
is to lead and coordinate business transformation efforts across the 

department. Regarding the BEA, the BTA is responsible for 

(1) maintaining and updating the department’s architecture; (2) ensuring 

that functional priorities and requirements of various defense components, 

such as the Department of the Army and Defense Logistics Agency (DLA), 

are reflected in the architecture; and (3) ensuring the adoption of DODwide information and process standards as defined in the architecture. 

Under DOD’s tiered accountability approach to systems modernization, 

components are responsible for defining their respective component 

architectures and transition plans while complying with BEA and ETP 

policy and requirements. Similarly, program managers are responsible for 

developing program-level architectures and transition plans and ensuring

integration with the architectures and transition plans developed and 

executed at the DOD enterprise and component levels. 

Summary of GAO’s Prior 

Reviews on DOD’s 

Architecture Efforts 

Between May 2001 and July 2005, we reported on DOD’s efforts to develop

an architecture and identified serious problems and concerns with the 

department’s architecture program, including the lack of specific plans 

outlining how DOD plans to extend and evolve the architecture to include 

the missing scope and detail.28 To address these concerns, in September 

200329 we recommended that DOD develop a well-defined near-term plan 

for extending and evolving the architecture and ensure that this plan 

includes addressing our recommendations, defining roles and

responsibilities of all stakeholders involved in extending and evolving the 

architecture, explaining dependencies among planned activities, and 

defining measures of progress for the activities. 

In response to our recommendations, in 2005, DOD adopted a 6-month 

incremental approach to developing its enterprise architecture and 

released version 3.0 of the BEA and the ETP in September 2005, describing 

them as the initial baselines. DOD further released version 3.1 on March 

15, 2006, and version 4.0 on September 28, 2006. As we have previously 

 28See, for example, GAO-01-525, GAO-03-458, GAO-03-571R, GAO-03-877R, GAO-03-1018, 

GAO-04-731R, GAO-05-381, and GAO-05-702. 

29GAO-03-1018. 

Page 12 GAO-07-451 Business Systems Modernization
reported,30 these incremental versions have provided additional content

and clarity and resolved limitations that we identified in the prior versions. 

For example, DOD reports that version 4.0 begins to define a key business 

process area missing from prior versions—the planning, programming, 

and budgeting process area. In this regard, according to DOD, the 

architecture includes departmental and other federal planning, 

programming, and budgeting guidance (e.g., OMB Circular A-11) and some 

high-level activities associated with this area. In addition, DOD reports 

that version 4.0 included restructured business process models to reduce 

data redundancy and ensure adherence to process modeling standards 

(e.g., eliminated numerous process modeling standards violations and 

stand-alone process steps with no linkages). 

We concluded, however, that these incremental versions were still not 

sufficiently complete to effectively and efficiently guide and constrain 

business system investments across the department. In particular, we 

reported that the BEA was not yet adequately linked to the component 

architectures and transition plans, which is important given that the 

department (1) had previously announced that it had adopted a federated 

approach to developing and implementing the architecture and (2) had yet

to address our recommendation from September 200331 for developing an 

architecture development management plan that defined how it intended 

to extend and evolve its BEA. 

Accordingly, in May 200632 we recommended that DOD submit an 

enterprise architecture development management plan to defense 

congressional committees. We stated that at a minimum, the plan should 

define what the department’s incremental improvements to the 

architecture and transition plan would be and how and when they would 

be accomplished, including what (and when) architecture and transition 

plan scope and content and architecture compliance criteria would be 

added into which versions. In addition, we stated that the plan should 

include an explicit purpose and scope for each version of the architecture, 

along with milestones, resource needs, and performance measures for 

each planned version, with particular focus and clarity on the near-term 

 30GAO, Defense Business Transformation: A Comprehensive Plan, Integrated Efforts, and 

Sustained Leadership Are Needed to Assure Success, GAO-07-229T (Washington, D.C.: 

Nov. 16, 2006). 

31GAO-03-1018. 

32GAO-06-658. 

Page 13 GAO-07-451 Business Systems Modernization
versions. In response, DOD stated that, in the future, the ETP and annual 

report to Congress would provide additional high-level milestones for BTA 

activities, including the additional detail for the capability improvements

to be addressed by the BEA. 

Our August 200633 report on the maturity of federal agency enterprise 

architecture programs, including those of the military departments, 

reemphasized the importance of DOD having an effective plan for 

federating its BEA. Specifically, the August report showed that the 

Departments of the Air Force, Army, and Navy had not satisfied about 30, 

55, and 30 percent, respectively, of the 31 core elements in our Enterprise 

Architecture Management Maturity Framework, which is a five-stage 

model for effectively managing architecture governance, content, use, and

measurement.34 In addition, the Army had only fully satisfied 1 of the 31 

core elements.35 (See table 1 for the number of elements that were fully, 

partially, and not satisfied by each of the military departments.) 

Table 1: Number of Framework Elements That Were Fully, Partially, and Not 

Satisfied by the Military Departments 

Military departments Fully satisfied Partially satisfied Not satisfied

Air Force 14 8 9

Army 1 13 17

Navy 10 12 9

Total 25 33 35

Source: GAO.

By comparison, the other major federal departments and agencies that we 

reviewed had as a whole fully satisfied about 67 percent of the 

framework’s core elements. Among the key elements that all three military 

departments had not fully satisfied were developing architecture products

 33GAO, Enterprise Architecture: Leadership Remains Key to Establishing and Leveraging 

Architectures for Organizational Transformation, GAO-06-831 (Washington, D.C.:

Aug. 14, 2006). 

34GAO, Information Technology: A Framework for Assessing and Improving Enterprise 

Architecture Management (Version 1.1), GAO-03-584G (Washington, D.C.: April 2003). 

35We did not review the enterprise architecture programs at other DOD components, such

as the Defense Information Systems Agency or the DLA. 

Page 14 GAO-07-451 Business Systems Modernization
that describe their respective target architectural environments and 

developing transition plans for migrating to a target environment. 

Furthermore, while the military departments had partially satisfied 

between 8 and 13 core elements in our framework, we reported that 

partially satisfied elements are not necessarily easy to satisfy fully, such as

those that address architecture content and thus have important 

implications for the quality and usability of an architecture. To assist the 

military departments in addressing enterprise architecture challenges and 

managing their architecture programs, we recommended that the military 

departments develop and implement plans for fully satisfying each of the 

conditions in our framework. The department generally agreed with our 

findings and recommendations. 

DOD’s BMA federation strategy provides a foundation on which to build 

and align DOD’s parent business architecture (the BEA) with its 

subordinate architectures (i.e., component- and program-level

architectures). In particular, this strategy (1) states the department’s 

federated architecture goals; (2) describes federation concepts that are to

be applied; and (3) includes high-level activities, capabilities, products, 

and services that are intended to facilitate implementation of the concepts.

However, DOD has yet to define the details needed to execute the strategy, 

such as how the architecture federation will be governed; how alignment 

with the DOD EA federation strategy and other potential mission area 

federation strategies will be achieved; how component architectures’ 

alignment with incremental versions of the BEA will be achieved; how 

shared services will be identified, exposed, and subscribed to; and what 

milestones will be used to measure progress and results. According to BTA 

program officials, including the chief technical officer, the department is 

in the early stages of defining and implementing its strategy and intends to

develop more detailed plans. As a result, much remains to be decided and 

accomplished before DOD will have in place the means to create a 

federated architecture and thus be able to satisfy both our prior 

recommendations and legislative requirements aimed at adopting an 

architecture-centric approach to departmentwide business systems 

investment management. 

DOD Is in the Early 

Stages of Federating 

Its BEA and Much 

Remains to Be 

Decided and 

Accomplished 

Page 15 GAO-07-451 Business Systems Modernization
BTA released the BMA federation strategy in September 2006. According

to the strategy, its purpose is to expand on the DOD EA federation strategy 

and provide details on how various aspects of the federation will be 

applied within the department’s BMA. In this regard, the BMA strategy 

cites the following four goals: 

BMA Federation Strategy 

Describes Goals, 

Concepts, and High-level 

Activities

• establish a capability to search for data in member architectures that may 

be relevant for analysis, reference, or reuse; 

• develop a consistent set of standards for architecture configuration 

management that will enable users to determine the development status 

and quality of data in various architectures; 

• establish a standard methodology for specifying linkages among existing 

component architectures that were developed using different tools and 

that are maintained in independent repositories; and 

• develop a standard methodology to reuse capabilities described by various 

architectures. 

To assist in accomplishing these goals, the strategy describes three 

concepts that are to be applied. 

1. Tiered accountability, which provides for architecture development at 

each of the department’s organizational levels. Under this concept, 

each level or tier—enterprise, component, and program—has its own 

unique goals as well as responsibilities to the tiers above and below it. 

More specifically, the BTA has responsibility for the enterprise tier, 

including common, DOD-wide requirements and standards, while 

components and programs are responsible for defining componentand program-level architecture requirements and standards for their 

respective tiers of responsibility that are aligned with the 

departmentwide requirements and standards. As such, this concept 

introduces the need for autonomy, while also seeking to ensure 

linkages and alignment from the program level through the component 

level to the enterprise level. 

2. Net-centricity, which provides for seamless and timely accessibility to 

information where and when needed via the department’s 

interconnected network environment. This concept includes 

infrastructure, systems, processes, and people and is intended to 

ensure that users (i.e., people, applications, and platforms) of

information at any level can both take what they need and contribute 

what they know. 

Page 16 GAO-07-451 Business Systems Modernization
3. Federating DOD architectures, which provides for linking or aligning 

different architectures via the mapping of common architectural 

information. This concept advocates subordinate architecture 

alignment to the parent architecture(s). 

Figure 2 shows a simplified version of DOD’s BMA federated architecture. 

Figure 2: Simplified Diagram of DOD’s Business Mission Area Federated Architecture 

Source: GAO analysis of DOD data.

Enterprise Shared Services and System Capabilities

Enterprise Rules and Standards for Interoperability

Navy Architectures Transition Plans

Systems Solutions

AF

Architectures

Transition Plans

Systems Solutions

Army Architectures Transition Plans

Systems Solutions

Architectures

Transition Plans

Systems Solutions

TRANS

COM

DFAS Architectures Transition Plans Systems Solutions

DLA Architectures Transition Plans Systems Solutions

Enterprise Shared Services and System Capabilities

Enterprise Rules and Standards for Interoperability

Enterprise Shared Services and System Capabilities

DOD BEA and Enterprise Transition Plan

Enterprise Rules and Standards for Interoperability

Navy Architectures Transition Plans

Systems Solutions

AF

Architectures

Transition Plans

Systems Solutions

Army Architectures Transition Plans

Systems Solutions

Component Layer Program Layer DOD-Enterprise 

Layer

BTA

Military departments

and example 

defense agencies

Example

programs

Architectures

Transition Plans

Systems Solutions

Architectures

Transition Plans

Systems Solutions

Architectures

Transition Plans

Systems Solutions

Architectures

Transition Plans

Systems Solutions

Architectures

Transition Plans

Systems Solutions

Architectures

Transition Plans

Systems Solutions

United States

Transportation 

Command

Defense 

Finance and 

Accounting

Service

Defense 

Logistics

Agency

Army Navy Air Force

General Fund 

Enterprise 

Business

System

Single Army 

Financial 

Enterprise

Navy 

Enterprise

Resource

Planning

Navy Tactical 

Command

Support 

System

Expeditionary 

Combat 

Support 

System

Technical 

Training 

Management 

System

Business

Systems

Modernization

Distribution 

Planning 

Management 

System

Automated 

Disbursing 

System

Defense Joint 

Military Pay 

System

Defense 

Enterprise 

Accounting 

and 

Management 

System

Defense 

Personal 

Property 

System

To support the achievement of its goals and implementation of its 

concepts, the strategy also describes three categories of high-level 

activities, capabilities, products, and services—governance,36 federating 

 36According to the strategy, governance addresses how the BMA federated approach will be 

implemented across DOD components by describing the new responsibilities imposed on 

the existing business systems governance structures resulting from the federation. 

Page 17 GAO-07-451 Business Systems Modernization
architecture operational views,37 and federating architecture systems 

views.38 Table 2 shows the strategy’s operational and systems view related

activities, capabilities, products, and services. 

Table 2: High-level Steps for Achieving Operational and Systems View Federation

Steps for achieving operational view federation 

Support and participate in DOD’s pilot efforts to demonstrate capability to search and 

navigate across the various DOD architectures. 

Implement the framework through a pilot with the DLA to demonstrate how the enterprise 

priorities are being addressed comprehensively within the defense agencies. 

Map components’ core systems to the BEA. 

Implement the architecture traceability tool and continue to add functionality according to 

user requirements to support BEA compliance. 

Release the traceability tool as a Web tool accessible through the BTA portal. 

Steps for achieving systems view federation

Incrementally build the common foundation infrastructure for a SOA environment by 

leveraging the core enterprise services, such as information assurance. 

Define standards for building the technical infrastructure. 

Stand up an initial set of infrastructure services to support “leave-in-place” pilots. 

Acquire, develop, or deploy a Business Mission Area portal.

Schedule and implement a series of “leave-in-place” federation pilots that can offer 

services and capabilities. 

Leverage and use the Enterprise Information Environment Mission Area core enterprise 

services. 

Bring the services that are developed as part of the pilots into the technical

infrastructure, as appropriate. 

 37The DOD Architecture Framework defines the operational view as a description of the

tasks and activities, operational elements, and information exchanges required to 

accomplish DOD missions. Federating architecture operational views, according to the 

BMA strategy, is an approach for gaining visibility across the various business architectures 

by enabling linkages and alignment among these various BMA architectures’ activities, 

processes, and data (e.g., DOD, component, and program). 

38The DOD Architecture Framework defines the systems view as a set of graphical and

textual products that describe systems and interconnections providing for or supporting

DOD functions. Federating architecture system views, according to the BMA strategy, is an

approach for the delivery of shared business systems and information services within a 

SOA through an IT infrastructure. 

Page 18 GAO-07-451 Business Systems Modernization
Establish a governance infrastructure to establish and monitor the policies, standards, 

and procedures necessary for the operation of the technical infrastructure and 

environment. 

Leverage existing architecture governance structures or include a new review board to 

focus on systems federation requirements. 

Develop an education program for stakeholders across DOD. 

Develop and deliver curriculum to each target stakeholder over the next year and 

address areas such as SOA, net-centricity, and overall federation strategy.

Source: DOD. 

The BMA Federation 

Strategy Is Missing 

Executable Details 

Relevant architecture management guidance39 states that organizations 

should develop executable architecture development management plans 

and that these plans should specify, among other things, tasks to be 

performed, resources needed to perform these tasks (e.g., funding, 

staffing, tools, and training), roles and responsibilities, time frames for 

completing tasks, and performance measures. As previously stated, we 

have recommended that DOD develop such an architecture development 

plan to govern the evolution and extension of the BEA.40 We also have 

previously reported that a SOA approach needs to ensure that shared 

systems and applications (i.e., services) are, among other things, defined,

developed, exposed, and subscribed to.41

The high-level construct of DOD’s BMA federation strategy and the yet-tobe-issued DOD EA federation strategy reinforces the need to implement 

our recommendation. In particular, the strategy defines the department’s 

federated architecture goals; describes federation concepts that are to be

applied; and explains high-level activities, capabilities, products, and 

services intended to facilitate implementation of the concepts. However, it 

does not adequately define the tasks needed to achieve the strategy’s 

goals, including those associated with executing high-level activities and 

providing related capabilities, products, and services. Specifically, the 

strategy does not adequately address how strategy execution will be 

governed, including assignment of roles and responsibilities, measurement 

of progress and results, and provision of resources. In addition, while the 

BMA strategy refers to several activities that are to be provided by the yetto-be-issued DOD EA federation strategy, it does not clearly describe the 

 39See, for example, GAO-03-584G and A Practical Guide to Federal Enterprise 

Architecture. 

40GAO-03-1018 and GAO-06-658. 

41GAO-07-19. 

Page 19 GAO-07-451 Business Systems Modernization
relationships, dependencies, and touch points between the two strategies. 

Also, the strategy does not address, among other things, how the 

architectures of the military departments will align with the latest version 

of the BEA and how DOD will identify and provide for sharing of common 

applications and systems across the department. Moreover, the strategy 

does not include milestones for executing the activities and related 

capabilities, products, and services. 

According to ASD(NII)/CIO officials, each mission area will be responsible 

for establishing its own governance structures, to include defined roles 

and responsibilities of its members (i.e., components and programs), and 

such governance disciplines as measurement of progress and results and 

provision of resources. Moreover, officials from DOD components, such as 

the DLA and the Defense Information Systems Agency (DISA), told us that

clearly defined and understood federation roles and responsibilities are 

critical to successfully executing the BMA strategy. 

Governance Structure Is Not 

Clearly Defined 

However, the BMA strategy does not clearly define the respective roles 

and responsibilities of each member of the federation (i.e., enterprise, 

component, and program). It also does not identify the resource 

commitments (e.g., funding, staffing, tools, and training) needed to 

execute the strategy’s activities and deliver capabilities, products, and 

services, or identify how fundamental governance disciplines will be 

performed, including performance and progress measurement. For 

example: 

• The strategy states that the DBSMC, which is currently responsible for the 

approval and maintenance of the BEA, will receive updates on how 

component (e.g., the military departments) architectures are aligning to 

the BEA. However, it does not describe which organizational entities are 

to be responsible for providing these updates or for aligning component 

and program architectures to the BEA. 

• The strategy states that in conjunction with the DOD investment review 

boards,42 the DBSMC will set the business priorities at the enterprise level 

through the identification of gaps in business capabilities. By establishing 

these priorities, the DBSMC is to determine where and when specific 

capabilities are addressed within the different architectures (i.e., from 

 42The investment review boards serve as the oversight and investment decision-making 

bodies for those business capabilities that support activities under their designated areas of 

responsibility. 

Page 20 GAO-07-451 Business Systems Modernization
BEA to program-level architectures) and is to approve recommended 

solutions to business capability needs. However, the strategy does not 

provide information on who is responsible for ensuring that component 

priorities fit with the overall enterprise priorities, or how the DBSMC will 

otherwise be provided the information it needs to fulfill its stated decisionmaking role.

• The strategy states that BMA stakeholders will need to be trained to 

understand the concepts presented in the strategy and begins to identify 

topics, such as SOA and the overall federation strategy. However, the

strategy does not identify time frames and the entity responsible for 

providing and overseeing such training. In addition, the strategy does not 

address how it will be funded and staffed. 

• The strategy identifies categories of high-level activities, capabilities, 

products, and services intended to facilitate implementation of the 

concepts, but it does not provide for metrics that can be used to gauge the 

progress and ensure that expected results are realized. 

According to the BMA federation strategy, the DOD EA federation strategy

outlines an approach for linking the repositories of all of the department’s 

various architectures and enabling search and navigation across them. In 

addition, it states that the DOD EA federation strategy outlines a series of 

pilot efforts that will demonstrate this approach. However, the BMA 

federation strategy does not clearly define how its various activities will 

integrate with the activities and concepts described in the yet-to-be-issued 

DOD EA federation strategy, or other potential mission area federation 

strategies, nor does it discuss how these activities will be carried out or 

who will be responsible for accomplishing them. For example: 

Relationship to DOD EA 

Federation Strategy Effort Is 

Unclear 

• ASD(NII)/CIO officials told us that the DOD EA federation strategy will 

establish new responsibilities for components and programs for making 

architecture information understandable and accessible across the 

department. However, these responsibilities are not explicitly discussed in 

the BMA federation strategy. Therefore, it is unclear how these new 

responsibilities are relevant to federating the BEA. Moreover, it is unclear 

how the BMA roles and responsibilities relate to the yet-to-be-released EA 

federation strategy roles and responsibilities. 

• The BMA federation strategy does not define how linkages among the BEA 

and the various component and program architectures will be established,

including whether program architectures will be linked to component 

architectures as well as the BEA, or if program architectures will be linked 

to the BEA, as is currently the case. Moreover, it is not clear if establishing 

Page 21 GAO-07-451 Business Systems Modernization
these linkages will be the responsibility of the programs, components, the 

BTA, or ASD(NII)/CIO.

According to the BMA federation strategy, it builds on the DOD EA 

federation strategy by proposing new tools and procedures to both 

identify overlaps and gaps in capabilities and ensure the compliance of all 

component and program architectures with the BEA. In this regard, it 

describes the following two tools: the Investment Management 

Framework, which is a spreadsheet that aligns program architectures’ 

capabilities (and activities) with the BEA, and the Architecture 

Compliance and Requirements Traceability tool, which is an automated 

tool that provides programs with an interface to the BEA so that they can

assess their alignment with the BEA’s operational view content (e.g., 

business capabilities, activities, processes, rules, and standards). 

However, the strategy does not address how alignment of component 

architectures with the BEA is to be achieved, including what, if any, 

component architecture alignment guidance, criteria, and tools are to be 

developed and who will develop them. Specifically, while the strategy 

states that it provides for demonstration of operational view linkages (e.g.,

activities, process, and capabilities) between the BEA and both 

component and program architectures, the tools cited do not provide the 

capability to either align program architectures to component 

architectures or to align component architectures to the BEA. According 

to officials from the Air Force, Navy, and DLA, they are using the 

traceability tool to assess compliance of their programs with the BEA. 

However, this tool does not allow them to assess their programs’ 

compliance with their component architectures. In contrast, Army and 

U.S. Transportation Command officials told us that they do not require the 

use of the traceability tool to assess compliance of their programs to the 

BEA or their component architectures. According to BTA officials, they 

are currently working with the Air Force and Navy to expand this tool to 

include component architecture alignment capabilities. 

According to the BMA strategy, the systems view federation is the 

application of principles, standards, services, and infrastructure to create

interoperable and reusable applications and systems. The strategy states 

that this will be accomplished through the delivery of services within a 

SOA construct, including an IT infrastructure43 that will expose reusable 

Operational View Federation 

Does Not Address Component 

Architecture Alignment 

Systems View Federation Lacks 

Key Execution Details 

 43The strategy refers to the IT infrastructure as the business transformation infrastructure. 

Page 22 GAO-07-451 Business Systems Modernization
functionality to federation members and enable interoperation and 

interconnection of the business systems and applications that provide this 

functionality. The strategy notes that this operating environment will be 

comprised of applications, systems, metadata,44 and a unifying portal. 

According to the strategy, this environment will build on existing 

Enterprise Information Environment Mission Area capabilities and provide 

the standards, policies, and technology needed to permit BMA services to 

be shared with the other DOD mission areas. 

However, the strategy does not describe how this will be accomplished, 

including respective roles and responsibilities of those involved, the range 

of services to be shared and developed, and the standards to be used. 

Moreover, component officials told us that the details behind the strategy’s 

SOA concepts need to be defined before a systems view federation can be 

achieved. More specifically: 

• The strategy does not clearly describe how interoperable services will be 

defined, developed, exposed, and subscribed to. For example, it does not 

delineate the specific roles and responsibilities of the military departments 

and defense agencies relative to defining, providing, and employing shared

systems and applications. As a result, the military departments and 

defense agencies may pursue duplicative efforts. This is of particular 

concern due to the various service orientation activities already under way 

in the military departments and defense agencies. For example, the Air 

Force has chartered a Transparency Integrated Product Team to guide 

their SOA initiatives, and the Navy has established a Transformation 

Group to support its service orientation activities. This is important 

because a key aspect of the BMA federation strategy is reusing and 

leveraging both enterprise-level and component-level systems and 

applications. 

• The strategy does not relate system federation activities and capabilities to

its existing ETP. In particular, while the strategy describes a number of 

“leave-in-place” pilots (systems and applications) that will be implemented 

during the next year to demonstrate the use of shared services, it does not 

describe how these relate to programs in the ETP. This is important 

because the chief technical officer told us that many of the enterprise-level 

programs being managed by the BTA and included in the ETP are to 

evolve into shared services. 

 44Metadata are data used to supplement information to main data. 

Page 23 GAO-07-451 Business Systems Modernization
• The strategy does not describe how interface standards will be established 

and used for obtaining and delivering shared services. Defining and 

enforcing such standards are important aspects of having services that are 

interoperable and reusable. According to the BTA chief technical officer, 

these standards will need to align with the yet-to-be-issued Enterprise 

Information Environment Mission Area standards. Officials from the Air 

Force and DISA agreed that more needs to be done to define the 

infrastructure standards that will enable user subscription to reusable 

systems and applications, particularly since the military departments and 

DOD are moving ahead with their own SOA initiatives. 

The strategy outlines what it refers to as a high-level road map by listing 

activities, capabilities, products, and services that are to be produced. (See 

table 2 for this high-level road map.) 

However, the strategy does not specify the milestones or provide specific

completion dates for the activities and related capabilities, products, and 

services listed in its high-level road map. Instead, the strategy states that

the road map began in October 2006 and that milestones will occur at 

approximately 3-month increments, without identifying, for example, 

which steps have begun and what is to be accomplished over 3 months for 

each of the steps. 

DOD is in the early, formative stage of federating its BEA, with much 

remaining to be decided and accomplished before it achieves its goals. 

While the goals, concepts, and related activities; capabilities; products; 

and services discussed in the strategy have merit and hold promise, the 

strategy lacks sufficient specificity for it to be executed and, therefore, 

must be viewed as a beginning. To the department’s credit, it recognizes 

the need for greater detail surrounding how it will extend (federate) its 

BEA. One key to making this happen is for the department to implement 

our prior recommendation for having a BEA development management 

plan. However, the department has yet to address this recommendation. 

Until it does, the likelihood of effectively extending the BEA to include the 

military departments and defense agencies is greatly reduced. 

To further assist the department in evolving its BEA, we are reiterating our 

prior recommendation for a BEA development management plan, and

augmenting it by recommending that the Secretary of Defense direct the

Deputy Secretary of Defense, as the chair of the DBSMC, to task the 

appropriate DOD organizations, to ensure that this plan describes, at a 

Strategy Does Not Include 

Milestones 

Conclusions 

Recommendation for 

Executive Action 

Page 24 GAO-07-451 Business Systems Modernization
minimum, how the BMA architecture federation will be governed; how the 

BMA federation strategy alignment with the DOD EA federation strategy 

will be achieved; how component business architectures’ alignment with 

incremental versions of the BEA will be achieved; how shared services 

will be identified, exposed, and subscribed to; and what milestones will be 

used to measure progress and results. 

In written comments on a draft of this report, signed by the DOD Deputy 

Chief Information Officer and the Deputy Under Secretary of Defense 

(Business Transformation) and reprinted in appendix II, the department 

stated that it largely disagrees with our recommendation and added that

while the BMA played a leading role in defining the department’s approach

to architecture federation and a service-oriented architecture, the impact 

of the issues discussed in this report goes beyond the scope of the 

business systems modernization. DOD also stated that any analysis of 

architecture federation should begin with the department’s approach and 

not the BMA, since the BMA federation strategy was written as an 

addendum to an enterprise approach. However, DOD added that it 

recognizes that our analysis was complicated by the fact that many of the 

enterprise-level strategy and governance documents, to which the BMA 

must comply, have yet to be issued.

The department also made the following specific comments on the five 

elements in our recommendation. 

First, DOD stated that it partially concurs with the element relating to 

architecture federation. According to DOD, responsibility for developing

the policy and guidance regarding how architectures are to be managed 

within its federated environment lies with the ASD(NII)/CIO; officials 

acknowledge the current lack of such guidance and stated that this will be 

addressed with the issuance of the DOD EA federation strategy. As such, 

the department recommends that we address our recommendation to 

ASD(NII)/CIO. We agree on the current lack of and the need to develop

policies and guidance describing how the federation will be governed; 

however, our recommendation is not intended to dictate who should 

develop the policies or guidance for managing architectures within a 

federated environment. Rather, it is focused on developing plans that 

describe how the BMA will adopt and implement the policies and guidance 

relating to federation governance. 

Second, the department stated that it nonconcurs with the element 

relating to ensuring alignment with other federation strategies. According 

Agency Comments 

and Our Evaluation 

Page 25 GAO-07-451 Business Systems Modernization
to DOD, there is a single architecture federation strategy for the 

department—the DOD EA federation strategy—and other architecture 

federation strategies supplement this overarching strategy. As such, it 

stated that this element of our recommendation is not needed. We 

disagree. While we do not question the department’s comment about the 

relationships among the strategies, we believe that this element of our 

recommendation is needed because its intent is to recognize these 

relationships by promoting collaboration and ensuring linkages among the 

various strategies. 

Third, DOD stated that it nonconcurs with the element relating to 

component architecture alignment with incremental versions of the BEA. 

According to DOD, this element has been implemented both in policy and 

execution to comply with legislative requirements, to include DOD’s 

development and use of the Architecture Compliance and Requirements 

Traceability tool. It also added that the Departments of the Air Force, 

Army, and Navy have mandated the use of this tool to assess compliance 

of their systems and architectures with the BEA. We disagree. The 

National Defense Authorization Act for Fiscal Year 2005 includes a 

requirement for ensuring that all business systems in excess of $1 million 

be certified as being in compliance with the BEA; the architecture 

traceability tool provides a mechanism for asserting only system 

compliance and not component architecture compliance. In addition, 

according to officials from the Air Force and Army, while they are 

encouraging the use of the tool for assessing compliance of their systems 

with the BEA, they have not mandated its use and are not using it to assess 

compliance of their architectures with the BEA. Moreover, officials from 

the Air Force further stated that they have not mandated the use of this 

tool because it does not provide the capability to map the Air Force 

architecture with the BEA. While we recognize DOD’s efforts to align 

programs to the BEA, our recommendation focuses on the lack of a 

discussion in the BMA federation strategy on how component 

architectures (military departments and defense agencies) will be linked

to the BEA, including the lack of component architecture alignment 

guidance, criteria, and tools. 

Fourth, the department stated that it partially concurs with the element 

relating to the identification and management of shared services. 

According to DOD, each mission area or component is responsible for 

identifying its own services requirements, and the ASD(NII)/CIO is 

responsible for defining the overall approach to how these services will be 

managed. As such, the department recommends that our recommendation 

be directed to the ASD(NII)/CIO. We agree on the need for guidance 

Page 26 GAO-07-451 Business Systems Modernization
describing how shared services will be identified and managed; however, 

our recommendation is not intended to dictate who should develop the 

policies or guidance for managing shared services within a federated 

environment. Rather, it is focused on developing plans that describe how 

the BMA will adopt and implement the policies and guidance relating to 

service orientation. As stated in the report, this is important because a key 

aspect of the BMA federation strategy is to reuse and leverage both 

enterprise-level and component-level systems and applications. 

Fifth, DOD stated that it nonconcurs with the element relating to 

milestones. According to DOD, milestones for gauging progress are and 

will continue to be monitored in the department’s enterprise transition 

plan. As such, it stated that it is unclear how the need to describe what 

milestones will be used relates to the topics in the report. While we have 

previously recognized that the transition plan provides information on 

progress on major investments over the last 6 months—including key 

accomplishments and milestones attained, this element of our 

recommendation is intended to address the lack of measures (e.g., return 

on investment of service-oriented architecture service reuse) or specific 

completion dates for the activities and related capabilities, products, and 

services that are to be produced for federating the Business Mission Area. 

To further ensure that our recommendation is properly interpreted and 

implemented, and to address DOD’s comments about directing the 

recommendation to the appropriate parties, we have slightly modified our 

recommendation. 

We are sending copies of this report to interested congressional 

committees; the Director, Office of Management and Budget; the Secretary

of Defense; the Deputy Secretary of Defense; the Under Secretary of 

Defense for Acquisition, Technology, and Logistics; the Under Secretary of 

Defense (Comptroller); the Assistant Secretary of Defense (Networks and 

Information Integration)/Chief Information Officer; the Under Secretary of 

Defense (Personnel and Readiness); and the Director, Defense Finance 

and Accounting Service. We will also make copies available to others on 

request. In addition, this report will also be available at no charge on our 

Web site at http://www.gao.gov. 

Page 27 GAO-07-451 Business Systems Modernization
If you have any questions concerning this information, please contact me 

at (202) 512-3439 or by e-mail at hiter@gao.gov. Contact points for our 

Offices of Congressional Relations and Public Affairs may be found on the 

last page of this report. Key contributors to this report are listed in 

appendix III. 

Randolph C. Hite 

Director, Information Technology Architecture 

 and Systems Issues 

Page 28 GAO-07-451 Business Systems Modernization
List of Committees 

The Honorable Carl Levin 

Chairman 

The Honorable John McCain 

Ranking Member 

Committee on Armed Services 

United States Senate 

The Honorable Daniel Inouye 

Chairman 

The Honorable Ted Stevens 

Ranking Member 

Committee on Appropriations 

United States Senate 

The Honorable Ike Skelton 

Chairman 

The Honorable Duncan Hunter 

Ranking Member 

Committee on Armed Services 

House of Representatives 

The Honorable John P. Murtha 

Chairman 

The Honorable C.W. Bill Young 

Ranking Member 

Committee on Appropriations 

House of Representatives 

Page 29 GAO-07-451 Business Systems Modernization
Appendix II: Comments from Appendix I: Objective, Scope, and the Department of Defense 

Methodology 

Our objective was to determine what progress the Department of Defense 

(DOD) has made in defining its Business Mission Area federation strategy. 

To accomplish our objective, we reviewed DOD’s Business Mission Area 

Federation Strategy and Road Map released in September 2006, comparing 

the strategy and any associated implementation plans with prior findings 

and recommendations relative to the content of the strategy.

In particular, we compared the strategy with our prior recommendations 

for developing an architecture development management plan to define 

how the department intends to extend and evolve its business enterprise 

architecture. In addition, we compared the strategy with our prior findings 

and the need to ensure that shared systems and applications (i.e., services) 

are, among other things, defined, developed, exposed, and subscribed to 

via well-defined and standardized interfaces. Furthermore, we reviewed 

available information on activities, capabilities, products, and services 

associated with the federation strategy, such as the Investment 

Management Framework and the Architecture Compliance and 

Requirements Traceability User’s Guide. In addition, we interviewed key

program officials, including the director of the Business Transformation 

Agency’s Investment Management Directorate and the chief technical 

officer and representatives from the Office of the Assistant Secretary of 

Defense (Networks and Information Integration)/Chief Information 

Officer, and the Departments of the Air Force, Army, and Navy; the 

Defense Logistics Agency and Defense Information Systems Agency; and

the United States Transportation Command, to obtain an understanding of

the steps taken and required to develop and execute the federation 

strategy. 

We conducted our work at DOD headquarters offices in Arlington, 

Virginia, from August 2006 through March 2007 in accordance with 

generally accepted government auditing standards. 

Page 30 GAO-07-451 Business Systems Modernization
Appendix II: Comments from the Department Appendix II: Comments from the Department of Defense 

of Defense 

Page 31 GAO-07-451 Business Systems Modernization
Appendix II: Comments from the Department 

of Defense 

Page 32 GAO-07-451 Business Systems Modernization
Appendix II: Comments from the Department 

of Defense 

Page 33 GAO-07-451 Business Systems Modernization
Appendix II: Comments from the Department 

of Defense 

Page 34 GAO-07-451 Business Systems Modernization
Appendix II: Comments from the Department 

of Defense 

Page 35 GAO-07-451 Business Systems Modernization
Appendix II: Comments from the Department 

of Defense 

Page 36 GAO-07-451 Business Systems Modernization
Appendix II: Comments from the Department 

of Defense 

Page 37 GAO-07-451 Business Systems Modernization
Appendix III: GAO

St

 Contact and 

aff Acknowledgments

Page 38 GAO-07-451

Appendix III: GAO Contact and Staff 

Acknowledgments 

GAO Contact Randolph C. Hite, (202) 512-3439 or hiter@gao.gov

In addition to the contact person named above, key contributors to this 

report were Neil Doherty, Nancy Glover, Michael Holland, Neelaxi 

Lakhmani (Assistant Director), Anh Le, Jacqueline Mai, and Jennifer 

Stavros-Turner. 

Business Systems Modernization

Staff 

Acknowledgments 

(310628) 
GAO’s Mission The Government Accountability Office, the audit, evaluation and 

investigative arm of Congress, exists to support Congress in meeting its 

constitutional responsibilities and to help improve the performance and 

accountability of the federal government for the American people. GAO 

examines the use of public funds; evaluates federal programs and policies; 

and provides analyses, recommendations, and other assistance to help

Congress make informed oversight, policy, and funding decisions. GAO’s 

commitment to good government is reflected in its core values of 

accountability, integrity, and reliability. 

The fastest and easiest way to obtain copies of GAO documents at no cost

is through GAO’s Web site (www.gao.gov). Each weekday, GAO posts 

newly released reports, testimony, and correspondence on its Web site. To

have GAO e-mail you a list of newly posted products every afternoon, go 

to www.gao.gov and select “Subscribe to Updates.” 

The first copy of each printed report is free. Additional copies are $2 each. 

A check or money order should be made out to the Superintendent of 

Documents. GAO also accepts VISA and Mastercard. Orders for 100 or 

more copies mailed to a single address are discounted 25 percent. Orders 

should be sent to: 

U.S. Government Accountability Office 

441 G Street NW, Room LM 

Washington, D.C. 20548 

To order by Phone: Voice: (202) 512-6000 

TDD: (202) 512-2537 

Fax: (202) 512-6061 

Contact: 

Web site: www.gao.gov/fraudnet/fraudnet.htm

E-mail: fraudnet@gao.gov

Automated answering system: (800) 424-5454 or (202) 512-7470 

Gloria Jarmon, Managing Director, JarmonG@gao.gov (202) 512-4400 

U.S. Government Accountability Office, 441 G Street NW, Room 7125 

Washington, D.C. 20548 

Paul Anderson, Managing Director, AndersonP1@gao.gov (202) 512-4800

U.S. Government Accountability Office, 441 G Street NW, Room 7149 

Washington, D.C. 20548 

Obtaining Copies of 

GAO Reports and 

Testimony

Order by Mail or Phone 

To Report Fraud,

Waste, and Abuse in 

Federal Programs 

Congressional 

Relations 

Public Affairs 

PRINTED ON RECYCLED PAPER