Business Systems Modernization: Strategy for Evolving DOD's	 
Business Enterprise Architecture Offers a Conceptual Approach,	 
but Execution Details Are Needed (16-APR-07, GAO-07-451).	 
                                                                 
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. 
-------------------------Indexing Terms------------------------- 
REPORTNUM:   GAO-07-451 					        
    ACCNO:   A68224						        
  TITLE:     Business Systems Modernization: Strategy for Evolving    
DOD's Business Enterprise Architecture Offers a Conceptual	 
Approach, but Execution Details Are Needed			 
     DATE:   04/16/2007 
  SUBJECT:   Defense capabilities				 
	     Enterprise architecture				 
	     Information technology				 
	     Interoperability					 
	     Standards						 
	     Strategic planning 				 
	     Systems conversions				 
	     Program goals or objectives			 
	     Program implementation				 
	     GAO High Risk Series				 

******************************************************************
** This file contains an ASCII representation of the text of a  **
** GAO Product.                                                 **
**                                                              **
** No attempt has been made to display graphic images, although **
** figure captions are reproduced.  Tables are included, but    **
** may not resemble those in the printed version.               **
**                                                              **
** Please see the PDF (Portable Document Format) file, when     **
** available, for a complete electronic file of the printed     **
** document's contents.                                         **
**                                                              **
******************************************************************
GAO-07-451

   

     * [1]Results in Brief
     * [2]Background

          * [3]Enterprise Architecture Is Critical to Achieving Successful

               * [4]Enterprise Architecture: A Brief Description

          * [5]DOD's Efforts to Adopt a Federated Approach to Architecting
          * [6]DOD Roles and Responsibilities for BEA Development and Use
          * [7]Summary of GAO's Prior Reviews on DOD's Architecture Efforts

     * [8]DOD Is in the Early Stages of Federating Its BEA and Much Re

          * [9]BMA Federation Strategy Describes Goals, Concepts, and High-
          * [10]The BMA Federation Strategy Is Missing Executable Details

               * [11]Governance Structure Is Not Clearly Defined
               * [12]Relationship to DOD EA Federation Strategy Effort Is
                 Unclear
               * [13]Operational View Federation Does Not Address Component
                 Archi
               * [14]Systems View Federation Lacks Key Execution Details
               * [15]Strategy Does Not Include Milestones

     * [16]Conclusions
     * [17]Recommendation for Executive Action
     * [18]Agency Comments and Our Evaluation
     * [19]GAO Contact
     * [20]Staff Acknowledgments
     * [21]GAO's Mission
     * [22]Obtaining Copies of GAO Reports and Testimony

          * [23]Order by Mail or Phone

     * [24]To Report Fraud, Waste, and Abuse in Federal Programs
     * [25]Congressional Relations
     * [26]Public Affairs

Report to Congressional Committees

United States Government Accountability Office

GAO

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

Contents

Letter 1

Results in Brief 3
Background 5
DOD Is in the Early Stages of Federating Its BEA and Much Remains to Be
Decided and Accomplished 15
Conclusions 24
Recommendation for Executive Action 24
Agency Comments and Our Evaluation 25
Appendix I Objective, Scope, and Methodology 30
Appendix II Comments from the Department of Defense 31
Appendix III GAO Contact and Staff Acknowledgments 38

Tables

Table 1: Number of Framework Elements That Were Fully, Partially, and Not
Satisfied by the Military Departments 14
Table 2: High-level Steps for Achieving Operational and Systems View
Federation 18

Figures

Figure 1: Simplified Depiction of the DOD Enterprise Architecture
Federation Strategy 10
Figure 2: Simplified Diagram of DOD's Business Mission Area Federated
Architecture 17

Abbreviations

ASD(NII)/CIO Assistant Secretary of Defense (Networks and Information
Integration)/Chief Information Officer
BEA business enterprise architecture
BMA Business Mission Area
BTA Business Transformation Agency
CIO Chief Information Officer
DBSMC Defense Business Systems Management Committee
DISA Defense Information Systems Agency
DLA Defense Logistics Agency
DOD Department of Defense
EA enterprise architecture
ETP enterprise transition plan
IT information technology
OMB Office of Management and Budget
SOA service-oriented architecture

This is a work of the U.S. government and is not subject to copyright
protection in the United States. It may be reproduced and distributed in
its entirety without further permission from GAO. However, because this
work may contain copyrighted images or other material, permission from the
copyright holder may be necessary if you wish to reproduce this material
separately.

United States Government Accountability Office
Washington, DC 20548

April 16, 2007

Congressional Committees

For decades, the Department of Defense (DOD) has been challenged in
repeated attempts to modernize its timeworn business systems.^1 In 1995,
we designated DOD's business systems modernization program as "high risk,"
and we continue to designate it as such today.^2 As our research on public
and private sector organizations has shown, one essential ingredient to a
successful systems modernization program is having and using a
well-defined enterprise architecture (EA).^3

Accordingly, we made recommendations to the Secretary of Defense in May
2001 that included the means for effectively developing an EA.^4 In July
2001, the department initiated a business management modernization program
to, among other things, develop one. Between 2001 and 2005, we reported
that the department's business management modernization program was not
being effectively managed, concluding in 2005 that hundreds of millions of
dollars had been spent on a business enterprise architecture (BEA) that
had limited use.^5 Accordingly, we made additional architecture-related
recommendations.

^1Business 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.

^2GAO, High-Risk Series: An Update, [27]GAO-07-310 (Washington, D.C.:
January 2007).

^3An 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.

^4GAO, Information Technology: Architecture Needed to Guide Modernization
of DOD's Financial Operations, [28]GAO-01-525 (Washington, D.C.: May 17,
2001).

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^6 that were consistent with our
recommendations, including those for developing a BEA and associated
enterprise transition plan (ETP). In 2006,^7 we reported that, among other
things, DOD had made important progress in developing its BEA, but that
much remained to be accomplished relative to the act's requirements and
relevant guidance. For example, we reported that the BEA was not
adequately linked to the military departments and defense agency
architectures. To address these shortfalls, DOD issued a strategy for
"federating" or extending its architecture.

To support GAO's legislative mandate to review DOD's BEA and as agreed
with your offices, the objective of this review was to determine DOD's
progress in defining its Business Mission Area (BMA) federation strategy.
To accomplish our objective, we compared the federation strategy and
associated plans with prior findings and recommendations relative to the
content of the strategy, and interviewed DOD officials regarding the
strategy's executability. We performed our work at DOD headquarters in
Arlington, Virginia, from August 2006 through March 2007 in accordance
with generally accepted government auditing standards. Additional details
on our objective, scope, and methodology are contained in appendix I.

^5See, for example, [29]GAO-01-525 ; GAO, DOD Business Systems
Modernization: Improvements to Enterprise Architecture Development and
Implementation Efforts Needed, [30]GAO-03-458 (Washington, D.C.: Feb. 28,
2003); Information Technology: Observations on Department of Defense's
Draft Enterprise Architecture, [31]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,
[32]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, [33]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, [34]GAO-04-731R (Washington, D.C.: May
17, 2004); DOD Business Systems Modernization: Billions Being Invested
without Adequate Oversight, [35]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, [36]GAO-05-702
(Washington, D.C.: July 22, 2005).

^6Ronald W. Reagan National Defense Authorization Act for Fiscal Year
2005, Pub. L. No. 108-375, S 332, 118 Stat. 1811, 1851-1856 (Oct. 28,
2004) (codified in part at 10 U.S.C. S 2222).

^7GAO, Business Systems Modernization: DOD Continues to Improve
Institutional Approach, but Further Steps Needed, [37]GAO-06-658
(Washington, D.C.: May 15, 2006).

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^8 by recommending
that this plan provide for effective execution of its BMA federation
strategy.

^8 [38]GAO-06-658 .

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,^9 the DOD systems
environment that supports these business functions is overly complex and
error-prone, and is characterized by (1) little standardization across the
department, (2) multiple systems performing the same tasks, (3) the same
data stored in multiple systems, and (4) the need for data to be entered
manually into multiple systems. Moreover, DOD recently reported that this
systems environment is comprised of approximately 3,100 separate business
systems. For fiscal year 2006, Congress appropriated approximately $15.5
billion to DOD, and for fiscal year 2007, DOD has requested about $16
billion in appropriated funds to operate, maintain, and modernize these
business systems and associated infrastructure.

^9 [39]GAO-06-658 .

As we have previously reported,^10 the department's nonintegrated and
duplicative systems contribute to fraud, waste, and abuse. In fact, DOD
currently bears responsibility, in whole or in part, for 15 of our 27
high-risk areas.^11 Eight of these areas are specific to DOD^12 and the
department shares responsibility for 7 other governmentwide high-risk
areas.^13 DOD's business systems modernization is one of the high-risk
areas, and it is an essential enabler to addressing many of the
department's other high-risk areas. For example, modernized business
systems are integral to the department's efforts to address its financial,
supply chain, and information security management high-risk areas.

Enterprise Architecture Is Critical to Achieving Successful Business Systems
Modernization

Effective use of an enterprise architecture--a modernization blueprint--is
a hallmark of successful public and private organizations. For more than a
decade, we have promoted the use of architectures to guide and constrain
systems modernization, recognizing them as a crucial means to this
challenging goal: optimally defined operational and technological
environments. Congress, the Office of Management and Budget (OMB), and the
federal Chief Information Officer's (CIO) Council have also recognized the
importance of an architecture-centric approach to modernization. The
Clinger-Cohen Act of 1996^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^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.^16

10See, for example, GAO, Defense Inventory: Opportunities Exist to Improve
Spare Parts Support Aboard Deployed Navy Ships, [40]GAO-03-887
(Washington, D.C.: Aug. 29, 2003); Military Pay: Army National Guard
Personnel Mobilized to Active Duty Experienced Significant Pay Problems,
[41]GAO-04-89 (Washington, D.C.: Nov. 13, 2003); and DOD Travel Cards:
Control Weaknesses Resulted in Millions of Dollars of Improper Payments,
[42]GAO-04-576 (Washington, D.C.: June 9, 2004).

^11 [43]GAO-07-310 .

^12These high-risk areas include DOD's overall approach to business
transformation, business systems modernization, financial management, the
personnel security clearance program, supply chain management, support
infrastructure management, weapon systems acquisition, and contract
management.

^13The 7 governmentwide high-risk areas are as follows: (1) disability
programs, (2) ensuring the effective protection of technologies critical
to U.S. national security interests, (3) interagency contracting, (4)
information systems and critical infrastructure, (5) information-sharing
for homeland security, (6) human capital, and (7) real property.

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

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

  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"^17 and the DOD
Architecture Framework.^18

The importance of developing, implementing, and maintaining an enterprise
architecture is a basic tenet of both organizational transformation and
systems modernization. Managed properly, an enterprise architecture can
clarify and help optimize the interdependencies and relationships among an
organization's business operations (and the underlying IT infrastructure
and applications) that support these operations. Moreover, when an
enterprise architecture is employed in concert with other important
management controls, such as portfolio-based capital planning and
investment control practices, architectures can greatly increase the
chances that an organization's operational and IT environments will be
configured to optimize mission performance. Our experience with federal
agencies has shown that investing in IT without defining these investments
in the context of an architecture often results in systems that are
duplicative, not well integrated, and unnecessarily costly to maintain and
interface.^19

16GAO, Information Technology Investment Management: A Framework for
Assessing and Improving Process Maturity, [44]GAO-04-394G (Washington,
D.C.: March 2004); CIO Council, A Practical Guide to Federal Enterprise
Architecture, Version 1.0 (February 2001); and OMB Capital Programming
Guide, Version 1.0 (July 1997).

^17John A. Zachman, "A Framework for Information Systems Architecture,"
IBM Systems Journal 26, No. 3 (1987).

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

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

^19See, for example, GAO, Homeland Security: Efforts Under Way to Develop
Enterprise Architecture, but Much Work Remains, [45]GAO-04-777
(Washington, D.C.: Aug. 6, 2004); [46]GAO-04-731R ; Information
Technology: Architecture Needed to Guide NASA's Financial Management
Modernization, [47]GAO-04-43 (Washington, D.C.: Nov. 21, 2003);
[48]GAO-03-1018 ; [49]GAO-03-877R ; Information Technology: DLA Should
Strengthen Business Systems Modernization Architecture and Investment
Activities, [50]GAO-01-631 (Washington, D.C.: June 29, 2001); and
Information Technology: INS Needs to Better Manage the Development of Its
Enterprise Architecture, and [51]GAO/AIMD-00-212 (Washington, D.C.: Aug.
1, 2000).

DOD's Efforts to Adopt a Federated Approach to Architecting All of Its Mission
Areas

The Office of the Assistant Secretary of Defense (Networks and Information
Integration)/Chief Information Officer (ASD(NII)/CIO), reports that it is
developing a strategy for federating the many and varied architectures
across the department's four mission areas--Warfighting,^21 Business,^22
DOD Intelligence,^23 and Enterprise Information Environment.^24 According
to ASD(NII)/CIO officials, they are drafting a yet-to-be-released strategy
for evolving DOD's Global Information Grid architecture,^25 so that it
provides a comprehensive architectural description of the entire DOD
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.

^20GAO, Information Technology: FBI Has Largely Staffed Key Modernization
Program, but Strategic Approach to Managing Program's Human Capital Is
Needed, [52]GAO-07-19 (Washington, D.C.: Oct. 16, 2006).

^21The Warfighting Mission Area focuses on transforming how DOD achieves
its mission objectives by addressing joint warfighting capabilities and
providing life-cycle oversight to applicable DOD component and combatant
command IT investments.

^22The Business Mission Area is responsible for ensuring that
capabilities, resources, and materiel are reliably delivered to the
warfighter. Specifically, the BMA addresses areas such as real property
and human resources management.

^23The DOD Intelligence Mission Area is focused on establishing advanced
capabilities to anticipate adversaries and includes IT investments within
the military intelligence program and defense component programs of the
National Intelligence Program.

^24The Enterprise Information Environment Mission Area enables the
functions of the other mission areas (e.g., Warfighting Mission Area,
Business Mission Area, and National Intelligence Mission Area) and
encompasses all communications, computing, and core enterprise service
systems, equipment, or software that provides a common information
capability or service for enterprise use.

^25According to DOD, the Global Information Grid consists of a globally
interconnected, end-to-end set of information capabilities, associated
processes, and personnel for collecting, processing, storing,
disseminating, and managing information on demand to warfighters,
policymakers, and support personnel, and as such represents the
department's IT architecture.

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

ASD(NII)/CIO officials stated that the goal of this strategy is to improve
the ability of DOD's mission areas, components, and programs to share
architectural information. In this regard, officials stated that the DOD
EA federation strategy will define (1) federation and integration
concepts, (2) alignment (i.e., linking and mapping) processes, and (3)
shared services.

The BMA federation strategy, according to these officials, is the first
mission area federation strategy, and it is their expectation that the
other mission areas will develop their own respective federation
strategies.

DOD Roles and Responsibilities for BEA Development and Use

In 2005, the department reassigned responsibility for directing,
overseeing, and executing its business transformation and systems
modernization efforts to the Defense Business Systems Management Committee
(DBSMC) and the Business Transformation Agency (BTA). At that time, it
also adopted a tiered accountability approach to business
transformation.^26 Under tiered accountability, responsibility and
accountability for business architectures and systems investment
management was allocated among the DOD enterprise,^27 component, and
program levels, depending on such factors as the scope, size, and
complexity of each investment.

The DBSMC is chaired by the Deputy Secretary of Defense and serves as the
highest-ranking governance body for business systems modernization
activities. According to its charter, the DBSMC provides strategic
direction and plans for the BMA in coordination with the Warfighting and
Enterprise Information Environment Mission Areas. The DBSMC is also
responsible for reviewing and approving the BEA and the ETP. In addition,
the DBSMC recommends policies and procedures required to integrate DOD
business transformation and attain cross-department, end-to-end
interoperability of business systems and processes.

The BTA operates under the authority, direction, and control of the DBSMC
and reports to the Under Secretary of Defense for Acquisition, Technology,
and Logistics in the incumbent's capacity as the vice chair of the DBSMC.
Oversight for this agency is provided by the Deputy Under Secretary of
Defense for Business Transformation, and day-to-day management is provided
by the director. The BTA's primary responsibility 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.

^26Under a tiered accountability approach, the BEA describes the
envisioned processes, systems, and standards and components are
responsible for defining a component-level architecture associated with
their own tier of responsibility in alignment with the BEA's
enterprisewide standards and requirements.

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

Under DOD's tiered accountability approach to systems modernization,
components are responsible for defining their respective component
architectures and transition plans while complying with BEA and ETP policy
and requirements. Similarly, program managers are responsible for
developing program-level architectures and transition plans and ensuring
integration with the architectures and transition plans developed and
executed at the DOD enterprise and component levels.

Summary of GAO's Prior Reviews on DOD's Architecture Efforts

Between May 2001 and July 2005, we reported on DOD's efforts to develop an
architecture and identified serious problems and concerns with the
department's architecture program, including the lack of specific plans
outlining how DOD plans to extend and evolve the architecture to include
the missing scope and detail.^28 To address these concerns, in September
2003^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,^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).

^28See, for example, [53]GAO-01-525 , [54]GAO-03-458 , [55]GAO-03-571R ,
[56]GAO-03-877R , [57]GAO-03-1018 , [58]GAO-04-731R , [59]GAO-05-381 , and
[60]GAO-05-702 .

^29 [61]GAO-03-1018 .

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^31 for developing an
architecture development management plan that defined how it intended to
extend and evolve its BEA.

Accordingly, in May 2006^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.

^30GAO, Defense Business Transformation: A Comprehensive Plan, Integrated
Efforts, and Sustained Leadership Are Needed to Assure Success,
[62]GAO-07-229T (Washington, D.C.: Nov. 16, 2006).

^31 [63]GAO-03-1018 .

^32 [64]GAO-06-658 .

Our August 2006^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.^34 In addition, the Army had only fully satisfied 1 of the 31
core elements.^35 (See table 1 for the number of elements that were fully,
partially, and not satisfied by each of the military departments.)

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

Military departments Fully satisfied Partially satisfied Not satisfied 
Air Force                         14                   8             9 
Army                               1                  13            17 
Navy                              10                  12             9 
Total                             25                  33            35 

Source: GAO.

By comparison, the other major federal departments and agencies that we
reviewed had as a whole fully satisfied about 67 percent of the
framework's core elements. Among the key elements that all three military
departments had not fully satisfied were developing architecture products
that describe their respective target architectural environments and
developing transition plans for migrating to a target environment.

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

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

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

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:

           o establish a capability to search for data in member
           architectures that may be relevant for analysis, reference, or
           reuse;

           o 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;

           o 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

           o 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

To support the achievement of its goals and implementation of its
concepts, the strategy also describes three categories of high-level
activities, capabilities, products, and services--governance,^36
federating architecture operational views,^37 and federating architecture
systems views.^38 Table 2 shows the strategy's operational and systems
view related activities, capabilities, products, and services.

^36According to the strategy, governance addresses how the BMA federated
approach will be implemented across DOD components by describing the new
responsibilities imposed on the existing business systems governance
structures resulting from the federation.

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.                                                                  

^37The DOD Architecture Framework defines the operational view as a
description of the tasks and activities, operational elements, and
information exchanges required to accomplish DOD missions. Federating
architecture operational views, according to the BMA strategy, is an
approach for gaining visibility across the various business architectures
by enabling linkages and alignment among these various BMA architectures'
activities, processes, and data (e.g., DOD, component, and program).

^38The DOD Architecture Framework defines the systems view as a set of
graphical and textual products that describe systems and interconnections
providing for or supporting DOD functions. Federating architecture system
views, according to the BMA strategy, is an approach for the delivery of
shared business systems and information services within a SOA through an
IT infrastructure.

Source: DOD.

The BMA Federation Strategy Is Missing Executable Details

Relevant architecture management guidance^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.^40 We also have previously
reported that a SOA approach needs to ensure that shared systems and
applications (i.e., services) are, among other things, defined, developed,
exposed, and subscribed to.^41

The high-level construct of DOD's BMA federation strategy and the
yet-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.

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

^40 [68]GAO-03-1018 and [69]GAO-06-658 .

^41 [70]GAO-07-19 .

  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:

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

           o The strategy states that in conjunction with the DOD investment
           review boards,^42 the DBSMC will set the business priorities at
           the enterprise level through the identification of gaps in
           business capabilities. By establishing these priorities, the DBSMC
           is to determine where and when specific capabilities are addressed
           within the different architectures (i.e., from 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.

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

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

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

           o 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^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,^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:

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

           o 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.
		   
^42The investment review boards serve as the oversight and investment
decision-making bodies for those business capabilities that support
activities under their designated areas of responsibility.

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

^44Metadata are data used to supplement information to main data.
		   
           o 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 http://www.gao.gov .

           If you have any questions concerning this information, please
           contact me at (202) 512-3439 or by e-mail at [email protected].
           Contact points for our Offices of Congressional Relations and
           Public Affairs may be found on the last page of this report. Key
           contributors to this report are listed in appendix III.

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

           List of Committees

           The Honorable Carl Levin		   
		   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
		   
		   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.
		   
		   Appendix II: Comments from the Department of Defense
		   
		   Appendix III: GAO Contact and Staff Acknowledgments
		   
		   GAO Contact

           Randolph C. Hite, (202) 512-3439 or [email protected]
		   
		   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.
		   
		   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 ( www.gao.gov ). Each
           weekday, GAO posts newly released reports, testimony, and
           correspondence on its Web site. To have GAO e-mail you a list of
           newly posted products every afternoon, go to www.gao.gov and
           select "Subscribe to Updates."
		   
		   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: www.gao.gov/fraudnet/fraudnet.htm E-mail:
           [email protected] Automated answering system: (800) 424-5454 or
           (202) 512-7470
		   
		   Congressional Relations

           Gloria Jarmon, Managing Director, [email protected] (202)
           512-4400 U.S. Government Accountability Office, 441 G Street NW,
           Room 7125 Washington, D.C. 20548
		   
		   Public Affairs

           Paul Anderson, Managing Director, [email protected] (202)
           512-4800 U.S. Government Accountability Office, 441 G Street NW,
           Room 7149 Washington, D.C. 20548

(310628)

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
[email protected].

Highlights of [80]GAO-07-451 , a 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

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.

[81]What GAO Recommends

To assist DOD in its efforts to evolve and extend its BEA, GAO is
augmenting a prior recommendation to the Secretary of Defense for
developing an architecture development management plan by recommending
that this plan incorporate details needed to execute DOD's Business
Mission Area federation strategy. In comments, DOD largely disagreed with
GAO's recommendation, noting that elements of it were either unnecessary
or not appropriately focused.

DOD's Business Mission Area federation strategy for extending its BEA to
the military departments and defense agencies provides a foundation on
which to build and align the department's parent business architecture
(the BEA) with its subordinate architectures (i.e., component- and
program-level architectures). (See figure.) In particular, the strategy,
which was released in September 2006, states the department's federated
architecture goals; describes federation concepts that are to be applied;
and explains high-level activities, capabilities, products, and services
that are intended to facilitate implementation of the concepts.

Simplified Diagram of DOD's Business Mission Area Federated Architecture

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.

References

Visible links
  27. http://www.gao.gov/cgi-bin/getrpt?GAO-07-310
  28. http://www.gao.gov/cgi-bin/getrpt?GAO-01-525
  29. http://www.gao.gov/cgi-bin/getrpt?GAO-01-525
  30. http://www.gao.gov/cgi-bin/getrpt?GAO-03-458
  31. http://www.gao.gov/cgi-bin/getrpt?GAO-03-571R
  32. http://www.gao.gov/cgi-bin/getrpt?GAO-03-877R
  33. http://www.gao.gov/cgi-bin/getrpt?GAO-03-1018
  34. http://www.gao.gov/cgi-bin/getrpt?GAO-04-731R
  35. http://www.gao.gov/cgi-bin/getrpt?GAO-05-381
  36. http://www.gao.gov/cgi-bin/getrpt?GAO-05-702
  37. http://www.gao.gov/cgi-bin/getrpt?GAO-06-658
  38. http://www.gao.gov/cgi-bin/getrpt?GAO-06-658
  39. http://www.gao.gov/cgi-bin/getrpt?GAO-06-658
  40. http://www.gao.gov/cgi-bin/getrpt?GAO-03-887
  41. http://www.gao.gov/cgi-bin/getrpt?GAO-04-89
  42. http://www.gao.gov/cgi-bin/getrpt?GAO-04-576
  43. http://www.gao.gov/cgi-bin/getrpt?GAO-07-310
  44. http://www.gao.gov/cgi-bin/getrpt?GAO-04-394G
  45. http://www.gao.gov/cgi-bin/getrpt?GAO-04-777
  46. http://www.gao.gov/cgi-bin/getrpt?GAO-04-731R
  47. http://www.gao.gov/cgi-bin/getrpt?GAO-04-43
  48. http://www.gao.gov/cgi-bin/getrpt?GAO-03-1018
  49. http://www.gao.gov/cgi-bin/getrpt?GAO-03-877R
  50. http://www.gao.gov/cgi-bin/getrpt?GAO-01-631
  51. http://www.gao.gov/cgi-bin/getrpt?GAO/AIMD-00-212
  52. http://www.gao.gov/cgi-bin/getrpt?GAO-07-19
  53. http://www.gao.gov/cgi-bin/getrpt?GAO-01-525
  54. http://www.gao.gov/cgi-bin/getrpt?GAO-03-458
  55. http://www.gao.gov/cgi-bin/getrpt?GAO-03-571R
  56. http://www.gao.gov/cgi-bin/getrpt?GAO-03-877R
  57. http://www.gao.gov/cgi-bin/getrpt?GAO-03-1018
  58. http://www.gao.gov/cgi-bin/getrpt?GAO-04-731R
  59. http://www.gao.gov/cgi-bin/getrpt?GAO-05-381
  60. http://www.gao.gov/cgi-bin/getrpt?GAO-05-702
  61. http://www.gao.gov/cgi-bin/getrpt?GAO-03-1018
  62. http://www.gao.gov/cgi-bin/getrpt?GAO-07-229T
  63. http://www.gao.gov/cgi-bin/getrpt?GAO-03-1018
  64. http://www.gao.gov/cgi-bin/getrpt?GAO-06-658
  65. http://www.gao.gov/cgi-bin/getrpt?GAO-06-831
  66. http://www.gao.gov/cgi-bin/getrpt?GAO-03-584G
  67. http://www.gao.gov/cgi-bin/getrpt?GAO-03-584G
  68. http://www.gao.gov/cgi-bin/getrpt?GAO-03-1018
  69. http://www.gao.gov/cgi-bin/getrpt?GAO-06-658
  70. http://www.gao.gov/cgi-bin/getrpt?GAO-07-19
  80. http://www.gao.gov/cgi-bin/getrpt?GAO-07-451
*** End of document. ***