This is the accessible text file for GAO report number GAO-07-451 
entitled 'Business Systems Modernization: Strategy for Evolving DOD’s 
Business Enterprise Architecture Offers a Conceptual Approach, but 
Execution Details Are Needed' which was released on April 16, 2007. 

This text file was formatted by the U.S. Government Accountability 
Office (GAO) to be accessible to users with visual impairments, as part 
of a longer term project to improve GAO products' accessibility. Every 
attempt has been made to maintain the structural and data integrity of 
the original printed product. Accessibility features, such as text 
descriptions of tables, consecutively numbered footnotes placed at the 
end of the file, and the text of agency comment letters, are provided 
but may not exactly duplicate the presentation or format of the printed 
version. The portable document format (PDF) file is an exact electronic 
replica of the printed version. We welcome your feedback. Please E-mail 
your comments regarding the contents or accessibility features of this 
document to Webmaster@gao.gov. 

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. 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. 

United States Government Accountability Office: 
GAO: 

Report to Congressional Committees: 

April 2007: 

Business Systems Modernization: 

Strategy for Evolving DOD’s Business Enterprise Architecture Offers a 
Conceptual Approach, but Execution Details Are Needed. 

GAO-07-451: 

GAO Highlights: 

Highlights of GAO-07-451, a report to congressional committees. 

Why GAO Did This Study: 

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 Found: 

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. 

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

[See PDF for image]

Source: GAO analysis of DOD data. 

[End of figure] 

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. 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. 

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. 

[hyperlink, http://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. 

[End of section] 

Contents: 

Letter: 

Results in Brief: 

Background: 

DOD Is in the Early Stages of Federating Its BEA and Much Remains to Be 
Decided and Accomplished: 

Conclusions: 

Recommendation for Executive Action: 

Agency Comments and Our Evaluation: 

Appendix I: Objective, Scope, and Methodology: 

Appendix II: Comments from the Department of Defense: 

Appendix III: GAO Contact and Staff Acknowledgments: 

Tables: 

Table 1: Number of Framework Elements That Were Fully, Partially, and 
Not Satisfied by the Military Departments: 

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

Figures: 

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

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

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:  

[End of section]  

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. [Footnote 
1] In 1995, we designated DOD’s business systems modernization program 
as “high risk,” and we continue to designate it as such today. 
[Footnote 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). [Footnote 3]  

Accordingly, we made recommendations to the Secretary of Defense in May 
2001 that included the means for effectively developing an EA. 
[Footnote 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 architecture (BEA) that had limited use. 
[Footnote 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 2005 [Footnote 6] that were 
consistent with our recommendations, including those for developing a 
BEA and associated enterprise transition plan (ETP). In 2006, [Footnote 
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 with generally accepted government auditing 
standards. Additional details on our objective, scope, and methodology 
are contained in appendix I. 

Results in Brief:  

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.  

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 plan 
[Footnote 8] by 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 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. 

Background:  

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, [Footnote 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. 

As we have previously reported, [Footnote 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. [Footnote 11] Eight of these 
areas are specific to DOD [Footnote 12] and the department shares 
responsibility for 7 other governmentwide high-risk areas. [Footnote 
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 1996 [Footnote 14] 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 [Footnote 15] 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. [Footnote 16]  

Enterprise Architecture: A Brief Description:  

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” [Footnote 
17] and the DOD Architecture Framework. [Footnote 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 
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. 
[Footnote 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 different component organizations. As we have 
previously reported, [Footnote 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 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. 

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, [Footnote 21] Business, [Footnote 22] DOD 
Intelligence, [Footnote 23] and Enterprise Information Environment. 
[Footnote 24] According to ASD(NII)/CIO officials, they are drafting a 
yet-to-be-released strategy for evolving DOD’s Global Information Grid 
architecture, [Footnote 25] 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.  

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

This figure is an organizational chart of the DOD Enterprise 
Architecture Federation Strategy. 

[See PDF for image]  

Source: GAO analysis of DOD data. 

[End of figure]  

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.  

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. [Footnote 26] Under tiered accountability, 
responsibility and accountability for business architectures and 
systems investment management was allocated among the DOD enterprise, 
[Footnote 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 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 DOD-wide 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. [Footnote 28] To address these 
concerns, in September 2003 [Footnote 29] 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 reported, [Footnote 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 2003 [Footnote 31] for developing an architecture development 
management plan that defined how it intended to extend and evolve its 
BEA.  

Accordingly, in May 2006 [Footnote 32] 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 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 2006 [Footnote 33] 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. [Footnote 34] In addition, the Army had 
only fully satisfied 1 of the 31 core elements. [Footnote 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: Air Force; 
Fully satisfied: 14; 
Partially satisfied: 8; 
Not satisfied: 9. 

Military departments: Army;
Fully satisfied: 1; 
Partially satisfied: 13; 
Not satisfied: 17. 

Military departments: Navy; 
Fully satisfied: 10; 
Partially satisfied: 12; 
Not satisfied: 9. 

Military departments: Total;
Fully satisfied: 25; 
Partially satisfied: 33; 
Not satisfied: 35. 

Source: GAO. 

[End of table]  

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 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 Is in the Early Stages of Federating Its BEA and Much Remains to Be 
Decided and Accomplished:  

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.  

BMA Federation Strategy Describes Goals, Concepts, and High-level 
Activities:  

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:  

* 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 component- and 
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. 

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:  

[See PDF for image] 

Source: GAO analysis of DOD data. 

[End of figure]  

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, [Footnote 
36] federating architecture operational views, [Footnote 37] and 
federating architecture systems views. [Footnote 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. 

* 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. 

[End of table]  

The BMA Federation Strategy Is Missing Executable Details:  

Relevant architecture management guidance [Footnote 39] 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. [Footnote 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. [Footnote 41] 

The high-level construct of DOD’s BMA federation strategy and the yet-
to-be-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 yet-to-be-issued DOD EA federation strategy, it does not clearly 
describe the 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.  

Governance Structure Is Not Clearly Defined:  

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.  

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, [Footnote 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 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 decision-making 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.  

Relationship to DOD EA Federation Strategy Effort Is Unclear:  

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:  

* 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 these linkages will be the responsibility of 
the programs, components, the BTA, or ASD(NII)/CIO.  

Operational View Federation Does Not Address Component Architecture 
Alignment:  

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.  

Systems View Federation Lacks Key Execution Details:  

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 infrastructure 
[Footnote 43] that will expose reusable 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, [Footnote 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. 

* 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.  

Strategy Does Not Include Milestones:  

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. 

Conclusions:  

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.  

Recommendation for Executive Action:  

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 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.  

Agency Comments and Our Evaluation:  

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 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 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 [hyperlink, 
http://www.gao.gov].  

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.  

Signed by:  

Randolph C. Hite: 
Director: 
Information Technology Architecture and Systems Issues:  

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:  

[End of section]  

Appendix I: Objective, Scope, and 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. 

[End of section]  

Appendix II: Comments from the Department of Defense:  

Office Of The Under Secretary Of Defense: 
3000 Defense Pentagon: 
Acquisition, Technology And Logistics: 
Washington, DC 20301-3000:  

April 3, 2007:  

Mr. Randolph Hite: 
Director: 
Information Technology Architecture and Systems Issues: 
U.S. Government Accountability Office: 
441 G Street, NW: 
Washington, DC 20548:  

Dear Mr. Hite: 

This is the Department of Defense (DoD) response to the GAO draft 
report 07-451, "Business Systems Modernization: Strategy for Evolving 
DOD's Business Enterprise Architecture Offers Conceptual Approach, But 
Execution Details Needed," dated March 1, 2007, (GAO Code 310628). 

This report examines two different, but related topics covered in the 
Business Mission Area (BMA) Federation Strategy, published last 
summer - the Department's approach to Architecture Federation and the 
evolution of the Services-Oriented Architecture (SOA) approach to 
creating an interoperable information environment across DoD. While 
both of these concepts have gained considerable momentum and have been 
evolving steadily within the various Mission Areas and Components of 
the Department, it is only recently that sufficient consensus around 
them has been established that specific strategies related to their 
global use and governance were deemed either appropriate or indeed 
possible. 

While the Business Mission Area has played a leading role in defining 
the Department's position on both Architecture Federation and SOA , the 
impact of these issues spans far beyond the scope of Business Systems 
Modernization. Any examination of these concepts must begin with the 
Department's approach, not the BMA's. The BMA Federation Strategy was 
written, not as stand alone documentation of the two concepts, but as 
an addendum to an Enterprise approach, detailing only those aspects 
specific to BMA requirements that would not be included in the DoD's 
enterprise approach. This being said, the Department recognizes that 
GAO's challenge in this study is complicated by the fact that many of 
the Enterprise-level strategy and governance documents, i.e. those to 
which BMA must comply, are still in draft mode. The Department did, 
however, share draft documents where possible to provide the broadest 
overview. A brief overview of the Department's position on these two 
topics follows: 

Architecture Federation – The Department's approach to Architecture 
Federation is described in the DoD Enterprise Architecture Federation 
Strategy. This document, although currently in draft (provided to GAO), 
has been widely circulated across the Department. It describes both the 
mechanisms that enable federation to exist among various Mission Area, 
Component and Program architectures and the responsibilities of each 
"tier" in ensuring that their architectures are compliant with 
enterprise standards. The final publication of this document is a near 
term priority of the DoD CIO. 

Other architecture federation strategies within the Department exist 
only to provide additional information, specific to an individual 
Mission Area or Component– not to repeat enterprise guidance. For 
example, the only discussion in the BMA Federation Strategy regarding 
architecture federation is the introduction of ACART, a tool used to 
assess compliance of Component and program business architectures with 
the BEA, architecture compliance being a key element to meeting FY05 
NDAA requirements All three Military Departments have mandated and are 
currently using ACART within their investment management processes to 
assess and ensure compliance of their systems and architectures with 
the BEA. In all other respects the BMA must align with the DoD 
Enterprise Architecture Federation Strategy. For reference, through the 
BEA, ETP and other guidance, the BMA has met or exceeded all 
requirements placed on mission area architectures in the draft DoD 
Enterprise Architecture Federation Strategy. 

Service-Oriented Architectures – This approach to information 
management and application development has recently gained great 
momentum both within the Department and the private sector. GAO's 
questions and recommendations regarding SOA generally fall into two 
categories: 1) how service opportunities / needs are identified, and 2) 
how services, once developed, are managed within the Department's 
infrastructure. The responsibility for these two activities lies in 
very different areas. 

* Service Identification - Each Mission area or Component identifies 
its own services requirement based on its internal analytical and 
investment management process. For the BMA, this process is described 
in the Business Transformation Guidance (BTG). While SOA services are 
not yet called out specifically in the BTG, the process for identifying 
the need and opportunity for IT services does not differ significantly 
from that of identifying other business capability information 
technology needs. Updates on the progress of identifying services, 
including specific milestones will be included in future editions of 
the Enterprise Transition Plan (ETP) along with all other 
transformation and system improvement milestones. 

* Services Management – The DoD CIO is responsible for defining the 
overall approach to how SOA services will be managed within the 
Department's infrastructure. Department-wide guidance and policies on 
using, operating, and managing services are currently in development. 
The DoD CIO is partnering with the DNI CIO, based on input from DoD 
Components, Mission Areas, and the Intelligence Community, to ensure 
consistent guidance is provided within relevant security domains, 
appropriate processes are implemented, and common governance forums are 
used to the maximum extent practible. 

Attached are the Department's specific responses to GAO recommendations 
regarding Architecture Federation and Services-Oriented Architecture. 
Where the Department "non concurs", we believe that the recommendation 
has either already been met in its entirety through both policy and 
implementation or duplicates or is embedded in other prior GAO 
recommendations. Where the Department "partially concurs", our concerns 
are generally not with the core intent of the recommendation, but 
rather that is it worded such that it: 

1. Is clearly achievable (i.e. worded in a fashion that allows DoD to 
take specific, reasonably-scoped steps in order to address and close 
the recommendation;  

2. Is directed to the appropriate parties within the Department, 
specifically those who actually have authority over and the ability to 
affect solutions to the issues raised in the recommendation. In several 
cases, GAO's recommendations ask for DoD Enterprise guidance or policy 
on issues, in which case there is no Business Mission Area-specific 
component to the solution. 

GAO continues to be a valuable and constructive partner in the 
Department's efforts to transform internal business operations. 
Analysis of our plans and activities, as well as recommendations for 
refinement, provides important learning on best practices as we move 
forward. We especially appreciate the support and recognition for the 
Department's continued progress in driving success. We welcome GAO's 
insights and look forward to their participation in our future 
efforts.  

Signed by:  

David Wennergren: 
DoD Deputy Chief Information Officer:  

Signed by:  

Paul A. Brinkley: 
Deputy Under Secretary of Defense (Business Transformation):  

Gao Draft Report Dated March 1, 2007: GAO-07-451 (GAO Code 310628):  

Recommendation 1: The GAO is augmenting a prior recommendation 
regarding the business enterprise architecture (BEA) development 
management plan by recommending that the Secretary of Defense direct 
the Deputy Secretary of Defense, to have the appropriate DoD 
organizations, including ASD(NII)/CIO and the Director of the Business 
Transformation Agency (BTA) ensure that the BEA plan describes, how 
architecture federation will be governed. 

DOD Response: Partially Concur – Policy and guidance regarding how 
architectures are to be managed within the Department's federated 
environment is the responsibility of the ASD(NII)/CIO. Such policy and 
guidance shapes how all Mission Areas and Components will participate. 
There are no requirements or responsibilities for the Business Mission 
Area that differ from those of other mission areas. While there is a 
current gap in the Enterprise-wide guidance, DoD has acknowledged the 
shortfall and it will soon be addressed by the formal issuance of the 
DoD Enterprise Architecture Federation Strategy, of which the GAO has 
the current draft. 

The BMA's Federation Strategy's only contribution to the concept of 
Architecture Federation is to augment the draft DoD Enterprise 
Architecture Federation Strategy by introducing the tool (ACART) that 
will be used to facilitate assessment of compliance of Component and 
Program business architectures with the BEA during the IRB process, 
consistent with FY05 NDAA requirements. In every other respect, the BMA 
adheres to architecture federation rules established in the draft DoD 
Enterprise Architecture Federation Strategy. It is not the role of the 
BMA Federation Strategy to repeat the enterprise strategy or explain 
how the enterprise strategy is being implemented. 

This recommendation would be more appropriately directed if stated as 
follows: ".......that the DEPSECDEF direct the ASD(NII)/CIO to issue 
the appropriate enterprise guidance that describes how architecture 
federation will be managed and governed across the Department of 
Defense. Each of the Department's Mission Areas (including the BMA 
representing the BEA) and Components should then be charged with 
building their architecture plans in compliance with this guidance." 

Recommendation 2: The GAO is augmenting a prior recommendation 
regarding the BEA development management plan by recommending that the 
Secretary of Defense direct the Deputy Secretary of Defense, to have 
the appropriate DoD organizations, including ASD(NII)/CIO and the 
Director of the BTA ensure that the BEA plan describes how alignment 
with other federation strategies will be achieved. (p. 30/GAO Draft 
Report) 

DOD Response: Non Concur – There is a single Architecture Federation 
Strategy for the Department of the Defense. That strategy, DoD 
Enterprise Architecture Federation Strategy, is currently in draft and 
was provided to GAO during the audit. This strategy describes the 
principles guiding how architecture federation will work and details 
the roles and responsibilities of Mission Area, Component and program 
architectures within the overall environment. It cannot be overstated 
that federation adheres to tiered accountability principles, where each 
tier is responsible for aligning its own architecture and 
transformation into DoD's strategic direction. In that context, all 
other architecture federation "strategies" within the Department exist 
for the sole purpose of supplementing the DoD Enterprise Architecture 
Federation Strategy, to provide Mission Area or Component-specific 
information that would not be appropriate in the enterprise strategy. 
The BMA Federation Strategy is a good example of this in that it only 
addresses tools used in assessing BEA compliance in order to meet FY05 
NDAA requirements. Given these facts, this recommendation is not 
needed, or at best is already implied/embedded in the previous 
recommendation. 

Recommendation 3: The GAO is augmenting a prior recommendation 
regarding the BEA development management plan by recommending that the 
Secretary of Defense direct the Deputy Secretary of Defense, to have 
the appropriate DoD organizations, including ASD(NII)/CIO and the 
Director of the BTA ensure that the BEA plan describes how component 
architectures alignment with incremental versions of the BEA will be 
achieved. (p. 30/GAO Draft Report) 

DOD Response: Non-Concur – This recommendation has already been fully 
implemented both in policy and execution. The FY05 NDAA requires that 
all business systems be certified as compliant with the enterprise-wide 
Business Enterprise Architecture. The Department has issued appropriate 
guidance to that affect, both in the form of guidance as to what is 
required to adhere to the IRB process as well as guidance specific to 
assessing architecture compliance. These guidances are reviewed and 
modified, as necessary, on an annual basis to ensure they are up-to-
date with current learning, practice, tools and versions of the 
architecture. 

The Department has gone further and developed a specific tool (ACART), 
which is continually updated to reflect the most recent release of the 
BEA, to help the Component assess compliance of their Component or 
system architectures with the BEA's current release. This tool is 
currently in use widely across the Department and has been specifically 
mandated by Directive by each of the military services as the tool that 
must be used to assess compliance with the BEA. 

Recommendation 4: The GAO is augmenting a prior recommendation 
regarding the BEA development management plan by recommending that the 
Secretary of Defense direct the Deputy Secretary of Defense, to have 
the appropriate DoD organizations, including ASD(NII)/CIO and the 
Director of the BTA ensure that the BEA plan describes how shared 
services will be identified, exposed, and subscribed to. (p. 30/GAO 
Draft Report) 

DOD Response: Partially Concur – This recommendation actually asks two 
very different questions: 1) how service opportunities / needs are 
identified, and 2) how services, once developed, are managed within the 
Department's infrastructure. The responsibility for these two sets of 
issues lies in very different areas. 

* Service Identification - Each mission area or component identifies 
its own services requirement based on its internal analytical and 
investment management process. For the BMA, this process is described 
in the Business Transformation Guidance (BTG). While SOA services are 
not yet called out specifically in the BTG, the process for identifying 
the need and opportunity for IT services does not differ significantly 
from that of identifying other business capability information 
technology needs. Updates on the progress of identifying services, 
including specific milestones will be included in future editions of 
the Enterprise Transition Plan (ETP) along with all other 
transformation and system improvement milestones. 

* Services Management – The DoD CIO is responsible for defining the 
overall approach to how SOA services will be managed within the 
Department's infrastructure. Department-wide guidance and policies on 
using, operating, and managing services are currently in development. 
The DoD CIO is partnering with the DNI CIO, based on input from DoD 
Components, Mission Areas, and the Intelligence Community, to ensure 
consistent guidance is provided within relevant security domains, 
appropriate processes are implemented, and common governance forums are 
used to the maximum extent practible.  

Given these facts, the Department believes that the GAO's 
recommendation would be more effective if reworded to direct the 
ASD(NII)/CIO to issue enterprise policy or guidance that establishes 
the framework within which all SOA services (including those identified 
by the BMA) will be managed and direct all Mission Areas and Components 
to adhere to this direction. No further tasking is required for the 
BMA. 

Recommendation 5: The GAO is augmenting a prior recommendation 
regarding the BEA development management plan by recommending that the 
Secretary of Defense direct the Deputy Secretary of Defense, to have 
the appropriate DoD organizations, including ASD(NII)/CIO and the 
Director of the BTA ensure that the BEA plan describes what milestones 
will be used to measure progress and results. (p. 30/GAO Draft Report) 

DOD Response: Non-Concur – It is unclear as to how this recommendation 
specifically relates to the topics addressed in this report. Looking at 
this strictly from a BMA perspective: 

1. Architecture Federation - The BEA currently meets those milestones 
that have been established for participating in DoD's federated 
architecture in the draft DoD Enterprise Architecture Federation 
Strategy. The BEA exists and is appropriately registered in the 
Department's architecture repository (DARS). There is a clearly defined 
mechanism in place that allows for assessment of compliance of other 
architectures within the federated environment with the BEA. Other 
future architecture federation requirements, such as the creation of a 
mission area taxonomy have also been met (in the BEA's case through the 
OV-5). As further architecture federation requirements are identified, 
these will be monitored in the BMA's Enterprise Transition Plan along 
with all other Business Transformation program milestones.  

2. Services Development - Following the path of leading government and 
commercial organizations worldwide, DoD is enabling business agility 
through a modular, federated integration of applications – SOA. This 
approach allows service development and deployment to become more 
consistent across the enterprise. Within that context, the development 
of specific SOA services is little different from the development and 
implementation of other capabilities. New applications can be developed 
and deployed as services and existing applications can provide and 
consume these services. They result from the same process detailed in 
the Business Transformation Guidance (BTG) and will (and already have 
been) be detailed in the milestones detailed in the BMA's Enterprise 
Transition Plan. Repeating the milestones in the BEA would be a 
redundant effort and is unnecessary. 

Given this, it is the Department's belief that this recommendation asks 
the Department to do something the GAO has already recognized that the 
Department is doing. 

[End of section]  

Appendix III: GAO Contact and Staff Acknowledgments:  

GAO Contact:  

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

Staff Acknowledgments:  

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.  

[End of section]  

Footnotes:  

[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). 

[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). 

[8] GAO-06-658. 

[9] GAO-06-658.  

[10] See, 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). 

[11] GAO-07-310.  

[12] These 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.  

[13] The 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.  

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

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

[16] GAO, 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).  

[17] John A. Zachman, “A Framework for Information Systems 
Architecture,” IBM Systems Journal 26, No. 3 (1987).  

[18] DOD, Department of Defense Architecture Framework, Version 1.0, 
Volume 1 (August 2003) and Volume 2 (February 2004).  

[19] See, 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).  

[20] GAO, 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).  

[21] The 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.  

[22] The 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.  

[23] The 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.  

[24] The 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.  

[25] According 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.  

[26] Under 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.  

[27] The DOD enterprise is comprised of the entities in the Office of 
the Secretary of Defense—the DBSMC, the BTA, and the Investment Review 
Boards.  

[28] See, 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.  

[29] GAO-03-1018.  

[30] GAO, 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).  

[31] GAO-03-1018.  

[32] GAO-06-658.  

[33] GAO, Enterprise Architecture: Leadership Remains Key to 
Establishing and Leveraging Architectures for Organizational 
Transformation, GAO-06-831 (Washington, D.C.: Aug. 14, 2006).  

[34] GAO, Information Technology: A Framework for Assessing and 
Improving Enterprise Architecture Management (Version 1.1), GAO-03-584G 
(Washington, D.C.: April 2003).  

[35] We did not review the enterprise architecture programs at other 
DOD components, such as the Defense Information Systems Agency or the 
DLA.  

[36] According 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.  

[37] The 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).  

[38] The 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.  

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

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

[41] GAO-07-19.  

[42] The 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.  

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

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

[End of section]  

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.  

Obtaining Copies of GAO Reports and Testimony:  

The fastest and easiest way to obtain copies of GAO documents at no 
cost is through GAO's Web site [hyperlink, http://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 [hyperlink, http://www.gao.gov] 
and select "Subscribe to Updates."  

Order by Mail or Phone:  

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:  

To Report Fraud, Waste, and Abuse in Federal Programs:  

Contact:  

Web site: [hyperlink, http://www.gao.gov/fraudnet/fraudnet.htm]: 
E-mail: fraudnet@gao.gov: 
Automated answering system: (800) 424-5454 or (202) 512-7470:  

Congressional Relations:  

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:  

Public Affairs:  

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: