DOD Business Systems Modernization
Important Progress Made to Develop Business Enterprise Architecture, but Much Work Remains Gao ID: GAO-03-1018 September 19, 2003The National Defense Authorization Act for Fiscal Year 2003 directed the Department of Defense (DOD) to develop an enterprise architecture and a transition plan that meets certain requirements. The act also directed DOD to have a process for controlling its system investments. As required by the act, GAO assessed DOD's actions to comply with the act's requirements and recently issued a report to congressional defense committees. This report provides further details of GAO's assessment results regarding (1) the extent to which DOD's actions complied with the requirements of the act and (2) DOD's plans for further development and implementation of its architecture.
DOD has expended tremendous effort and resources and made important progress in complying with the act's requirements aimed at developing and effectively implementing a well-defined business enterprise architecture. Further, DOD's initial version of its architecture provides a foundation from which to build and ultimately produce a well-defined architecture. For example, the "As Is" environment includes an inventory of about 2,300 existing systems and their characteristics that support DOD's current business operations; and the "To Be" environment addresses, to at least some degree, how DOD intends to operate in the future, what information will be needed to support these future operations, and what technology standards should govern the design of future systems. Further, DOD has established some of the architecture management capabilities advocated by best practices and federal guidance, such as having a program office, designating a chief architect, and using an architecture development methodology and automated tool. At the same time, DOD's initial architecture does not yet adequately address the act's requirements and other relevant architectural requirements governing the scope and content. For example, critical federal requirements governing the "To Be" architecture, such as federal accounting requirements for recording revenue, are not included in the initial architecture. Other items not included are descriptions of the current business operations in terms of entities and people who perform the functions, processes, and activities and the locations where these are performed; descriptions of the systems to be developed or acquired to support future business operations; and time frames for phasing out existing systems. Furthermore, DOD has not yet implemented an effective investment management process for selecting and controlling ongoing and planned business system investments. Until it does, DOD remains at risk of spending billions of dollars on duplicative, stove-piped, nonintegrated systems that do not optimize mission performance and accountability and, therefore, do not support the department's business transformation goals. Overall, our findings indicate that DOD has taken positive first steps, but much remains to be accomplished before DOD will have the kind of blueprint and associated investment controls to successfully modernize its business operations and supporting systems. According to program officials and the initial version of the transition plan, DOD intends to extend and evolve the architecture to include the missing scope and detail; however, it has not yet defined specific plans outlining how this will be accomplished.
RecommendationsOur recommendations from this work are listed below with a Contact for more information. Status will change from "In process" to "Open," "Closed - implemented," or "Closed - not implemented" based on our follow up work.
Director: Team: Phone:GAO-03-1018, DOD Business Systems Modernization: Important Progress Made to Develop Business Enterprise Architecture, but Much Work Remains
This is the accessible text file for GAO report number GAO-03-1018
entitled 'DOD Business Systems Modernization: Important Progress Made
to Develop Business Enterprise Architecture, but Much Work Remains'
which was released on September 19, 2003.
This text file was formatted by the U.S. General Accounting 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.
Report to Congressional Committees:
September 2003:
DOD BUSINESS SYSTEMS MODERNIZATION:
Important Progress Made to Develop Business Enterprise Architecture,
but Much Work Remains:
[Hyperlink, http://www.gao.gov/cgi-bin/getrpt?GAO-03-1018] GAO-03-
1018:
GAO Highlights:
Highlights of GAO-03-1018, a report to congressional committees
Why GAO Did This Study:
The National Defense Authorization Act for Fiscal Year 2003 directed
the Department of Defense (DOD) to develop an enterprise architecture
and a transition plan that meets certain requirements. The act also
directed DOD to have a process for controlling its system investments.
As required by the act, GAO assessed DOD‘s actions to comply with the
act‘s requirements and recently issued a report to congressional
defense committees. This report provides further details of GAO‘s
assessment results regarding (1) the extent to which DOD‘s actions
complied with the requirements of the act and (2) DOD‘s plans for
further development and implementation of its architecture.
What GAO Found:
DOD has expended tremendous effort and resources and made important
progress in complying with the act‘s requirements aimed at developing
and effectively implementing a well-defined business enterprise
architecture. Further, DOD‘s initial version of its architecture
provides a foundation from which to build and ultimately produce a
well-defined architecture. For example, the ’As Is“ environment
includes an inventory of about 2,300 existing systems and their
characteristics that support DOD‘s current business operations; and
the ’To Be“ environment addresses, to at least some degree, how DOD
intends to operate in the future, what information will be needed to
support these future operations, and what technology standards should
govern the design of future systems. Further, DOD has established some
of the architecture management capabilities advocated by best
practices and federal guidance, such as having a program office,
designating a chief architect, and using an architecture development
methodology and automated tool.
At the same time, DOD‘s initial architecture does not yet adequately
address the act‘s requirements and other relevant architectural
requirements governing the scope and content. For example, critical
federal requirements governing the ’To Be“ architecture, such as
federal accounting requirements for recording revenue, are not
included in the initial architecture. Other items not included are
* descriptions of the current business operations in terms of entities
and people who perform the functions, processes, and activities and
the locations where these are performed;
* descriptions of the systems to be developed or acquired to support
future business operations; and
* time frames for phasing out existing systems.
Furthermore, DOD has not yet implemented an effective investment
management process for selecting and controlling ongoing and planned
business system investments. Until it does, DOD remains at risk of
spending billions of dollars on duplicative, stove-piped,
nonintegrated systems that do not optimize mission performance and
accountability and, therefore, do not support the department‘s
business transformation goals.
Overall, our findings indicate that DOD has taken positive first
steps, but much remains to be accomplished before DOD will have the
kind of blueprint and associated investment controls to successfully
modernize its business operations and supporting systems. According to
program officials and the initial version of the transition plan, DOD
intends to extend and evolve the architecture to include the missing
scope and detail; however, it has not yet defined specific plans
outlining how this will be accomplished.
What GAO Recommends:
To further assist DOD in its efforts to effectively develop and
implement an enterprise architecture and to guide and constrain its
business system investments, GAO is making recommendations to the
Secretary of Defense aimed at improving DOD‘s plans for developing the
next version of the architecture and implementing the institutional
means for selecting and controlling both planned and ongoing business
system investments. DOD concurred with 9 of our 10 recommendations,
partially concurred with the remaining one, and described completed,
ongoing, or planned actions to address them.
www.gao.gov/cgi-bin/getrpt?GAO-03-1018
To view the full product, including the scope and methodology, click
on the link above. For more information, contact Gregory Kutz, (202)
512-9095 (kutzg@gao.gov) or Randolph Hite, (202) 512-3439
(hiter@gao.gov).
[End of section]
Contents:
Letter:
Results in Brief:
Background:
DOD Has Taken Positive First Steps in Complying with Enterprise
Architecture Legislative Requirements, but Much Remains to be
Accomplished:
DOD's Plans for Evolving and Extending Its Enterprise Architecture and
for Improving Business System Investment Decision Making Are Unclear:
Conclusions:
Recommendations:
Agency Comments and Our Evaluation:
Appendixes:
Appendix I: SEC. 1004. [of Public Law 107-314] Development and
Implementation of Financial Management Enterprise Architecture:
Appendix II: Scope and Methodology:
Appendix III: Status of Prior Recommendations on DOD's Business
Enterprise Architecture:
Appendix IV: Comments from the Department of Defense:
Appendix V: GAO Contacts and Staff Acknowledgments:
GAO Contacts:
Acknowledgments:
Tables:
Table 1: Interrelationship Between Domains and Business Process Areas:
Table 2: Summary of GAO's Enterprise Architecture (EA) Maturity
Framework Stages:
Table 3: Assessment of DOD's Enterprise Architecture Efforts Against
GAO's Enterprise Architecture Maturity Framework:
Table 4: Summary of GAO Analysis of JFMIP Requirements:
Table 5: Detailed Analysis of the Extent to Which DOD's "As Is"
Architecture Satisfies Key Elements:
Table 6: Detailed Analysis of the Extent to Which DOD's "To Be"
Architecture Satisfies Key Elements:
Table 7: Detailed Analysis of the Extent to Which DOD's Transition Plan
Satisfies Key Architectural Elements:
Figures:
Figure 1: Interdependent C4ISR Views:
Figure 2: Summary of Extent to Which Version 1.0 of DOD's Enterprise
Architecture Satisfies Key Elements Governing Architectural Content:
Letter September 19, 2003:
Congressional Committees:
Our research of successful public and private sector organizations
shows that attempting a large-scale systems modernization program
without having a well-defined modernization blueprint--commonly called
an enterprise architecture--and effective investment management
controls, results in systems that are duplicative, are not well-
integrated, are unnecessarily costly to maintain and interface, and do
not effectively optimize mission performance. Accordingly, in May
2001[Footnote 1] we recommended that the Department of Defense (DOD)
develop an enterprise architecture to guide and constrain its almost
$20 billion annual investment in business systems and establish the
investment controls needed to implement this architecture. In July
2001, DOD initiated a program to, among other things, address our
recommendations, and began developing a DOD-wide business enterprise
architecture (BEA) in April 2002. This effort is an essential part of
the Secretary of Defense's broad initiative to "transform the way the
department works and what it works on.":
The National Defense Authorization Act for Fiscal Year 2003[Footnote 2]
required DOD to develop by May 1, 2003, a financial management
enterprise architecture[Footnote 3] and a transition plan for
implementing the architecture that meet certain requirements. The act
also requires DOD to control expenditures for financial system
improvements while the architecture and transition plan are being
developed and after they are completed. The act states that the
enterprise architecture shall describe an information infrastructure
that, at a minimum, would enable DOD to achieve certain capabilities,
such as complying with all federal accounting, financial management,
and reporting requirements. The act also requires development of a
transition plan for implementing the enterprise architecture that
includes, among other things, a schedule for phasing out existing
systems that will not become part of the "To Be" environment. Finally,
before the architecture and transition plan are approved, the act
requires DOD to review proposed obligations of funds in amounts
exceeding $1 million for financial system improvements to determine if
they meet specific conditions called for in the act. Once the
architecture and transition plan are approved, the act requires DOD to
ensure that obligations exceeding $1 million for financial system
investments are consistent with the architecture and the transition
plan.
The act also directs us to submit to congressional defense committees,
within 60 days of DOD's approval of its enterprise architecture and its
transition plan, an assessment of DOD's actions taken to comply with
these requirements. (See app. I for a copy of section 1004 of the act.)
We recently issued a report to satisfy this requirement.[Footnote 4]
This report provides specific details on our assessment results
regarding (1) the extent to which DOD's actions complied with the
requirements of the act and (2) DOD's plans for further development and
implementation of its enterprise architecture. It also makes
recommendations to the Secretary of Defense for improving DOD's
architecture development, maintenance, and implementation efforts,
including restricting investments in systems until the architecture is
sufficiently defined and effective controls are in place for ensuring
new investments are aligned with it.
We performed our work from March 2003 through June 2003 in accordance
with U.S. generally accepted government auditing standards. Details on
our scope and methodology are included in appendix II. We requested
comments on a draft of this report from the Secretary of Defense or his
designee. Written comments from the Under Secretary of Defense
(Comptroller) are addressed in the "Agency Comments and Our Evaluation"
section of this report and are reprinted in appendix IV.
Results in Brief:
As we reported in February 2003,[Footnote 5] DOD undertook a
challenging and ambitious task--to develop within 1 year a
departmentwide architecture for modernizing its current financial and
business operations and systems. Thus far, DOD has expended tremendous
effort and resources and made important progress in complying with the
legislative requirements aimed at developing and effectively
implementing a well-defined enterprise architecture. Concerning
progress, the department has established some of the architecture
management capabilities advocated by best practices and federal
guidance,[Footnote 6] such as having a program office, designating a
chief architect, and using an architecture development methodology and
automated tool. Further, DOD's initial version of its BEA provides a
foundation from which to build and ultimately produce a well-defined
business enterprise architecture. For example, the "As Is" descriptions
include an inventory of about 2,300 systems in operation or under
development, and their characteristics, that support DOD's current
business operations. The "To Be" descriptions address, to at least some
degree, how DOD intends to operate in the future, what information will
be needed to support these future operations, and what technology
standards should govern the design of future systems.
At the same time, the initial version does not yet adequately address
the act's requirements and other relevant architectural
requirements.[Footnote 7] For example,
* While DOD has incorporated many relevant external requirements from
152 federal sources in developing its "To Be" architecture products,
critical federal requirements governing the "To Be" architecture, such
as federal accounting requirements for recording revenue, are not
included. As a result, the architecture's descriptions of certain
business processes, such as those associated with revenue accounting
and reporting, which include over $70 billion earned annually by
working capital fund activities, are not complete.
* The "As Is" environment provides little descriptive content and does
not satisfy 90 percent of the architectural elements required by
relevant guidance, such as descriptions of the current business
operations in terms of the entities/people who perform the functions,
processes, and activities, and the locations where the functions,
processes, and activities are performed. As a result, DOD does not have
a sufficiently described picture of its current environment to permit
development of a meaningful and useful transition plan.
* The "To Be" architecture does not provide sufficient descriptive
content related to future business operations and supporting technology
to permit effective acquisition and implementation of system solutions
and associated operational change. For example, it does not include
descriptions of the actual systems to be developed or acquired to
support future business operations and the physical infrastructure
(e.g., hardware and software) that will be needed to support the
business systems. As a result, the "To Be" environment lacks the
details needed to provide DOD with a common vision and frame of
reference for defining a transition plan to guide and constrain capital
investments, and thus to effectively leverage technology to orchestrate
logical, systematic change and optimize enterprisewide mission
performance.
* The transition plan does not possess the attributes needed to provide
a temporal roadmap for moving from the "As Is" to the "To Be"
environment and is basically a plan to develop a transition plan. For
example, such information as time frames for phasing out existing
systems within DOD's current inventory of about 2,300 systems, and
resource requirements for implementing the "To Be" architecture, are
not part of the transition plan. As a result, DOD does not yet have a
meaningful and reliable basis for managing the disposition of its
existing inventory of about 2,300 systems or for sequencing the
introduction of modernized business operations and supporting systems.
Moreover, DOD has not yet defined and implemented an effective approach
to select and control business systems investments[Footnote 8] for
obligations exceeding $1 million while the architecture is being
developed and after it is completed. Since enactment of the act, as of
June 6, 2003, DOD had approved one business system improvement for $10
million that met this $1 million threshold and was currently reviewing
four others. Our analysis of DOD's fiscal years 2003 and 2004
information technology (IT) budget requests shows that over 200
business systems in each year's budget, totaling about $4 billion per
year, could involve obligations of funds that meet the $1 million
threshold. This indicates that the majority of the billions of dollars
that DOD invests in business system improvements annually have not been
subject to the scrutiny of the DOD Comptroller now called for in the
act. Overall, our findings indicate that DOD has taken positive first
steps, but much remains to be accomplished before DOD will have the
kind of blueprint and associated investment controls needed to
successfully modernize its financial management operations and
supporting business systems.
DOD's position is that, to varying degrees, the initial version of its
architecture fully satisfies the act's requirements, but it also
recognizes that the architecture needs to be expanded and extended to
provide a sufficient basis for guiding and constraining investment
decisions. DOD's position is also that it has taken steps to implement
the act's requirements regarding approving system investments, but that
it needs to do more to effectively select and control business system
investments. DOD attributes the current state of its architecture and
investment management processes to the limited time it has had to
define and implement each, in part because it was overly optimistic in
estimating what it could deliver by May 1, 2003. Until DOD develops and
provides for effective implementation of a well-defined enterprise
architecture, its ability to modernize its business and systems
environments in a way that minimizes risk and maximizes return on
investment will be severely hindered.
According to program officials and the initial version of the
transition plan, DOD intends to extend and evolve the architecture to
include the missing scope and detail. However, it has not defined
specific plans outlining how this will be accomplished. Rather, DOD's
current plan is to develop a strategy for producing the next version of
its architecture, and managing ongoing and planned investments. Among
other things, this strategy is to provide for:
* determining the resources needed to further develop the architecture;
* developing a methodology for integrating the architecture with other
internal and external architectures;
* establishing an approach for maintaining its existing systems
inventory; and:
* evaluating the architecture for completeness, accuracy, and
integration of end-to-end business processes and system functions.
In addition, DOD program documentation provides for initiating pilot
projects in the near term that are to demonstrate and implement a
portion of the architecture and be usable across the department.
However, DOD officials stated that the pilot projects are intended to
validate departmentwide business processes and not to implement
production systems. Because of these differing views of what the pilot
projects are intended to achieve, the purpose and scope of these
projects remain unclear, and specific projects have yet to be selected.
To assist DOD, we are making recommendations to the Secretary of
Defense aimed at improving its plans for developing the next version of
the architecture and implementing the institutional means for selecting
and controlling both planned and ongoing system investments. DOD
concurred with 9 of our 10 recommendations, partially concurred with
the remaining one, and described actions recently completed, ongoing,
or planned to implement them.
Background:
DOD is one of the largest and most complex organizations in the world.
In fiscal year 2002, DOD reported that its operations involve about
$700 billion in assets, nearly $1.5 trillion in liabilities,
approximately 3.3 million military and civilian personnel, and
disbursements of over $346 billion. Moreover, execution of these
operations spans a wide range of defense organizations, including the
military services and their respective major commands and functional
activities, numerous large defense agencies and field activities, and
various combatant and joint operational commands that are responsible
for military operations for specific geographic regions or theaters of
operations. To execute these military operations, the department
performs an assortment of interrelated and interdependent business
functions, including logistics management, procurement, healthcare
management, and financial management.
The department's pervasive problems in performing these business
functions are well chronicled by the DOD Inspector General, the
military service audit agencies, and us. Of the 25 areas in the federal
government that we have designated as high risk, 6 are DOD program
areas (i.e., systems modernization management, financial management,
contract management, inventory management, support infrastructure
management, and weapon systems acquisition), and DOD shares
responsibility for 3 of the governmentwide high-risk areas (i.e.,
strategic human capital management, protecting information systems and
critical infrastructures, and federal real property).[Footnote 9] DOD's
problems in each of these areas hinder the efficiency of operations,
and leave the department vulnerable to fraud, waste, and abuse.
To support its business functions, DOD reports that it currently relies
on about 2,300 systems, including accounting, acquisition, logistics,
and personnel. As we have previously reported,[Footnote 10] this
environment was not designed to be, but rather has evolved into, an
overly complex, and error-prone IT environment, including (1) little
standardization across DOD, (2) multiple systems performing the same
tasks, (3) the same data stored in multiple systems, and (4) manual
data entry into multiple systems. For fiscal year 2003, DOD requested
approximately $26 billion in IT funding to support a wide range of
military operations as well as DOD business system operations.
Approximately $18 billion--nearly $5.2 billion for business systems and
$12.8 billion primarily for business systems infrastructure--relates to
the operation, maintenance, and modernization of DOD's business
systems. The remaining $8 billion relates primarily to command and
control systems, including the infrastructure to support these systems.
One of the seven key elements we have reported[Footnote 11] as
necessary to successfully execute the department's business systems
modernization program is establishing and implementing an enterprise
architecture. Subsequently, in its fiscal year 2002 Performance and
Accountability Report, DOD acknowledged that deficiencies in its
systems and business processes hindered the department's ability to
collect and report financial and performance information that is
accurate, reliable, and timely. The report noted that to address its
systemic problems and assist in the transformation of the department's
business operations, the department had undertaken the development and
implementation of a business enterprise architecture, or modernization
blueprint. Table 1 shows the scope of DOD's business operations,
including business domains owners, and related business process areas
and supporting functions.
Table 1: Interrelationship Between Domains and Business Process Areas:
Domain: Acquisition/Procurement; Domain owner: Under Secretary of
Defense (Acquisition, Technology and Logistics); Business process
areas: Procurement and Acquisition; Business process functions:
Identifying a need and procuring and acquiring goods and services to
satisfy the need (includes managing contracts and purchase card
programs).
Domain: Finance, Accounting Operations, and Financial Management;
Domain owner: Under Secretary of Defense (Comptroller/Chief Financial
Officer); Business process areas: Accounting; Collection, Accounts
Receivable, and Cash Management; Payables and Disbursing;
Financial and Management Reporting; Business process functions:
Identifying, measuring, recording, and communicating economic
information about an organization (includes developing and maintaining
DOD standard accounting structure, policies, and cost accounting);
Recording, tracking, managing, monitoring, liquidating, and collecting
amounts due to DOD (includes reconciling fund balance with Treasury);
Receiving payment requests, determining payment due dates, and
issuing payment; Providing accurate, reliable, and timely financial
and management information.
Domain: Human Resource Management; Domain owner: Under Secretary of
Defense (Personnel and Readiness); Business process areas: Human
Resource Management; Business process functions: Facilitating entry to
the organization, developing and managing careers, managing benefits
and pay, executing policies and procedures, and managing employee
information.
Domain: Logistics; Domain owner: Under Secretary of Defense
(Acquisition, Technology and Logistics); Business process areas:
Logistics; Business process functions: Planning, controlling, and
carrying out the efficient and effective movement and maintenance of
forces (includes inventory and personal property management).
Domain: Strategic Planning and Budgeting; Domain owner: Under Secretary
of Defense (Comptroller/Chief Financial Officer); Business process
areas: Strategic Planning and Budgeting; Business process functions:
Strategic planning, developing the programs and the budget, and
executing the budget.
Domain: Installations and Environment; Domain owner: Under Secretary of
Defense (Acquisition, Technology and Logistics); Business process
areas: Real Property and Environmental Liabilities; Business process
functions: Managing all real property and environmental controls.
Domain: Technical Infrastructure; Domain owner: Assistant Secretary of
Defense (Networks and Information Integration)/Chief Information
Officer[A]; Business process areas: All of the above; Business process
functions: Providing foundation for enterprise data management,
reporting, enterprise and technical services, and standards and policy
(includes information assurance).
Source: GAO analysis of DOD data.
[A] Formerly known as Assistant Secretary of Defense (Command, Control,
Communications and Intelligence)/Chief Information Officer.
[End of table]
Enterprise Architecture Is Critical to DOD's Ability to Improve Its
Business Functions:
Effective use of enterprise architectures is a trademark of successful
public and private organizations. For a decade, we have promoted the
use of architectures, recognizing them as a crucial means to a
challenging goal: agency operational structures that are optimally
defined, in both business and technological environments. The Congress,
the Office of Management and Budget (OMB), and the federal Chief
Information Officer (CIO) Council also have recognized the importance
of an architecture-centric approach to modernization. For example, the
Clinger-Cohen Act of 1996[Footnote 12] mandates that an agency's CIO
develop, maintain, and facilitate the implementation of an architecture
within the agency and that the agency's decisions to invest in IT
satisfy specified criteria and take into account the agency's business
processes. Further, OMB has issued guidance[Footnote 13] that, among
other things, requires system investments to be consistent with these
architectures.
What Is an Enterprise Architecture?
An enterprise architecture 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 both the enterprise's current or "As Is" operational and
technological environment and its target or "To Be" environment, as
well as a capital investment roadmap for transitioning from the current
to the target environment. These snapshots further consist of "views,"
which are basically one or more architecture products that provide
conceptual or logical representations of the enterprise.
The concept of enterprise architectures dates back to the mid-1980s. At
that time, John Zachman, widely recognized as a leader in the field of
enterprise architecture, identified the need to use a logical
construction blueprint (i.e., an architecture) for defining and
controlling the integration of systems and their components.[Footnote
14] Accordingly, Zachman developed a structure or "framework" for
defining and capturing an architecture. In his work, Zachman drew
parallels to the field of classical architecture and later to the
aircraft manufacturing industry, in which different work products
(e.g., architect plans, contractor plans, shop plans, and bills of
lading) represent different views of the planned building or aircraft.
Similarly, Zachman's framework identified the kinds of work products
needed for people to understand and thus build a given system or
entity. This framework provides for six windows from which to view the
enterprise, which Zachman terms "perspectives" on how a given entity
operates: those of (1) the strategic planner, (2) the system user,
(3) the system designer, (4) the system developer, (5) the
subcontractor, and (6) the system itself. Zachman also proposed six
abstractions or models associated with each of these perspectives:
these models cover (1) how the entity operates, (2) what the entity
uses to operate, (3) where the entity operates, (4) who operates the
entity, (5) when entity operations occur, and (6) why the entity
operates. Zachman's framework provides a way to identify and describe
an entity's existing and planned component parts and the parts'
relationships before one begins the costly and time-consuming efforts
associated with developing or transforming the entity.
Since Zachman introduced his framework, a number of other frameworks
have been proposed. In February 1998, DOD directed its components to
use its Command, Control, Communications, Computers, Intelligence,
Surveillance, and Reconnaissance (C4ISR) Architecture Framework,
Version 2.0. The C4ISR architecture framework defines the type and
content of architectural artifacts, as well as the relationships among
artifacts, that are needed to produce a useful enterprise architecture.
Briefly, the framework decomposes an enterprise architecture into three
primary views (windows into how the enterprise operates): the
operational, systems, and technical views. According to DOD, the three
interdependent views are needed to ensure that IT systems are developed
and implemented in an interoperable and cost-effective manner. (See
fig. 1 for an illustration of the three views.):
Figure 1: Interdependent C4ISR Views:
[See PDF for image]
[End of figure]
More recently, OMB established the Federal Enterprise Architecture
Program Management Office to develop a federated enterprise
architecture according to a collection of five "reference models":
* The Business Reference Model is intended to describe the business
operations of the federal government independent of the agencies that
perform them, including defining the services provided to state and
local governments.
* The Performance Reference Model is to provide a common set of general
performance outputs and measures for agencies to use to achieve
business goals and objectives.
* The Data and Information Reference Model is to describe, at an
aggregate level, the type of data and information that support program
and business line operations, and the relationships among these types.
* The Service Component Reference Model is to identify and classify IT
service (i.e., application) components that support federal agencies
and promote the reuse of components across agencies.
* The Technical Reference Model is to describe how technology is
supporting the delivery of service components, including relevant
standards for implementing the technology.
These post-Zachman frameworks differ in their nomenclatures and
modeling approach. However, the frameworks consistently provide for
defining an enterprise's operations in both (1) logical terms, such as
interrelated business processes and business rules, information needs
and flows, and work locations and users, and (2) technical terms, such
as hardware, software, data, communications, and security attributes
and performance standards. The frameworks also provide for defining
these perspectives both for the enterprise's "As Is" and "To Be"
environments, as well as a transition plan for moving from the "As Is"
to the "To Be" environment.
The importance of developing, implementing, and maintaining an
enterprise architecture is a basic tenet of both organizational
transformation and IT management. 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. 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
organizations' operational and IT environments will be configured so as
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 15]
Subsection 1004(b) of the act (see app. I) also defines elements
required of DOD's enterprise architecture that are consistent with the
above mentioned enterprise architecture guidance and requirements.
Specifically, DOD's financial management enterprise architecture (its
BEA) must define an information infrastructure that would enable DOD to
meet certain requirements and it must include policies, procedures,
data standards, and system interface requirements applicable uniformly
throughout DOD.
Prior Reviews of DOD's Enterprise Architecture Efforts Have Identified
Challenges and Weaknesses:
For the last 2 years, GAO has addressed the need for and reviewed DOD's
efforts to develop an enterprise architecture for modernizing its
business operations and systems and made recommendations to assist DOD
in successfully developing the architecture and using it to gain
control over its ongoing business system investments.
In particular, we reported in May 2001[Footnote 16] that the department
had neither an enterprise architecture for its financial and financial-
related business operations, nor the management structure, processes,
and controls in place to effectively develop and implement one. We also
reported that the department planned to spend billions of dollars on
new and modified business systems that would function independently
from one another and outside the context of an enterprise architecture.
We concluded that if the department continued down this path, it would
only perpetuate its existing business operations and systems
environment, which we described as duplicative, not interoperable,
unnecessarily costly to maintain and interface, and not optimizing
mission performance and accountability. We made eight recommendations
to the Secretary of Defense aimed at providing the means for
effectively developing and implementing an enterprise architecture. Of
the eight recommendations, DOD has fully implemented one, partially
implemented five, and has not yet implemented two.
In February 2003,[Footnote 17] we reported that while DOD is following
some enterprise architecture and IT investment management processes and
controls, it is not following others, in part, because it was focused
on meeting an ambitious schedule. More specifically, with respect to
developing the architecture, we reported that DOD had yet to (1)
establish a governance structure and process controls needed to ensure
ownership of and accountability for the architecture across the
department, (2) clearly communicate to intended stakeholders its
purpose, scope, and approach to developing the architecture, and (3)
define and implement an independent quality assurance process.
We also reported in our February 2003 report that, while DOD had taken
some initial steps aimed at improving its management of ongoing
business system investments, DOD had yet to (1) establish an investment
governance structure and process to align ongoing investments with its
architectural goals and direction, (2) establish and apply common
investment criteria to its ongoing IT system projects, and (3) conduct
a comprehensive review of its ongoing IT investments to ensure they are
consistent with architecture development efforts. We reiterated our
earlier recommendations and made six new recommendations to the
Secretary of Defense to assist DOD in successfully developing an
enterprise architecture and using it to gain control over its ongoing
business system investments. Of the six recommendations we made, DOD
has partially implemented two but has not yet implemented the remaining
four.
In March 2003,[Footnote 18] we reported on DOD's draft version of the
BEA, dated February 7, 2003, and concluded that it did not include a
number of items recommended by relevant architectural guidance and that
DOD's plans would not fully satisfy the act's requirements. For
example, the draft architecture did not include a "To Be" security
view, which defines the security requirements, including relevant
standards to be applied in implementing security policies, procedures,
and controls. We did not make recommendations because this draft was a
work in process that was changing daily. However, DOD officials agreed
with our preliminary assessment of the architecture and stated that
subsequent versions of the architecture would provide these missing
details.
See appendix III for details on the status of all our recommendations,
including our assessment of DOD's actions.
DOD Has Taken Positive First Steps in Complying with Enterprise
Architecture Legislative Requirements, but Much Remains to be
Accomplished:
DOD has made important progress in complying with the legislative
requirements to develop and effectively implement a well-defined
enterprise architecture. The department has (1) elected an incremental
approach to developing its architecture, (2) adopted some of the
architecture management capabilities advocated by best practices and
federal guidance,[Footnote 19] such as designating a chief architect,
and (3) developed initial versions of architecture products that
provide a foundation upon which to build. Nevertheless, DOD's initial
architecture lacks sufficient scope and content to fully satisfy
legislative requirements, satisfy relevant architecture guidance, and
make informed decisions about systems investments. Moreover, DOD has
yet to implement an effective investment management process to select
and control ongoing and planned business system investments.
DOD Is Following an Incremental Approach to Developing Its
Architecture:
Our research and experience show that for major program investments,
such as the development of an enterprise architecture, successful
organizations approach product development in an incremental fashion,
meaning that they initially develop a foundational product that is
expanded and extended through a series of follow-on products that add
more capability and value. In doing so, these organizations can
effectively mitigate the enormous risk associated with trying to
deliver a large and complex product that requires the execution of many
activities over an extended period of time as a single monolithic
product. In effect, this incremental approach permits a large
undertaking to be broken into a series of smaller projects, or
incremental versions, that can be better controlled to provide
reasonable assurance that expectations are met.
For its enterprise architecture development program, we have recognized
and told DOD that given its plans, capabilities, and status, it would
not be able to produce and approve a complete version of its
architecture by May 1, 2003. Accordingly, we advised DOD to adopt an
incremental approach to developing and implementing its architecture
and to represent its architecture product to stakeholders as an initial
version and to define its plans for evolving and extending this initial
version to satisfy the act and create a well-defined blueprint.
Recognizing these obstacles, DOD has adopted an incremental approach.
Specifically, DOD has designated its architecture as version 1.0 and
has committed to building on this in producing subsequent versions.
According to DOD, the next significant delivery of the BEA is currently
planned for May 2004.
DOD Has Recently Adopted Some, but Not All Key Elements of Architecture
Management Best Practices:
Effective process controls for managing architecture development,
maintenance, and implementation are recognized hallmarks of successful
public and private organizations. According to guidance published by
the federal CIO Council,[Footnote 20]effective architecture management
consists of a number of practices, conditions, and structures. In April
2003, we published version 1.1 of our enterprise architecture
management maturity framework, which arranges the core elements of the
CIO Council's guidance into five hierarchical stages.[Footnote 21] The
framework provides an explicit benchmark for gauging the effectiveness
of architecture management and provides a roadmap for making
improvements. Table 2 summarizes the framework's five stages of
maturity.
Table 2: Summary of GAO's Enterprise Architecture (EA) Maturity
Framework Stages:
Stage: Stage 1: Creating EA awareness; Description: Organization does
not have plans to develop and use an architecture, or it has plans that
do not demonstrate an awareness of the value of having and using an
architecture. While stage 1 agencies may have initiated some EA
activity, these agencies' efforts are ad hoc and unstructured, lack
institutional leadership and direction, and do not provide the
management foundation necessary for successful EA development.
Stage: Stage 2: Building the EA management foundation; Description:
Organization recognizes that the EA is a corporate asset by vesting
accountability for it in an executive body that represents the entire
enterprise. At this stage, an organization assigns EA management roles
and responsibilities and establishes plans for developing EA products
and for measuring program progress and product quality; it also commits
the resources necessary for developing an architecture--people,
processes, and tools.
Stage: Stage 3: Developing the EA (includes all elements in stage 2);
Description: Organization focuses on developing architecture products
according to the selected framework, methodology, tool, and established
management plans. Roles and responsibilities assigned in the previous
stage are in place, and resources are being applied to develop actual
EA products. The scope of the architecture has been defined to
encompass the entire enterprise, whether organization-based or
function-based.
Stage: Stage 4: Completing the EA (includes all elements in stage 3);
Description: Organization has completed its EA products, meaning that
the products have been approved by the EA steering committee or an
investment review board, and by the CIO. Further, an independent agent
has assessed the quality (i.e., completeness and accuracy) of the EA
products. Additionally, evolution of the approved products is governed
by a written EA maintenance policy approved by the head of the
organization.
Stage: Stage 5: Leveraging the EA to manage change; (includes all
elements in stage 4); Description: Organization has secured senior
leadership approval of the EA products and a written institutional
policy stating that IT investments must comply with the architecture,
unless granted an explicit compliance waiver. Further, decision makers
are using the architecture to identify and address ongoing and proposed
IT investments that are conflicting, overlapping, not strategically
linked, or redundant. Also, the organization tracks and measures EA
benefits or return on investment, and adjustments are continuously made
to both the EA management process and the EA products.
Source: GAO.
[End of table]
The state of DOD's implementation of key enterprise architecture
management practices, conditions, and structures currently places it at
stage 1 of our maturity framework. Specifically, it has satisfied about
80 percent of the core elements associated with building the enterprise
architecture management foundation--stage 2 of our framework--but only
about 41 percent (9 of the 22) of the core elements associated with
stages 3, 4, and 5. According to our framework, effective architecture
management is generally not achieved until an enterprise has a
completed and approved architecture that is being effectively
maintained and is being used to leverage organizational change and
support investment decision making; having these characteristics is
equivalent to having satisfied all stage 3 core elements and many stage
4 and 5 elements.
With respect to stage 2 core elements, DOD has, for example,
established a program office, assigned a chief architect, and selected
a framework (C4ISR) and an automated tool (e.g., the System Architect
by Popkin Software). However, the department has not satisfied two of
the stage 2 core elements that are critical to effective enterprise
architecture management. For example, a committee or group representing
the enterprise has not yet been established to guide, direct, and
approve the architecture. Instead, the current version of its
architecture has been guided and directed by the Business Modernization
and Systems Integration (BMSI) program office. Although the Secretary
of Defense has established Financial Management Modernization Executive
and Steering Committees for the enterprise architecture, which are made
up of senior leaders from across the department, to provide program
guidance, these committees are not accountable for approving the
architecture. Instead, the responsibility of each committee is limited
to providing guidance to the BMSI program office and advising the DOD
Comptroller. However, DOD officials told us that the Executive
Committee has approved the architecture; yet there were no minutes of
the Executive Committee documenting this decision. Without an
accountable corporate entity to lead the architectural effort, there is
increased risk that the architecture will not represent a corporate
decision-making tool and will not be viewed and endorsed as a
departmentwide asset.
Further, DOD does not have a written and approved policy for
architecture development, which is a stage 3 core element. Without such
a policy that, for example, identifies the major players in the
development process and provides for architecture guidance, direction,
and approval, DOD has been, and will continue to be, challenged in
achieving departmentwide architecture commitment and support.
The department also has yet to implement numerous stage 4 and 5 core
elements. For example, DOD has not (1) documented and approved a policy
for architecture maintenance, (2) fully implemented an independent
verification and validation function that covers architecture products
and architecture management processes, and (3) made the architecture an
integral component of its IT investment management process.
According to program officials, the department set overly optimistic
expectations and time frames for its enterprise architecture program,
which resulted in the need to establish architecture management process
controls concurrent with developing architecture products. Until the
department implements the core elements of our enterprise architecture
management maturity framework, it is unlikely that it will be able to
either produce and maintain a well-defined architecture or effectively
implement what is produced.
Table 3 provides the results of our assessment of DOD's satisfaction of
each of the core elements of our maturity framework.
Table 3: Assessment of DOD's Enterprise Architecture Efforts Against
GAO's Enterprise Architecture Maturity Framework:
[See PDF for image]
Source: GAO analysis of DOD data.
[A] DOD defines the GIG as the 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, policy makers, and support
personnel.
[B] GAO-03-458.
[End of table]
Initial Version of Architecture Provides a Foundation Upon Which to
Build:
DOD has expended tremendous effort and resources and made important
progress in complying with the legislative requirements aimed at
developing and implementing a well-defined enterprise architecture.
Further, DOD's initial version of its BEA provides a foundation from
which to build and ultimately produce a well-defined business
enterprise architecture. However, the initial architecture does not
adequately address the act's requirements and other relevant
architectural requirements.[Footnote 22] Specifically, the initial
version of the architecture does not adequately describe the accounting
and financial management requirements, and the "As Is" and "To Be"
environments and the transition plan are not sufficiently complete to
provide a basis for guiding and constraining investment decisions.
Architecture Does Not Adequately Address Federal Requirements and
Accounting Standards:
DOD elicited and incorporated about 4,000 external requirements in its
"To Be" architecture from 152 federal sources. Our review of 1,767 of
the external requirements--specifically those that were elicited from
the Joint Financial Management Improvement Program (JFMIP)[Footnote
23]--identified 340 JFMIP requirements (about 19 percent) that were not
adequately addressed in version 1.0 of the "To Be" architecture.
Specifically, DOD (1) omitted some JFMIP requirements that are
significant, (2) included some that are invalid, and (3) included some
that are not appropriate to its business operations.
Mission requirements are one of the key bases for determining the scope
and content for enterprise architectures. One source of requirements is
the legal, regulatory, and other external constraints that define the
environment within which an enterprise, such as DOD, must operate. If a
given architecture is not developed to adequately recognize these
constraints, and these missing constraints are significant, the
architecture will not provide a sufficient frame of reference for
informed decision making. The act specifies that the architecture
should enable DOD to comply with all federal accounting, financial
management, and reporting requirements. JFMIP requirements arise from
various public laws, regulations, bulletins, circulars, federal
accounting standards, and leading practices and are applicable
government wide. Agencies must use these requirements, in addition to
agency-unique mission requirements, in planning and implementing their
financial management improvement projects.
DOD's "To Be" architecture omitted significant JFMIP requirements. For
example, DOD's architecture did not include any relevant revenue
requirements. These requirements are significant to DOD because they
affect the accounting of and reporting for DOD's revenue, which include
at least $70 billion earned annually by DOD working capital fund
activities. Department and contractor officials agreed that these
system requirements were either excluded or not adequately addressed
and stated that a subsequent version of the architecture would include
or modify the requirements. Table 4 summarizes the JFMIP requirements
that we reviewed and the numbers of missing or incomplete requirements
we identified.
Table 4: Summary of GAO Analysis of JFMIP Requirements:
JFMIP requirements: Revenue; Number of JFMIP: requirements: 220; Number
of missing or incomplete requirements: 220; Percent of missing or
incomplete requirements: 100.
JFMIP requirements: Acquisition; Number of JFMIP: requirements: 112;
Number of missing or incomplete requirements: 10; Percent of missing or
incomplete requirements: 9.
JFMIP requirements: Core Financial; Number of JFMIP: requirements: 430;
Number of missing or incomplete requirements: 4; Percent of missing or
incomplete requirements: 1.
JFMIP requirements: Human Resources and Payroll; Number of JFMIP:
requirements: 203; Number of missing or incomplete requirements: 37;
Percent of missing or incomplete requirements: 18.
JFMIP requirements: Managerial Cost Accounting; Number of JFMIP:
requirements: 67; Number of missing or incomplete requirements: 30;
Percent of missing or incomplete requirements: 45.
JFMIP requirements: Inventory; Number of JFMIP: requirements: 141;
Number of missing or incomplete requirements: 7; Percent of missing or
incomplete requirements: 5.
JFMIP requirements: Travel; Number of JFMIP: requirements: 166; Number
of missing or incomplete requirements: 12; Percent of missing or
incomplete requirements: 7.
JFMIP requirements: Property Management; Number of JFMIP: requirements:
78; Number of missing or incomplete requirements: 0; Percent of missing
or incomplete requirements: 0.
JFMIP requirements: Benefit; Number of JFMIP: requirements: 350; Number
of missing or incomplete requirements: 20; Percent of missing or
incomplete requirements: 6.
JFMIP requirements: Total; Number of JFMIP: requirements: 1,767; Number
of missing or incomplete requirements: 340; Percent of missing or
incomplete requirements: 19.
Source: GAO analysis of DOD data.
[End of table]
As another example, the "To Be" architecture did not include
requirements governing accounting for and reporting of national defense
plant, property, and equipment (PP&E)[Footnote 24] that became valid
shortly before the architecture was approved. These requirements
significantly affect the accounting of and reporting requirements for a
reported 600,000 aircraft, ships, combat vehicles, missiles and other
weapons systems, and related equipment. The architecture did not
incorporate requirements for these accounting standards[Footnote 25]
even though (1) the Federal Accounting Standards Advisory Board and the
three sponsoring agencies[Footnote 26] responsible for federal
accounting standards approved them in October 2002 and (2) DOD already
recognized these new PP&E requirements in its fiscal year 2002
Performance and Accountability Report and has begun to implement them.
According to DOD and contractor officials, they used outdated
requirements because the new standard was not in effect when they were
identifying and linking national defense PP&E requirements to
activities, processes, and entities depicted by the architecture. As a
result, DOD must now revise its architecture to reflect these
requirements, activities, and processes to ensure compliance with the
new accounting standard.
Lastly, the architecture includes options for doing business at the
federal level that were not appropriate to DOD's business operations
(i.e., do not reflect external requirements constraining DOD's
operations). For example, Statement of Federal Financial Accounting
Standards (SFFAS) No. 3, Accounting for Inventory and Related Property,
requires operating materials and supplies to be primarily accounted for
using the consumption method and allows the purchases method to be used
as an exception only under certain conditions.[Footnote 27] Because
DOD's operating supplies and materials are considered significant, DOD
reports the value of its almost $91 billion of operating materials and
supplies using the consumption method of accounting. Developing the
architecture to allow DOD to use the purchases method to account for
its inventory and related property may result in inappropriate use of
this method and, therefore, inconsistent practices and supporting
system solutions among DOD components.
According to DOD and contractor officials, both the omission and
limited definition of relevant federal requirements is partly due to
not having a fully functioning quality assurance process to verify and
validate the requirements when the requirements were elicited. In March
2003, following our previous recommendation to strengthen quality
assurance activities, DOD increased its quality assurance activities.
These officials stated that, as part of their current quality assurance
process, they are identifying additional requirements and deleting
existing requirements that are duplicative or deemed not mandatory. As
a result, version 1.0 of the BEA does not adequately reflect and
recognize critical external requirements, and thus is not yet
sufficiently complete for making informed decisions about system
investments.
Initial Version of DOD Architecture Is Not Sufficiently Complete to
Satisfy Act and Guide and Constrain Modernization Investments:
As previously discussed, the various frameworks used to develop an
enterprise architecture consistently (1) describe the architectures for
both the enterprise's "As Is" and "To Be" environments in logical
(e.g., business, performance, application, information) as well as
technical (e.g., hardware, software, data) terms, and (2) define a
capital investment sequencing plan to transition from the "As Is" to
the "To Be" environment. However, the frameworks do not prescribe the
degree to which the component parts should be described to be
considered correct, complete, understandable, and usable--essential
attributes of any architecture. This is because the depth and detail of
the descriptive content depend on the architecture's intended purpose.
In the case of DOD, the act specifies that its enterprise architecture
should enable the department to (1) comply with all federal accounting,
financial management, and reporting requirements, (2) routinely produce
timely, accurate, and reliable financial information for management
purposes, (3) integrate budget, accounting, and program information and
systems, and (4) provide for the systematic measurement of performance.
Moreover, DOD's stated intention is to use the architecture as the
basis for departmentwide business transformation and systems
modernization.
Collectively, these purposes necessitate that the architecture provide
considerable depth and detail, as well as logical and rational
structuring and internal linkages. More specifically, they mean that
the architecture should contain sufficient scope and detail to permit,
for example, (1) elimination of duplicative business operations and
systems, (2) standardization and integration of business operations and
interoperability of supporting systems, (3) maximum use of
enterprisewide services, and (4) alignment with related shared
solutions, like OMB's e-gov initiatives. Moreover, this scope and
detail[Footnote 28] should be accomplished in a way that (1) provides
flexibility in adapting to changes in the enterprise's internal and
external environments, (2) facilitates its usefulness and comprehension
by varying perspectives/users/stakeholders, and (3) provides for
properly sequencing investments to recognize, for example, the
investments' respective dependencies and relative business value.
Version 1.0 of DOD's enterprise architecture does not contain
sufficient scope and detail to either satisfy the act's requirements or
effectively guide and constrain departmentwide business transformation
and systems modernization. This is based on our decomposition of
version 1.0 into various parts and components and comparison of it
against relevant benchmarks. More specifically, we first divided the
architecture into the three primary component parts specified in the
act and recognized in best practices and federal guidance: the "As Is"
architecture, the "To Be" architecture, and the transition plan. We
then divided the "As Is" and the "To Be" architectures into five
architectural components similar to those in OMB's architecture
reference models: the business, information/data, services/
applications, technical, and performance components; we added security
as a sixth component because of its recognized importance and relevance
to the other five. We then compared version 1.0 to relevant:
criteria[Footnote 29] governing the content of key architectural
elements for the transition plan and these six components of the "As
Is" and "To Be" architectures. Based on this comparison, we determined
whether version 1.0 of the architecture generally satisfied, did not
satisfy,[Footnote 30] or partially satisfied[Footnote 31] each
architectural element.
Overall, DOD's "As Is" architecture did not satisfy 26 of 29 key
elements, and partially satisfied the remaining 3; its "To Be"
architecture did not satisfy 4 of 30 key elements, and partially
satisfied the remaining 26; and its transition plan partially satisfied
2 of the 3 elements, but did not satisfy the remaining 1 (see fig. 2).
This means that version 1.0 of DOD's enterprise architecture does not
satisfy the requirements of the act and is not sufficiently complete to
provide an adequate basis for guiding and constraining investments in
modernized systems. Program officials agreed that this version of the
architecture is not complete, but stated that it fully satisfies the
act, because it addresses, to at least some degree, each of the act's
requirements. They added that they have accomplished as much in
completing the architecture as was possible in the time available, and
that the department was overly optimistic in estimating what it could
produce by May 1, 2003. We agree that DOD set unrealistic expectations
of the scope and level of architectural definition it could provide by
this time, but do not agree, as discussed in detail in the previous
section and the sections that follow, that it satisfies the act's
requirements. We also believe that the state of DOD's architecture is
also due to weaknesses in its architecture development management
controls that are discussed in the previous section, and that our prior
recommendations were aimed at correcting.
Figure 2: Summary of Extent to Which Version 1.0 of DOD's Enterprise
Architecture Satisfies Key Elements Governing Architectural Content:
[See PDF for image]
[End of figure]
In addition, the structure of the "To Be" architecture contains
internal linkage, consistency, and navigation limitations that
constrain its ease of use and understandability. For example, explicit
linkages among (1) services/applications, (2) organizations using the
services/applications, and (3) technical standards governing the
services/applications were missing, as were linkages between certain
business and information/data artifacts. This is important because
dependencies exist among these architectural components and a well-
defined architecture makes such dependencies explicit to ensure that
systems are implemented in a nonduplicative and integrated fashion. We
also found instances of internal inconsistencies. For example, one
artifact (a table) indicated that DOD had not selected any standards
for certain security services, while another artifact identified
selected standards for these services. In another instance, four
artifacts listed identified requirement sources for security, such as
the Computer Security Act of 1987[Footnote 32] and OMB Circular A-130;
however, the artifacts' respective lists varied and no single list
included all the requirement sources. In another instance, some terms
contained within the architecture (e.g., availability, integrity
checks, confidentiality, and authentication) were not consistently
defined, and the architecture did not explain the basis for these
inconsistencies. For example, one artifact defined authentication as
the "standard practices followed to authenticate the identity of system
users," while another artifact defined it as a "security measure
designed to establish the validity of a transmission, message, or
originator, or a means of verifying an individual's authorization to
receive specific categories of information.":
Such inconsistencies in the architecture can in turn lead to
misinterpretations, and thus incompatibilities, in how systems are
implemented. Additionally, the architecture did not include user
instructions or guidance, making it difficult to navigate and use. For
example, (1) certain artifacts (e.g., diagrams) could not be read on-
line because there was no "zoom" capability enabling enlargement, and
(2) specific content, such as the applicability of security standards
to specific security services, took three persons several days to
locate. The complete results of our analysis of each of version 1.0's
parts and related components are discussed in detail below.
"As Is" Architecture: This architecture is intended to capture the
current state of enterprise operations in sufficient scope and detail
to permit meaningful analysis of gaps between such things as current
and future processes, data, standards, and systems. It thus should
describe, for those areas of the enterprise that are likely to change,
the current set of business processes and performance measures that are
in place and operating and, among other things, the information/data,
services/applications, and technology that are in place to support
these processes and measures. According to relevant guidance,[Footnote
33] the "As Is" architecture should contain, for example, a description
of (1) the actual business operations currently being performed to
support the organization's mission, including the entities/people that
perform the functions, processes, and activities, and the locations
where the functions, processes, and activities are being performed, (2)
the information/data used by the functions, processes, and activities,
(3) the systems that support the functions, processes, and activities,
including system interfaces, (4) the types of technology (e.g.,
hardware and software) and associated technical standards that comprise
the physical systems environment, (5) the security standards and tools
used to secure and protect systems and data, and (6) the metrics for
evaluating the effectiveness of mission operations and supporting
system performance in achieving mission goals and objectives. Without
this information, an enterprise would be extremely challenged in
identifying the proper sequence of changes needed to move from its
current operating environment to its future, target environment. As
stated by one leading industry authority on enterprise
architecture,[Footnote 34] an organization will be unable to
effectively plan and manage its modernization efforts, and will waste
IT dollars, if it does not have a clear picture of its "As Is"
environment.
Version 1.0 of DOD's "As Is" architecture provides little of this
descriptive content. On the positive side, it includes an inventory of
about 2,300 existing systems that support DOD's current business
operations, including certain characteristics about each (e.g., system
owner, purpose and business process it supports, and vendor). However,
the majority of systems do not have descriptions of system interfaces,
and the inventory has not been validated and continues to change
significantly. For example, DOD's current "As Is" systems inventory of
about 2,300 systems has increased approximately 35 percent when
compared to its "As Is" inventory of about 1,700 business systems in
October 2002. In addition, DOD's architecture does not describe (1) the
current business operations in terms of the entities/people who perform
the functions, processes, and activities, and the locations where the
functions, processes, and activities are performed, (2) the data/
information being used by the functions, processes, and activities, (3)
the types of technology and associated technical standards being
employed, (4) the security standards and tools being used, and (5) the
performance metrics being used. Instead, it merely provides a listing
of the names of the current business processes. As a result, DOD does
not have a sufficiently described picture of its current environment to
permit development of a meaningful and useful transition plan. See
table 5 for the detailed results of our analysis of DOD's "As Is"
architecture.
Table 5: Detailed Analysis of the Extent to Which DOD's "As Is"
Architecture Satisfies Key Elements:
Key architectural element: Business:
Key architectural element: A description of the strategic goals, which
defines what an organization wants to achieve; Element satisfied?: No.
Key architectural element: A business strategy, which defines how the
strategic goals and objectives will be achieved; Element satisfied?:
No.
Key architectural element: An inventory of key policies, procedures,
and standards governing how business operations are executed and
managed; Element satisfied?: No.
Key architectural element: A description of key business processes and
how they support the agency's mission, including the organizational
units responsible for performing the business processes and the
locations where the business processes are being performed; Element
satisfied?: Partially; Explanation of partially satisfied: The
architecture contains (1) a list of the names of the business processes
and (2) a high-level (1-page) graphical depiction of these processes.
It does not contain detailed descriptions of existing business
operations that include, for example, information flows among
activities, organizational units and locations that perform the
business processes, and the technological characteristics of the
systems that perform these processes.
Key architectural element: An analysis of deficiencies in the "As Is"
business environment that are to be addressed, as well as obstacles to
addressing these deficiencies, plans for addressing them, and a
business case for addressing them. An example is an analysis of the
quality of existing data to determine their completeness and accuracy;
Element satisfied?: Partially; Explanation of partially satisfied:
The architecture contains an analysis of process area deficiencies.
However, this analysis does not include the business case(s) for
addressing the deficiencies.
Key architectural element: A description of organizational
accountability for execution of current business policies, procedures,
and standards; Element satisfied?: No.
Key architectural element: Information/Data:
Key architectural element: A description of the data management
policies, processes, procedures, and tools (e.g., CRUD Matrix[A] ) for
analyzing, designing, building, and maintaining existing databases;
Element satisfied?: No.
Key architectural element: A description of the business and
operational rules[B] for data standardization to ensure data
consistency, integrity, and accuracy, such as business and security
rules that govern access, maintenance, and use of data; Element
satisfied?: No.
Key architectural element: A data dictionary, which is a repository of
standard data definitions for applications; Element satisfied?: No.
Key architectural element: A conceptual data model that describes the
fundamental things/objects (e.g., invoices, financial statements,
inventory) that make up the business and how they are used, but without
regard for how they will be physically stored. It represents the
consolidated structure of business objects to be used by business
applications; Element satisfied?: No.
Key architectural element: A logical database model that provides the
data structures that support information flows, and that provides the
basis for developing the schemas for designing, building, and
maintaining the existing physical databases; Element satisfied?: Yes:
[Empty]; Element satisfied?: No.
Key architectural element: A metadata[C] model that specifies the rules
and standards for access to information; Element satisfied?: Yes:
[Empty]; Element satisfied?: No.
Key architectural element: A description of information flows and
relationships between organizational units, business operations, and
applications; Element satisfied?: No.
Key architectural element: Services/Applications:
Key architectural element: A stable listing of business application
systems and system components and their interfaces; Element
satisfied?: Partially; Explanation of partially satisfied: There is
a list of systems, but the respective interfaces have not been
described. Further, this list continues to change.
Key architectural element: A description of the common technical
approach, policies, and procedures for developing/acquiring business
application systems throughout their life cycle, including requirements
management, design, implementation, testing, deployment, operations,
and maintenance. The common technical approach should also describe the
process for integrating legacy systems with the systems to be
developed/acquired; Element satisfied?: No.
Key architectural element: Technical.
Key architectural element: Descriptions of the enterprise
infrastructure services[D] to include specific details regarding the
functionality and capabilities that these services provide to enable
systems applications; Element satisfied?: No.
Key architectural element: Identification of the technical standards[E]
implemented for each enterprise service; Element satisfied?: Yes:
[Empty]; Element satisfied?: No.
Key architectural element: A description of the physical IT
infrastructure needed to support the current and any newly developed
and/or acquired systems outside the scope of the architecture,
including the relationships among hardware, software, and
communications devices; Element satisfied?: No.
Key architectural element: Common policies and procedures for
developing/acquiring infrastructure systems throughout their life
cycle, including requirements management, design, implementation,
testing, deployment, operations, and maintenance; Element satisfied?:
No.
Key architectural element: Security:
Key architectural element: A description of the policies, procedures,
goals, strategies, and requirements relevant to information assurance
and security; Element satisfied?: No.
Key architectural element: A listing of security and information
assurance related terms; Element satisfied?: No.
Key architectural element: A listing of accountable organizations and
their respective responsibilities for implementing enterprise security
services; Element satisfied?: No.
Key architectural element: A description of operational security rules
that are derived from security policies; Element satisfied?: No.
Key architectural element: A description of enterprise security
infrastructure services (e.g., identification and authentication)
needed to protect the department's assets, and the means for
implementing such a service (e.g., firewalls and intrusion detection
software); Element satisfied?: No.
Key architectural element: A description of the security standards[F]
implemented for each enterprise service to secure assets. These
standards should be derived from security requirements; Element
satisfied?: No.
Key architectural element: A description of the protection mechanisms
implemented to secure the department's assets, such as firewalls and
intrusion detection software, including a description of the
relationships among these protection mechanisms; Element satisfied?:
No.
Key architectural element: Performance.
Key architectural element: A description of the performance management
process, including how the organization measures, tracks, evaluates,
and predicts business performance with respect to business functions,
baseline data, and service levels; Element satisfied?: No.
Key architectural element: A description of customer-focused,
measurable goals and outcomes for business products and services;
Element satisfied?: No.
Key architectural element: A description of measurable goals and
outcomes for managing technology to enable the achievement of business
goals and outcomes; Element satisfied?: No.
Source: GAO analysis of DOD data.
[A] A CRUD (create, read, update, and/or delete) matrix shows the
specific business functions and applications that create, read, update,
and/or delete specific data elements, which enables the organization to
develop applications.
[B] Business and operational rules define specific constraints for the
data, such as security needs (e.g., confidentiality and access of
data), and actions that should or should not occur such as updating or
deleting data.
[C] Metadata are "data about data" that enable automation and
consistent management and use of information, such as rules and
standards.
[D] Examples of enterprise services include application services, such
as web services, and collaboration services, such as instant messaging
or voice conferencing.
[E] Technical standards are strict rules and protocols governing how a
given enterprise service is to be implemented.
[F] Security standards cover such services as identification and
authentication, audit trail creation, access controls, virus
prevention, and intrusion prevention and detection.
[End of table]
"To Be" Architecture: This architecture is intended to capture the
vision of future business operations and supporting technology. It
should describe the desired capabilities and structures at a specified
point(s) in the future. The "To Be" architecture should show, for
example, future business processes, information needs, and supporting
infrastructure, and it should be fiscally and technologically
achievable. According to relevant guidance,[Footnote 35] the "To Be"
architecture should contain, among other things, a description of (1)
the future business operations that will be performed to support the
organization's mission, including the entities/people that will perform
the functions, processes, and activities, and the locations where the
functions, processes, and activities will be performed, (2) the logical
database model that is to be used to guide the creation of the physical
databases where information will be stored, (3) the systems to be
developed or acquired to support the business operations, (4) the
physical infrastructure (e.g., hardware and software) that will be
needed to support the business systems, (5) the organizations that will
be accountable for implementing security and the tools to be used to
secure and protect systems and data, and (6) the metrics that will be
used to evaluate the effectiveness of mission operations and supporting
system performance in achieving mission goals and objectives. By
including these, the architecture would allow DOD to satisfy the act's
requirements, such as routinely providing timely, accurate, and
reliable information for management decision making.
Version 1.0 of DOD's "To Be" architecture provides some of this
descriptive content, but not to the extent needed to meet the act's
requirements and permit effective acquisition and implementation of
system solutions and associated operational change. On the positive
side, it contains a description of the future business operations and a
logical database model. However, the future business operations are not
described in terms of the entities/people who will perform the
functions, processes, and activities, and the locations where the
functions, processes, and activities will be performed. Further, we
found no linkage between the logical database model and the conceptual
data model, which raises concerns regarding the utility of this model
in supporting information flows for business operations and systems. In
addition, it does not describe (1) the actual systems to be developed
or acquired to support future business operations, (2) the physical
infrastructure (e.g., hardware and software) that will be needed to
support the business systems, (3) the organizations that will be
accountable for implementing security and the tools to be used to
secure and protect systems and data, and (4) the metrics that will be
used to evaluate the effectiveness of mission operations and supporting
system performance in achieving mission goals and objectives. Without
this information, the organization will not have a common vision and
frame of reference for defining a transition plan to guide and
constrain capital investment, and thus will be unable to effectively
leverage technology to orchestrate logical and systematic change and
optimize enterprisewide mission performance. See table 6 for the
results of our analysis of DOD's "To Be" architecture.
Table 6: Detailed Analysis of the Extent to Which DOD's "To Be"
Architecture Satisfies Key Elements:
Key architectural element: Business:
Key architectural element: A description of the strategic goals, which
define what an organization wants to achieve; Element satisfied?:
Partially; Explanation of partially satisfied: The architecture
contains a description of the strategic goals, but does not address
how it will support the department's warfighter goals.
Key architectural element: A business strategy, which defines how the
strategic goals and objectives will be achieved; Element satisfied?:
Partially; Explanation of partially satisfied: The architecture lists
business strategies, such as utilizing more commercial practices to
promote private sector partnerships, but does not describe how these
strategies will be implemented.
Key architectural element: Common policies, procedures, and business
rules for consistent implementation of architecture; Element
satisfied?: Partially; Explanation of partially satisfied: The
architecture does not have common policies and procedures, nor has it
defined a plan for achieving this. It does, however, recognize the
need for such policies, procedures, and business rules, and provides a
general time frame for when they will be developed; The architecture
includes high-level descriptions of business rules, but does not
formally define how these rules will be automated and implemented.
Key architectural element: A description of key business processes and
how they support the agency's mission, including the organizational
units responsible for performing the business processes and the
locations where the business processes are performed; Element
satisfied?: Partially; Explanation of partially satisfied: The
architecture has a high-level description of processes, without a
specific identification of organizations and locations.
Key architectural element: A description of the architecture
governance structure and processes to ensure that the department's
business transformation effort remains compliant with the
architecture; Element satisfied?: Partially; Explanation of partially
satisfied: The architecture has a draft concept for governance, but
does not describe,
for example, the process for ensuring compliance with the architecture
and the processes for managing risks and approving the architecture and
systems investments.
Key architectural element: A listing of opportunities to unify and/or
simplify systems and processes across the agency; Element satisfied?:
Partially; Explanation of partially satisfied: The architecture
contains a list of deficiencies for the operational activities, but
not
for systems. For example, it does not identify the specific pilot
projects that will be conducted, nor does it identify the resources
(funding and staffing) needed for conducting these pilots.
Key architectural element: A description of the organizational
approach for communications and interactions among business lines and
program areas for management reporting, operational functions, and
architecture development and use; Element satisfied?: Partially;
Explanation
of partially satisfied: The architecture has a notional organizational
structure for communications and interactions among departmental
entities for reporting and management purposes.
Key architectural element: Information/Data.
Key architectural element: Description of data management policies,
processes, procedures, and tools (e.g., CRUD Matrix) for analyzing,
designing, building, and maintaining databases in an enterprise
architected environment; Element satisfied?: Partially; Explanation of
partially satisfied: The architecture contains a high-level data
management strategy, including guidelines, and an approach for managing
the data in an EA environment. However, it does not identify the
policies, processes, procedures, and tools to be used.
Key architectural element: A description of the business and
operational rules for data standardization to ensure data consistency,
integrity, and accuracy, such as business and security rules that
govern access, maintenance, and use of data; Element satisfied?:
Partially; Explanation of partially satisfied: The architecture
contains descriptions of data standards upon which business rules can
later be developed. The architecture contains rules for security, but
lacks the details needed to consistently enforce these rules (e.g., the
rules do not always identify the event, entity name, and the action to
occur). In addition, the architecture does not provide any evidence as
to whether these business rules have been verified and validated for
completeness.
Key architectural element: A data dictionary, which is a repository of
standard data definitions for applications; Element satisfied?:
Partially; Explanation of partially satisfied: The architecture
contains a data dictionary comprised of a list of terms and their
respective definitions. However, the architecture does not have a
complete list of terms nor does it contain a list of the data
elements[A] needed to support systems and database design.
Key architectural element: A conceptual data model that describes the
fundamental things/objects (e.g., invoices, financial statements,
inventory) that make up the business and how they are used, but
without regard for how they will be physically stored. It represents
the consolidated structure of business objects to be used by business
applications; Element satisfied?: Partially; Explanation of partially
satisfied: The architecture contains a high-level conceptual data model
that does not specify how the business objects are used by applications
(i.e., does not show how the information is used by the enterprise).
Further, this model does not show a consolidated view of the data
(business objects) to be used by applications.
Key architectural element: A logical database model that provides the
data structures that support information flows, and that provides the
basis for developing the schemas for designing, building, and
maintaining the physical databases; Element satisfied?: Partially;
Explanation of partially satisfied: The architecture contains data
structures, which describe, for example, data entities, attributes,
and relationships among data. However, the model has not been verified
or validated for completeness with respect to business relevance (i.e.,
business scenarios do not show evidence of this validation), nor are
there criteria for defining the number of business scenarios that have
to be completed. In addition, it does not show the relationship among
the data structures in this data model nor the data structure
underlying the data/information flows for business operations and
systems. Further, the architecture does not contain a unified
enterprise data model that reconciles the independent data models that
have been developed for each business process area.
Key architectural element: A metadata model that specifies the rules
and standards for access to information; Element satisfied?:
Partially; Explanation of partially satisfied: The architecture notes
that an approach, strategy, and plan for creating and managing
metadata have not yet been developed. However, it notes that these
documents will be created at a later time.
Key architectural element: A description of information flows and
relationships between organizational units, business operations, and
system elements; Element satisfied?: Partially; Explanation of
partially
satisfied: The architecture contains notional system-to-system
relationships, including how the system may support business
activities, which can be used to extend development of the
architecture, but the architecture does not link organizational units
to business operations and system elements (e.g., hardware and
software).
Key architectural element: Services/Applications.
Key architectural element: A description of the business application
systems and system components and their interfaces; Element
satisfied?: Partially; Explanation of partially satisfied: The
architecture has grouped business functions into system entities[B] and
identified the communication paths between these entities; however,
these entities are notional.
Key architectural element: A description of the common technical
approach, policies, and procedures for developing/acquiring business
application systems throughout their life cycle, including requirements
management, design, implementation, testing, deployment, operations,
and maintenance. The common technical approach should also describe the
process for integrating legacy systems with the systems to be
developed/acquired; Element satisfied?: Partially; Explanation
of partially satisfied: The architecture does not have a common
technical approach and policies and procedures, nor has it defined a
plan for achieving this. It does, however, recognize the need for
having an approach and policies and procedures, and provides a general
time frame for when they will be developed.
Key architectural element: Technical.
Key architectural element: Descriptions of the enterprise
infrastructure services to include specific details regarding the
functionality and capabilities these services will provide to enable
systems applications; Element satisfied?: Partially; Explanation
of partially satisfied: The architecture contains high-level
definitions for the enterprise services. However, the specific
enterprise services for this architecture are to be developed within
the context of the GIG's enterprise services, and, according to DOD,
the GIG is not complete and is still evolving.
Key architectural element: Identification of the technical standards to
be implemented for each enterprise service; Element satisfied?:
Partially; Explanation of partially satisfied: DOD has identified
enterprise infrastructure services for system entities. However,
standards profiles that support the services, and commonly apply to all
system entities, are not clearly identified and described. DOD has not
yet defined standards profiles to be employed in the conduct of
business processes.
Key architectural element: A description of the physical IT
infrastructure needed to support the developed and/or acquired
systems, including the relationships among hardware, software, and
communications devices; Element satisfied?: No.
Key architectural element: Common policies and procedures for
developing/acquiring infrastructure systems throughout their life
cycle including requirements management, design, implementation,
testing, deployment, operations, and maintenance. These policies and
procedures should also address the integration of applications,
including legacy systems; Element satisfied?: Partially; Explanation
of partially satisfied: The architecture does not have common policies
and procedures, nor has it defined a plan for achieving this. It does,
however, recognize the need for having these policies and procedures,
and provides a general time frame for when they will be developed.
Key architectural element: Security.
Key architectural element: A description of the policies, procedures,
goals, strategies, and requirements relevant to information assurance
and security; Element satisfied?: Partially; Explanation of partially
satisfied: The architecture refers to policies, but application of the
policies is inconsistent within the architecture. It does not contain
procedures; but recognizes the need for them and provides a general
time frame for when they will be developed. The architecture contains
hypothetical security goals for such attributes as risk and impact
assessments. It also contains a high-level strategy that explains where
information assurance should be addressed in the architecture and the
target capabilities needed for information assurance (e.g., threat/
vulnerability assessments). In addition, the architecture lists
relevant security requirements; However, the goals, strategies, and
requirements have not been mapped to specific physical security systems
solutions. It is also unclear how information assurance activities will
support the department's warfighter goals.
Key architectural element: A listing of security and information
assurance related terms; Element satisfied?: Partially; Explanation of
partially satisfied: The data dictionary does list some security-
related terms (e.g., availability, integrity, and authentication);
however, the definitions for these terms are inconsistent with the
definitions contained in the existing policy; In addition, some of
the terms that are not listed (e.g., need-to-know and nonrepudiation)
are critical to implementing effective information assurance controls.
Key architectural element: A listing of accountable organizations and
their respective responsibilities for implementing enterprise security
services; Element satisfied?: No.
Key architectural element: A description of operational security rules
that are derived from security policies; Element satisfied?: No.
Key architectural element: A description of enterprise security
infrastructure services (e.g., identification and authentication) that
will be needed to protect the department's assets, and the means for
implementing such services (e.g., firewalls and intrusion detection
software); Element satisfied?: Partially; Explanation of partially
satisfied: The architecture contains generic descriptions of enterprise
security services, but does not specify the means for implementation.
Key architectural element: A description of the security standards to
be implemented for each enterprise service to secure assets. These
standards should be derived from security requirements; Element
satisfied?: Partially; Explanation of partially satisfied: The
architecture describes the enterprise services and associated standards
that apply to individual system entities. However, it does not link
requirements to standards and vice versa.
Key architectural element: A description of the protection mechanisms
that will be implemented to secure the department's assets, such as
firewalls and intrusion detection software, including a description of
the relationships among these protection mechanisms; Element
satisfied?: No.
Key architectural element: Performance.
Key architectural element: A description of the performance management
process, including how the organization will measure, track, evaluate,
and predict business performance with respect to business functions,
baseline data, and service levels; Element satisfied?: Partially;
Explanation of partially satisfied: The architecture contains a high-
level proposal to develop this process; however, buy-in has not been
achieved. Until buy-in is obtained, the development of such a process
will not be an architectural requirement.
Key architectural element: A description of customer-focused measurable
goals and outcomes for business products and services; Element
satisfied?: Partially; Explanation of partially satisfied: The
architecture contains performance metrics for operational activities
and notional systems; however, these metrics are not linked to
measurable goals associated with business products and services.
Key architectural element: A description of measurable goals and
outcomes for managing technology to enable the achievement of business
goals and outcomes; Element satisfied?: Partially; Explanation of
partially satisfied: The architecture contains plans to establish
baseline measures that can be used to establish technical performance
measures, but it does not yet recognize the need to tie these measures
to the business goals/outcomes.
Source: GAO analysis of DOD data.
[A] Data elements are basic units of information that cannot be further
subdivided. For example, you may create a data structure called
'Address,' which contains the data elements 'Street Address, City,
State, and Zip Code.':
[B] System entities are logical groups of system functions (e.g.,
general ledger, payroll) representing "To Be" capabilities and
requirements.
[End of table]
Transition Plan: According to relevant guidance and best
practices,[Footnote 36] the transition plan should provide a temporal
roadmap for moving from the "As Is" to the "To Be" environment. An
important step in the development of a well-defined transition plan is
a gap analysis that compares the "As Is" and "To Be" architectures to
identify differences. Other important steps include analyses of
technology opportunities and market place trends as well as assessments
of fiscal and budgetary realities and institutional acquisition and
development capabilities. Using such analyses and assessments, options
are explored and decisions are made regarding which legacy systems to
retain, modify, or retire, and which new systems to introduce on either
a tactical (temporary) basis or to pursue as strategic solutions.
Accordingly, transition plans identify legacy, migration, and new
systems, and sequence them to show, for example, the phasing out and
termination of systems and capabilities, and the timing of the
introduction of new systems and capabilities. Furthermore, they do so
in light of resource constraints, such as budget, people, acquisition/
development process maturity, and associated time frames. Recognizing
the importance of a well-defined transition plan, the act[Footnote 37]
also required DOD to identify (1) all mission-critical or mission-
essential operational and developmental financial and nonfinancial
systems, (2) the actual costs to operate and maintain these systems
during fiscal year 2002, and (3) the estimated costs for fiscal year
2003.
DOD's transition plan generally does not possess these attributes, and
is basically a plan to develop a transition plan. Specifically, it does
not (1) provide a gap analysis identifying the needed changes to
current business processes and systems, (2) identify all of the systems
that will not become part of the "To Be" architecture as well as the
time frames for phasing out these systems, (3) show a time-based
strategy for replacing legacy systems, including identification of
intermediate (i.e., migration) systems that may be temporarily needed,
and (4) define the resources (e.g., funding and staff) needed to
transition to the target environment. Further, while the transition
plan contained system cost information for fiscal years 2002 and 2003,
it did not associate this information, as specified in the act, with
mission-critical or mission-essential operational and developmental
financial and nonfinancial systems.
DOD attributed the state of its transition plan to attempting to
develop this plan concurrently with developing its "As Is" and "To Be"
architectures, which it found was not feasible. As a result, DOD does
not yet have a meaningful and reliable basis for managing the
disposition of its existing inventory of about 2,300 systems or for
sequencing the introduction of modernized business operations and
supporting systems. See table 7 for the detailed results of our
analysis of DOD's transition plan.
Table 7: Detailed Analysis of the Extent to Which DOD's Transition Plan
Satisfies Key Architectural Elements:
[See PDF for image]
Source: GAO analysis of DOD data.
[A] An acquisition/business strategy is a plan of action for achieving
a specific goal or result through contracting for software products and
services.
[End of table]
Contractor Review of Version 1.0 of the Architecture Also Identified
Weaknesses:
DOD's verification and validation contractor assessed Version 1.0 of
its architecture against relevant best practices to determine its
quality. In June 2003,[Footnote 38] consistent with our assessment,
this contractor reported that while DOD's architecture contained
significant content, it lacked the depth and detail needed to begin
building and implementing modernized systems and making operational
changes. Further, the contractor reported that the architecture was not
easily understandable and that its utility to stakeholders in system
acquisition planning was limited. According to the contractor, these
conclusions were based on the following findings.
* Linkages among architecture products had not been defined, making it
difficult to navigate through the architecture.
* Architecture products did not adequately describe the "As Is"
environment, including business processes and existing business
application systems and supporting technology, which would make it
difficult for DOD to perform a gap analysis to support development of a
transition plan.
* Architecture products did not adequately describe the "To Be"
environment, including (1) business rules governing how data are to be
accessed and used within the automated environment, (2) migration and
target systems and applications, (3) enterprise infrastructure services
and the technical standards relevant to each service, (4) security
needs, including standards and protection mechanisms (e.g., firewalls),
and (5) performance metrics.
* The transition plan was merely a plan to develop a transition plan.
As a result, the contractor recommended, among other things, that the
department discontinue further development of the "To Be" architecture
until it addressed identified deficiencies. Program officials stated
that they will address these comments in subsequent versions of the
architecture. However, they could not provide us with any written plans
governing the scope of comments to be addressed, and how they will be
addressed and validated.
DOD Has Yet to Establish an Effective Investment Management Process for
Selecting and Controlling Business System Investments:
Using the architecture as an integral investment management frame of
reference is essential to effectively selecting and controlling
business system investments and to moving the organization toward the
target architecture. Such use of an architecture is provided for in
legislation, federal guidance, and best practices. In addition,
subsection 1004(d) of the act stipulates that any amount in excess of
$1 million may be obligated for system improvements only if the DOD
Comptroller makes a determination that the improvement is necessary for
(1) critical national security capability or critical safety and
security requirements or (2) prevention of significant adverse effect
on a project that is needed to achieve an essential capability. The act
further states that once the architecture is approved, the DOD
Comptroller must determine that expenditures for system improvements
are consistent with the enterprise architecture and the transition
plan. These legislative requirements are consistent with our open
recommendations to DOD for selecting and controlling business systems
investments. Specifically, we recommended that DOD gain control over
business system investments by establishing a hierarchy of investment
review boards from across the department, establishing a standard set
of criteria to ensure alignment and consistency with the architecture,
and directing the boards to perform a comprehensive review of all
ongoing business system investments. (App. III contains details on the
status of DOD's efforts to address our open recommendations.):
To comply with the legislative requirement and address our
recommendations, the DOD Comptroller issued a memorandum on March 7,
2003, to DOD's component organizations stating that the BMSI office--
which is responsible for overseeing the development and implementation
of the architecture--must review all system initiatives with
expenditures in excess of $1 million. In addition, the memorandum
directs the DOD components, as an integral part of the review and
approval process, to present information to DOD Comptroller officials
and relevant domain owners that demonstrates that each investment (1)
complies with the architecture, and (2) is economically justified.
DOD has not yet defined and implemented an effective investment
management process to proactively identify and control system
investments exceeding $1 million while the architecture is being
developed and after it is completed. Based on DOD data, as of June 6,
2003, the DOD Comptroller had approved one system initiative with
expenditures exceeding $1 million since enactment of the act, and was
reviewing four others. The one system approval for $10 million was an
enhancement to the Mechanization of Contract Administrative Services
(MOCAS) system--which is DOD's primary contractor pay system and is
used to maintain data on the majority of DOD's weapons systems as well
as service contracts administered by the Defense Contract Management
Agency. According to DOD, the enhancements to MOCAS are essential
because the system intended to replace MOCAS--Defense Procurement
Payment System--was terminated in December 2002 by the DOD Comptroller
after 7 years of effort and an investment of $126 million because of
poor program performance and increasing costs. In approving the
enhancements to MOCAS, the DOD Comptroller determined that it was
needed to assure continued system operations and that the failure of
MOCAS would jeopardize DOD's ability to pay contractors on time, which
is one of the criteria in the act.
BMSI officials stated that the department's current process for
selecting and controlling business system investments depends on the
system owners coming forward with the request for approval, and that it
has not established the means to determine which systems should be
submitted for review. In response to our prior open recommendations,
the DOD Comptroller states that the department is currently
establishing a governance structure that includes an investment review
board and making the domain owners an integral part of the review and
approval process for selecting and controlling business system
investments. According to DOD officials, the board is to utilize a
portfolio management approach based on established approval thresholds
to address investment decisions across the department. Further, DOD
officials state that the department is developing standard criteria to
be used by the investment boards to assess business system investments,
including consistency with the architecture. However, this proposed
governance concept has not yet been adopted. We discuss this process in
more detail later in this report.
Our analysis of DOD's fiscal years 2003 and 2004 IT budget requests
shows that over 200 systems in each year's budget, totaling about $4
billion per year, could involve obligations of funds that meet the $1
million threshold. This indicates that the majority of the billions of
dollars that DOD invests in business system improvements annually have
not been subjected to the scrutiny of the DOD Comptroller as now called
for in the act. The act places limitations on the legal authority of
individual program and government contracting officials to obligate
funds in support of the systems for which they are responsible, but DOD
has yet to proactively manage investments to avoid violations of the
limitations and to review investments in any meaningful way to enforce
these statutory limitations. Program officials acknowledge that the
department, at a minimum, could use DOD's IT budget documentation to
proactively fulfill the act's requirements. Until DOD strengthens its
process for selecting and controlling business system investments and
adopts an effective governance concept, it remains exposed to the risk
of spending billions of dollars on duplicative, stove-piped,
nonintegrated systems that do not optimize mission performance and
accountability and, therefore, do not support the department's
transformation goals.
DOD's Plans for Evolving and Extending Its Enterprise Architecture and
for Improving Business System Investment Decision Making Are Unclear:
According to DOD officials, it intends to (1) further develop, evolve,
and extend the architecture, including the transition plan, and issue a
revised version, and (2) improve processes for selecting and
controlling business systems investments. However, DOD's plans for this
next phase have not been explicitly defined. Until they are clearly and
completely defined and effectively implemented, the department risks
perpetuating past business system investment practices and spending
tens of billions of dollars on incompatible, duplicative, and
nonintegrated systems.
DOD's Plans for Issuing Next Version of Architecture Products Are
Unclear:
According to DOD, it intends to issue its next significant version of
the architecture in May 2004 and this update is to extend and evolve
the architecture. To accomplish this, program documentation states that
DOD will, among other things,
* determine the contractor resources needed to evolve and extend the
architecture;
* develop a methodology for integrating the architecture with DOD's GIG
and OMB's Federal Enterprise Architecture;[Footnote 39]
* establish an approach for maintaining its existing systems inventory;
and:
* evaluate the architecture for completeness, accuracy, and integration
of end-to-end business processes and system functions.
However, how DOD will accomplish these and other activities associated
with effectively updating its architecture has not been defined, nor
have such things as roles and responsibilities for executing
activities, dependencies among activities, and measures of activity
progress. Rather, the department basically has plans to develop a
strategy that will define this next phase of activities. By following
this approach, DOD will again be setting unrealistic expectations; and
without clearly defined plans for evolving and extending the
architecture, the department is at risk of falling short of its
intended goals to centrally guide and direct its architecture efforts.
DOD's Plans for Improving Controls over Ongoing and Planned Business
System Investments Are Unclear:
As previously described, DOD has a proposed governance concept that
describes how and by whom business transformation requirements
identified by the architecture will be implemented in the department.
This proposal vests the business line representatives or domain owners
with the authority, responsibility, and accountability for business
transformation, implementation of the architecture, development and
execution of the transition plan, and portfolio management within their
domains. This proposal also designates the domain owners of the
business process areas and provides them a high-level description of
their roles and responsibilities. In addition, the proposal allocates
the current inventory of about 2,300 systems to these domain owners as
portfolios of investments to manage.
However, it is not clear how the proposed approach will be implemented,
and how it will satisfy the act's investment selection and control
requirements. Further, it is also not clear how the proposed approach
will address our recommendations for establishing a hierarchy of
investment review boards and an explicit set of standard criteria for
selecting, controlling, and evaluating IT investments as a portfolio of
options, with one criterion to ensure consistency and compliance with
ongoing architecture development efforts.
According to DOD officials, as a first step, the domain owners will
validate cost and other functional information associated with the
existing inventory of about 2,300 systems and identify those
inventoried systems that will not become part of the "To Be"
architecture. According to DOD, these efforts will evolve over time
and, therefore, its plans do not include a completion date.
Moreover, DOD program documentation provides for initiating pilot
projects in the near term that are to demonstrate and implement a
portion of the architecture and be usable across the department. In
contrast, DOD officials stated that the pilot projects are intended to
validate departmentwide business processes and not to implement
production systems. Thus, the purpose and scope of these projects
remain unclear and specific projects have yet to be selected. If DOD
intends for these projects to demonstrate or validate an enterprisewide
business process to address a current deficiency in DOD's business
operations and systems, such as the lack of common data standards,
these projects could help DOD improve its architecture and thus could
be reasonable investments. However, if the pilot projects are to be
used to acquire and implement system solutions and place them into
production to achieve an operational capability, it is unclear how DOD
will ensure architecture alignment and manage the risk associated with
investing in more systems before it has a well-defined blueprint and an
effective investment management process to guide and control them.
Conclusions:
Recent legislation and our past recommendations to DOD recognize that
it is absolutely essential to have and use a well-defined enterprise
architecture to guide and constrain DOD's business systems
modernization program. DOD's efforts to date to develop such an
architecture, and satisfy its legislative mandate, are good first steps
to this end, but more steps are needed before it will have an adequate
basis for acquiring and implementing its desired systems environment.
In our view, DOD's BEA (version 1.0) provides a foundation for it to
move forward in adding missing architectural scope and detail, and
ultimately validating that the architecture is sufficiently complete
and correct.
DOD has not, however, made similar strides in its efforts to control
its ongoing and planned systems investments. In effect, nothing
significant has changed since our prior review in the way that DOD is
investing billions of dollars annually in existing and new systems.
This means that the department has yet to implement our prior
recommendations for controlling systems funding, and it has not yet
defined and implemented an effective approach to satisfy legislative
requirements for approving systems investments over $1 million. As a
result, billions of dollars continue to be at risk of being spent on
more systems that are duplicative, are not interoperable, cost more to
maintain than necessary, and do not optimize mission performance and
accountability.
The future of DOD's architecture development and implementation
activities is difficult to understand because DOD's near-term plans are
unclear. As a result, DOD's business systems modernization efforts
remain exposed to considerable risk. It is critical for DOD to
effectively expand and extend its architecture to the point that it
provides a sound basis for departmentwide investment decision making,
and that in doing so, it continue to centrally guide and direct its
architecture development efforts and not allow DOD domain owners to
proceed independently. Similarly, it is critical for DOD to immediately
gain control over near-term investments pending the architecture's
completion. This includes justifying further investment in each ongoing
system project beyond fiscal year 2003 and not starting any new
projects that are intended to be put into production and provide
operational capabilities, pilot or otherwise, until the (1)
architecture has been sufficiently completed and (2) DOD has
established an effective institutional approach to make informed
systems investment decisions, including ensuring that each investment
is architecturally aligned. To do less continues to put billions of
dollars at unnecessary risk of perpetuating today's legacy systems
environment.
Recommendations:
Because our open recommendations to DOD for managing the development,
maintenance, and implementation of its BEA, including effectively
controlling ongoing investment in business systems, are critical to the
success of its modernization and transformation efforts, we reiterate
the recommendations that we made in our May 2001[Footnote 40] and
February 2003[Footnote 41] reports. To further assist the department in
effectively implementing these recommendations, we are augmenting them
by providing the following more specific implementation steps.
Specifically, we recommend to the Secretary of Defense that he or his
appropriate designee,
* define and implement an effective investment management process to
proactively identify, control, and obtain DOD Comptroller review and
approval of expenditures for new and ongoing business system
investments exceeding $1 million while the architecture is being
developed and after it is completed, and which includes clearly defined
domain owners' roles and responsibilities for selecting and controlling
ongoing and planned system investments;
* implement the core elements in our EA Framework for Assessing and
Improving Enterprise Architecture Management that we identify in this
report as not satisfied, including ensuring that minutes of the
executive body charged with directing, overseeing, and approving the
architecture are prepared and maintained;
* update version 1.0 of the architecture to include the 340 Joint
Financial Management Improvement Program requirements that our report
identified as omitted or not fully addressed;
* update version 1.0 of the architecture to include the 29 key elements
governing the "As Is" architectural content that our report identified
as not being fully satisfied;
* update version 1.0 of the BEA to include the 30 key elements
governing the "To Be" architectural content that our report identified
as not being fully satisfied;
* update version 1.0 to ensure that "To Be" architecture artifacts are
internally consistent, to include addressing the inconsistencies
described in this report, as well as including user instructions or
guidance for easier architecture navigation and use;
* update version 1.0 of the architecture to include (1) the three key
elements governing the transition plan content that our report
identified as not being fully satisfied and (2) those system
investments that will not become part of the "To Be" architecture,
including time frames for phasing out those systems;
* update version 1.0 of the architecture to address comments made by
the verification and validation contractor;
* 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 activity progress; and:
* limit the pilot projects to small, low-cost, low-risk prototype
investments that are intended to provide knowledge needed to extend and
evolve the architecture, and are not to acquire and implement
production version system solutions or to deploy an operational system
capability.
Agency Comments and Our Evaluation:
In written comments on a draft of this report (reprinted in app. IV),
the department concurred with 9 of our 10 recommendations, partially
concurred with the remaining one, and described recently completed,
ongoing, or planned efforts to address them. We will evaluate whether
DOD's efforts fully address our recommendations in future BEA reviews.
DOD partially concurred with our recommendation regarding the
architectural content of the "As Is" environment stating that because
the current operating environment is dynamic, complete satisfaction of
the 29 key elements that our report identified is not realistically
achievable. DOD stated that such data, even if they were possible to
obtain, would be obsolete upon arrival and, therefore, the department
does not deem the data collection effort to be cost effective. DOD
stated that it is currently analyzing the 29 key elements and that as
part of its incremental development approach, it will collect relevant
"As Is" documentation, where appropriate, and will include the data in
future releases of the BEA.
We agree that architectural information that does not provide value
commensurate with cost should not be captured in the BEA. However,
DOD's comments concerning the missing 29 "As Is" key elements do not
contain sufficient context, detail, and explanation to understand which
key elements DOD proposes to satisfy and which it does not. Further,
its comments do not adequately explain and justify why key elements
should be waived. As noted in our report, DOD's "As Is" architecture
products provide little descriptive content and do not satisfy 90
percent of the architectural elements required by relevant guidance
needed to permit development of a meaningful and useful transition
plan. Further, as noted in our March 2003 report,[Footnote 42] while
further development of the "As Is" environment can coincide with the
development of the transition plan, not having defined the "As Is"
operations and technology at this juncture is risky because it defers
until too late in the architecture development cycle creation of
sufficient descriptive content and context to develop an effective
transition plan.
We are sending copies of this report to interested congressional
committees; the Director, Office of Management and Budget; the
Secretary of Defense; the Under Secretary of Defense (Comptroller); the
Assistant Secretary of Defense (Networks and Information Integration)/
Chief Information Officer; the Under Secretary of Defense (Acquisition,
Technology, and Logistics); the Under Secretary of Defense (Personnel
and Readiness); and the Director, Defense Finance and Accounting
Service. This report will also be available at no charge on our Web
site at [Hyperlink, http://www.gao.gov] http://www.gao.gov.
If you or your staff have any questions on matters discussed in this
report, please contact Gregory D. Kutz at (202) 512-9095 or [Hyperlink,
kutzg@gao.gov] kutzg@gao.gov, or Randolph C. Hite at (202) 512-3439 or
[Hyperlink, hiter@gao.gov] hiter@gao.gov. Major contributors to this
report are acknowledged in appendix V.
Gregory D. Kutz
Director
Financial Management and Assurance:
Randolph C. Hite
Director
Information Technology Architecture and System Issues:
Signed by Gregory D. Kutz and Randolph C. Hite:
List of Committees:
The Honorable John W. Warner
Chairman
The Honorable Carl Levin
Ranking Minority Member
Committee on Armed Services
United States Senate:
The Honorable Ted Stevens
Chairman
The Honorable Daniel K. Inouye
Ranking Minority Member
Subcommittee on Defense
Committee on Appropriations
United States Senate:
The Honorable Duncan Hunter
Chairman
The Honorable Ike Skelton
Ranking Minority Member
Committee on Armed Services
House of Representatives:
The Honorable Jerry Lewis
Chairman
The Honorable John P. Murtha
Ranking Minority Member
Subcommittee on Defense
Committee on Appropriations
House of Representatives:
[End of section]
Appendixes:
Appendix I: SEC. 1004. [of Public Law 107-314] Development and
Implementation of Financial Management Enterprise Architecture:
SEC. 1004. (of Public Law 107-314] DEVELOPMENT AND IMPLEMENTATION OF
FINANCIAL MANAGEMENT ENTERPRISE ARCHITECTURE:
(a) REQUIREMENT FOR ENTERPRISE ARCHITECTURE AND FOR TRANSITION
PLAN-:
Not later than May 1. 2003, the Secretary of Defense shall develop-:
(1) a financial management enterprise architecture for all budgetary,
accounting, finance, enterprise resource planning, and mixed
information systems of the Department of Defense; and:
(2) a transition plan for implementing that financial management
enterprise architecture.
(b) COMPOSITION OF ENTERPRISE ARCHITECTURE-:
(]) The financial management enterprise architecture developed under
subsection (a)(1) shall describe an information infrastructure that, at
a minimum, would enable the Department of Defense to-:
(A) comply with all Federal accounting, financial management, and
reporting requirements;
(B) routinely produce timely, accurate, and reliable financial
information for management purposes;
(C) integrate budget, accounting, and program information and systems;
and:
(D) provide for the systematic measurement of performance, including
the ability to produce timely, relevant, and reliable cost information.
(2) That enterprise architecture shall also include policies,
procedures, data standards, and system interface requirements that are
to apply uniformly throughout the Department of Defense.
(c) COMPOSITION OF TRANSITION PLAN-The transition plan developed under
subsection (a)(2) shall include the following:
(1) The acquisition strategy for the enterprise architecture, including
specific time-phased milestones, performance metrics, and financial and
nonfinancial resource needs.
(2) A listing of the mission critical or mission essential operational
and developmental financial and nonfinancial management systems of the
Department of Defense, as defined by the Under Secretary of Defense
(Comptroller), consistent with budget justification documentation,
together with--:
(A) the costs to operate and maintain each of those systems during
fiscal year 2002; and:
(B) the estimated cost to operate and maintain each of those systems
during fiscal year 2003.
(3) A listing of the operational and developmental financial management
systems of the Department of Defense as of the date of the enactment of
this Act (known as `legacy systems') that will not be part of the
objective financial and nonfinancial management system, together with
the schedule for terminating those legacy systems that provides for
reducing the use of those legacy systems in phases.
(d) CONDITIONS FOR OBLIGATION OF SIGNIFICANT AMOUNTS FOR FINANCIAL
SYSTEM IMPROVEMENTS-
An amount in excess of $1,000,000 may be
obligated for a defense financial system improvement only if the Under
Secretary of Defense (Comptroller) makes a determination regarding that
improvement as follows: (l) Before the date of an approval specified in
paragraph (2), a determination that
the defense financial system improvement is necessary for either of the
following reasons:
(A) To achieve a critical national security capability or address a
critical requirement in an area such as safety or security.
(B) To prevent a significant adverse effect (in terms of a technical
matter, cost, or schedule) on a project that is needed to achieve an
essential capability, taking into consideration in the determination
the alternative solutions for preventing the adverse effect.
(2) On and after the date of any approval by the Secretary of Defense
of a financial management enterprise architecture and a transition plan
that satisfy the requirements of this section, a determination that the
defense financial system improvement is consistent with both the
enterprise architecture and the transition plan.
(e) CONGRESSIONAL REPORTS-Not later than March 15 of each year from
2004 through 2007, the Secretary of Defense shall submit to the
congressional defense committees a report on the progress of the
Department of Defense in implementing the enterprise architecture and
transition plan required by this section. Each report shall include, at
a minimum-:
(1) a description of the actions taken during the preceding fiscal year
to implement the enterprise architecture and transition plan (together
with the estimated costs of such actions);
(2) an explanation of any action planned in the enterprise architecture
and transition plan to be taken during the preceding fiscal year that
was not taken during that fiscal year;
(3) a description of the actions taken and planned to be taken during
the current fiscal year to implement the enterprise architecture and
transition plan (together with the estimated costs of such actions);
and:
(4) a description of the actions taken and planned to be taken during
the next fiscal year to implement the enterprise architecture and
transition plan (together with the estimated costs of such actions).
(f) COMPTROLLER GENERAL REVIEW-Not later than 60 days after the
approval of an enterprise architecture and transition plan in
accordance with the requirements of subsection (a), and not later than
60 days after the submission of an annual report required by subsection
(e), the Comptroller General shall submit to the congressional defense
committees an assessment of the extent to which the actions taken by
the Department comply with the requirements of this section.
(g) DEFINITIONS-In this section:
(1) The term `defense financial system improvement' means the
acquisition of a new budgetary, accounting, finance, enterprise
resource planning, or mixed information system for the Department of
Defense or a modification of an existing budgetary, accounting,
finance, enterprise resource planning, or mixed information system of
the Department of Defense. Such term does not include routine
maintenance and operation of any such system.
(2) The term `mixed information system' means an information system
that supports financial and non-financial functions of the Federal
Government as defined in Office of Management and Budget Circular A-127
(Financial management Systems).
(h) REPEAL-(1) Section 2222 of title 10, United States Code, is
repealed. The table of sections at the beginning of chapter 131 of such
title is amended by striking the item relating to such section.
(2) Section 185(d) of such title is amended by striking `has the
meaning given that term in section 2222(c)(2) of this title' and
inserting `means an automated or manual system from which information
is derived for a financial management system or an accounting system'.
[End of section]
Appendix II: Scope and Methodology:
To accomplish our objectives for determining (1) the extent to which
DOD's actions complied with the requirements of section 1004 of Public
Law 107-314 and (2) DOD's plans for further development and
implementation of the architecture, we assessed DOD's initial
architecture, which, according to DOD, was approved by the DOD
Comptroller and transmitted to the Comptroller General on May 8, 2003.
This report provides specific details on our assessment results. Our
overall assessment of DOD's initial architecture was issued on July 7,
2003,[Footnote 43] which satisfied the legislative requirement that we
submit a report to congressional defense committees within 60 days of
the architecture's approval.
Consistent with the act and as agreed with congressional defense
committees' staffs, this assessment focused on (1) compliance with all
federal accounting, financial management, and reporting requirements,
(2) the content of the "As Is" and "To Be" environments, (3) the
content of the transition plan to include time-phased milestones for
phasing out existing systems, resource needs for implementing the "To
Be" environment, and information on the systems inventory, and (4) the
extent to which DOD is controlling its business system investments. In
addition, we used our Enterprise Architecture Management Maturity
Framework[Footnote 44] that describes the five stages of management
maturity to determine the extent to which DOD has adopted key elements
of architecture management best practices. To make this determination,
we reviewed program documentation, such as program policies and
procedures, steering and executive committee charters, and architecture
products, and compared them to the elements in the framework. We did
not validate the cost and budget information provided by the program's
budget analyst.
Specific to our review of federal requirements, we could not determine
whether the architecture contained all federal accounting, financial
management, and reporting requirements because a central repository of
all such requirements does not exist. Nevertheless, to assess the
completeness of the federal requirements, we compared the about 4,000
external requirements[Footnote 45] contained in the architecture to
those listed in selected JFMIP federal systems requirements
publications.[Footnote 46] Of the 4,000 external requirements
incorporated in the initial architecture, we performed a detailed
review of 1,767 (about 45 percent), all of which were JFMIP
requirements. Specifically, we identified whether these requirements
were incorporated in the initial architecture, relevant to DOD's
business operations, or were current. To supplement our documentation
review, we held interviews with government and contractor officials
from the Office of the Under Secretary of Defense (Comptroller) and
IBM.
For our review of the architecture,[Footnote 47] our internal team of
architecture experts identified relevant criteria to be used to assess
the architecture products, including best practices and federal
guidance.[Footnote 48]
In reviewing the criteria, these experts categorized the key
requirements according to their relevance to the three primary
component parts of the architecture specified in the act and recognized
in best practices and federal guidance: the "As Is" architecture, the
"To Be" architecture, and the transition plan. For ease of reporting,
they further divided the "As Is" and "To Be" architectures into five
architectural components similar to OMB's architecture reference
models: business, information/data, services/applications, technical,
and performance. We added security as a sixth component because of its
recognized importance in the various architecture frameworks and
relevance to the other five architectural components. For each of these
six architectural components, we identified the key architectural
requirements that would need to be addressed for the "As Is" and "To
Be" environments for the department to create an architecture that
would be effective in facilitating its business modernization efforts
and documented this information in detailed matrices. These experts
also identified the key architectural requirements for the transition
plan component of the architecture, which were also documented in a
detailed matrix. We then compared the architecture products including
the transition plan against the identified criteria governing their
content and documented the results of our analysis in the matrices.
We interviewed program officials, including the program director, the
Chief Architect, and contractor staff (IBM and MITRE) to discuss our
preliminary findings and to clarify the intended scope and purpose of
this version of the architecture. We also participated in a 2-day
architecture walkthrough in which DOD officials provided a progress
update on the department's development of the architecture and future
plans for further evolution and implementation of the architecture. In
addition, we reviewed the program's verification and validation
contractor's (MITRE) report[Footnote 49] documenting its assessment of
version 1.0 of the architecture including the transition plan. We also
interviewed program officials as to the department's plans for
addressing MITRE's comments.
To review DOD's actions to comply with the conditions for obligations
in excess of $1 million for financial system improvements, we obtained
and reviewed memorandums and other documentation regarding the approval
of expenditures for system investments in excess of $1 million. We also
reviewed and analyzed the DOD IT budget requests for fiscal years 2003
and 2004 to identify systems that met the $1 million threshold and
compared this to the total number of systems DOD reviewed and approved
to measure DOD's progress in reviewing those systems that meet the
legislative threshold. To augment our document reviews and analyses, we
interviewed officials from various DOD organizations, including the
Office of the Under Secretary of Defense (Comptroller); Office of the
Under Secretary of Defense (Acquisition, Technology, and Logistics);
and the Office of the Under Secretary of Defense (Personnel and
Readiness).
To determine DOD's plans for further development and implementation of
the architecture, we reviewed the initial transition plan and IBM's
statement of work, DOD's proposed governance concept, and program
documentation pertaining to plans for implementing pilot projects. We
also reviewed DOD's response to the recommendations we made in our
February 2003 report[Footnote 50] pertaining to controlling ongoing and
planned IT systems investments. To augment our document reviews and
analyses, we interviewed government and contractor officials from the
Office of the Under Secretary of Defense (Comptroller) and IBM.
We conducted our work primarily at DOD headquarters offices in
Washington, D.C., and Arlington, Virginia, and we performed our work
from March 2003 through June 2003 in accordance with U.S. generally
accepted government auditing standards. We requested comments on a
draft of this report from the Secretary of Defense or his designee.
Written comments from the Under Secretary of Defense (Comptroller) are
addressed in the "Agency Comments and Our Evaluation" section of this
report and are reprinted in appendix IV.
:
[End of section]
Appendix III: Status of Prior Recommendations on DOD's Business
Enterprise Architecture:
[See PDF for image]
Source: GAO analysis of DOD data.
[End of table]
[End of section]
Appendix IV: Comments from the Department of Defense:
COMPTROLLER:
UNDER SECRETARY OF DEFENSE 1 100 DEFENSE PENTAGON WASHINGTON DC 20301-
1100:
AUG 1 8 2003:
Mr. Gregory Kutz Director:
Financial Management and Assurance United States General Accounting
Office Washington, DC 20548:
Dear Mr. Kutz:
Enclosed is the Department of Defense (DoD) response to the General
Accounting Office (GAO) Draft Report, "DoD Business Systems
Modernization: Important Progress Made to Develop Business Enterprise
Architecture, But Much Work Remains," dated July 21, 2003, (GAO-03-
1018). The Department concurs or partially concurs with all 10 of the
GAO's recommendations for corrective action.
My point of contact for this matter is Ms. Marilyn Fleming, Chief
Architect, Directorate for Business Modernization and Systems
Integration. She may be contacted by email: flemingm@osd.pentagon.mil
or by telephone at (703) 607-3367.
Sincerely,
Signed by:
Dov S. Zakheim:
Enclosure: As stated:
DoD Response to Draft GAO Report: "DoD Business Systems Modernization:
Important Progress Made to Develop Business Enterprise Architecture,
But Much Work Remains," dated July 21, 2003, (GAO-03-1018):
1. GAO Recommendation: The Secretary of Defense implement the core
elements in our EA Framework for Assessing and Improving Enterprise
Architecture Management that we identify in this report as not
satisfied, including ensuring that minutes of the executive body
charged with directing, overseeing, and approving the architecture are
prepared and maintained.
DoD Response to GAO Recommendation 1: Concur. The Department of Defense
(DoD) is taking steps to meet our near-term goal of achieving Stage 2
compliance with the GAO Enterprise Architecture Framework. A letter has
been prepared that designates the Business Management Modernization
Program (BMMP) Executive Committee as the body responsible for guiding,
directing, and approving the Business Enterprise Architecture (BEA).
Minutes of future Executive Committee meetings will be prepared and
maintained. In addition, while the Department believes that policy for
the DoD BEA already exists, the Information Technology Portfolio
Management (ITPM) policy currently being developed will identify the
major proponents in the architecture process and further define
responsibilities. Also in development are charters for the BEA
Architecture Review Board and the Configuration Control Board. For
those framework elements related to the "As-Is" architecture that the
GAO has noted as not satisfied, the Department intends to address those
elements, as deemed necessary, when we extend the architecture within
our overall incremental approach.
2. GAO Recommendation: The Secretary of Defense update version 1.0 of
the architecture to include the 340 Joint Financial Management
Improvement Program (JFMIP) requirements that our report identified as
omitted or not fully addressed.
DoD Response to GAO Recommendation 2: Concur. The Department has
updated version 1.0 of the architecture, to address basic errors and
omissions. Version 1.1 of the BEA now includes JFMIP requirement
controls (such as revenue and other controls) that were identified by
GAO as being missing or only partially addressed. Furthermore, Version
1.1 of the BEA includes the new FASAB Standard #23.
3. GAO Recommendation. The Secretary of Defense update version 1.0 of
the architecture to include the 29 key elements governing the "As Is"
architectural content that our report identified as not being fully
satisfied.
DoD Response to GAO Recommendation 3: Partially concur. Because the
current operating environment is dynamic, complete satisfaction of the
29 key elements governing the "As Is" architectural content is not
realistically achievable. Such data, if it were possible to obtain,
might be obsolete upon arrival. The Department, therefore, does not
deem the effort to obtain such data to be cost effective. The DoD
currently is analyzing the referenced 29 key elements, and will
leverage them effectively, where appropriate, in the further
development of the architecture. The Department will collect relevant
"As Is" documentation as part of its incremental
development of the BEA. This "As Is" data also will be included in
future incremental releases of the architecture.
4. GAO Recommendation: The Secretary of Defense update version 1.0 of
the business enterprise architecture to include the 30 key elements
governing the "To Be" architectural content that our report identified
as not being fully satisfied.
DoD Response to GAO Recommendation 4: Concur. The Department is
developing the BEA on an incremental basis in accordance with the
Architecture Development Methodology (ADM). (The Architecture
Methodology Report for Global Information Grid/Federal Enterprise
Architecture (GIG/FEA) Integration describes the Department's
methodology for alignment of the BEA with FEA reference models.) The
DoD currently is analyzing the 30 key elements governing the "To Be"
architectural content, and will satisfy fully all or most of these
elements by the next significant delivery of the BEA (currently planned
for May 2004). The DoD will incorporate pertinent elements of the FEA
reference models during the planned extension and evolution of the
architecture. Each increment of the BEA will align more fully with the
FEA reference models, so that by the time the BEA is complete, it will
contain all pertinent elements of the FEA reference models.
5. GAO Recommendation: The Secretary of Defense update version 1.0 to
ensure that "To Be" architecture artifacts are internally consistent,
to include addressing the inconsistencies described in this report, as
well as including user instructions or guidance for easier architecture
navigation and use.
DoD Response to GAO Recommendation 5: Concur. The Department will
investigate all deliverables to determine what inconsistencies
materially impact the BEA, and DoD will correct those inconsistencies.
As future increments of the BEA are released, the Department will
ensure that no inconsistencies exist between dependencies, such as
between the narrative and the models. The DoD currently provides
instruction for navigating the BEA to users, such as System Architect
Users Guide, Extensibility Guide, Conversion Guide, Popkin Process
Guide, and a Tutorial Guide. This instruction is available on the BEA
web portal. During the architecture refinement process, DoD will assess
various architectural tool mixes to determine if we could make
navigation of the BEA easier.
6. GAO Recommendation: The Secretary of Defense update version 1.0 of
the architecture to include (1) the 3 key elements governing the
transition plan content that our report identified as not being fully
satisfied and (2) those system investments that will not become part of
the "To Be" architecture, including timeframes for phasing out those
systems.
DoD Response to GAO Recommendation 6: Concur. Our transition approach
focuses on deploying the architecture in increments by reengineering
DoD's current inefficient business processes and installing system
solutions that implement leading business practices. We will eliminate
from our current inventory of systems those that have redundant
capability and those that are not compliant with the BEA. Based on best
business practices, this reengineering effort and acquiring and
deploying systems will be done incrementally, and based on the size and
complexity of DoD, we expect it will take about ten years.
The first increment will begin implementing the architecture and its
key business processes and technical standards. Examples of the
processes and standards in the first increment include the United
States Standard General Ledger, a standard accounting code structure,
data standards, data storage and retrieval, and the integration of
logistics business processes with the related acquisition and
accounting processes.
As the Department moves into the reengineering phase for each
Increment, the updated BEA Transition Plan will continue to identify
the needed changes to current business processes and systems by
Increment. As both the BEA and the Transition Plan mature for each
Increment, the analysis will become more specific and refined. As a
result, DoD will then identify which business systems will not be part
of the "To Be" architecture. At that time, a plan for phasing out those
systems will be completed.
7. GAO Recommendation: The Secretary of Defense update version 1.0 of
the architecture to address comments made by the verification and
validation contractor.
DoD Response to GAO Recommendation 7: Concur. The Department has
reviewed and agrees with the comments provide by MITRE, the referenced
Independent Verification and Validation (IV&V) contractor. The BEA
Version 1.0 will be updated, in subsequent versions, to address the
comments provided by MITRE.
8. GAO Recommendation: The Secretary of Defense define and implement an
effective investment management process to proactively identify,
control, and obtain DoD Comptroller review and approval of expenditures
for new and ongoing business system investments exceeding $1 million
while the architecture is being developed and after it is completed,
and which includes clearly defined domain owners' roles and
responsibilities for selecting and controlling ongoing and planned
system investments.
DoD Response to GAO Recommendation 8: Concur. The Department is
finalizing the "Information Technology Portfolio Management (ITPM)"
policy for managing information technology (IT) investments. The
document establishes policies and assigns responsibilities for the
management of DoD IT and associated investments. This policy will be
supplemented by a DoD Instruction, which will provide detailed guidance
and procedures for implementing the ITPM. Implementation of the ITPM
policy and procedures will take place in FY 2004.
9. GAO Recommendation: The Secretary of Defense 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 activity progress.
DoD Response to GAO Recommendation 9: Concur. The Department is
developing a detailed plan for Increment 1 (business process
reengineering). First, DoD is finalizing the Architecture Development
Methodology (ADM). The ADM is the near-term plan to extend and
evolve the architecture. It explains the dependencies among the planned
activities for architecture evolution. The ADM also discusses the task
to define measures of activity progress.
The Department also is developing Domain Plans, which extend the ADM
into the Domains. The Domain Plans also define roles and
responsibilities of all Domain Owner stakeholders. A framework Domain
Plan was delivered in August 2003. We are working on developing a
detailed plan of action and milestones for extending the Increment I of
the BEA into the Domains. The first version of Domain-specific plans
are planned to be completed by the end of the first quarter of FY 2004.
10. GAO Recommendation: The Secretary of Defense limit the pilot
projects to small, low-cost, low-risk prototype investments that are
intended to provide knowledge needed to extend and evolve the
architecture, and are not to acquire and implement production version
system solutions or to deploy an operational system capability.
DoD Response to GAO Recommendation 10: Concur. The Department's pilot
initiatives will test and prove the ADM through a limited number of
small, low cost, low risk prototype investments. These pilot
initiatives also will demonstrate how Increment I of the BEA has
achieved improvements in DoD operations.
[End of section]
Appendix V: GAO Contacts and Staff Acknowledgments:
GAO Contacts:
Jenniffer Wilson, (202) 512-9192 Cynthia Jackson, (202) 512-5086:
Acknowledgments:
In addition to the individuals named above, key contributors to this
report included Beatrice Alff, Nabajyoti Barkakati, Justin Booth,
Francine Delvecchio, Francis Dymond, Jason Kelly, Neelaxi Lakhmani, Anh
Le, Evelyn Logue, Mai Nguyen, Darby Smith, Stacey Smith, Alan Steiner,
Randolph Tekeley, William Wadsworth, and James Weidner.
(192100):
FOOTNOTES
[1] U.S. General Accounting Office, Information Technology:
Architecture Needed to Guide Modernization of DOD's Financial
Operations, GAO-01-525 (Washington, D.C.: May 17, 2001).
[2] Bob Stump National Defense Authorization Act for Fiscal Year 2003,
Pub. L. No. 107-314, § 1004, 116 Stat. 2458, 2629, Dec. 2, 2002.
[3] In May 2003, the DOD Comptroller changed the architecture name from
the Financial Management Enterprise Architecture to the BEA to reflect
the transformation of departmentwide business operations and supporting
systems, including accounting and finance, budget formulation,
acquisition, inventory management, logistics, personnel, and property
management systems.
[4] U.S. General Accounting Office, Business Systems Modernization:
Summary of GAO's Assessment of Department of Defense's Initial Business
Enterprise Architecture, GAO-03-877R (Washington, D.C.: July 7, 2003).
[5] U.S. General Accounting Office, DOD Business Systems Modernization:
Improvements to Enterprise Architecture Development and Implementation
Efforts Needed, GAO-03-458 (Washington, D.C.: Feb. 28, 2003).
[6] U.S. General Accounting Office, Information Technology: A Framework
for Assessing and Improving Enterprise Architecture Management (Version
1.1), GAO-03-584G (Washington, D.C.: April 2003).
[7] See for example, Office of Management and Budget, Federal
Enterprise Architecture Business Reference Model, Version 1.0 (2002);
Chief Information Officer Council, A Practical Guide to Federal
Enterprise Architecture, Version 1.0 (February 2001); Office of
Management and Budget Circular A-130, Management of Federal Information
Resources (Nov. 28, 2000); M.A. Cook, Building Enterprise Information
Architectures: Reengineering Information Systems (Upper Saddle River,
N.J., Prentice Hall: 1996); and National Institute of Standards and
Technology, Information Management Directions: The Integration
Challenge, Special Publication 500-167 (September 1989).
[8] Business systems include financial and nonfinancial systems, such
as civilian personnel, finance, health, logistics, military personnel,
procurement, and transportation, with the common element being the
generation or use of financial data to support DOD's business
operations.
[9] U.S. General Accounting Office, High Risk Series: An Update, GAO-
03-119 (Washington, D.C.: January 2003); U.S. General Accounting
Office, High Risk Series: Strategic Human Capital Management, GAO-03-
120 (Washington, D.C.: January 2003); U.S. General Accounting Office,
High Risk Series: Protecting Information Systems Supporting the Federal
Government and the Nation's Critical Infrastructures, GAO-03-121
(Washington, D.C.: January 2003); and U.S. General Accounting Office,
High Risk Series: Federal Real Property, GAO-03-122 (Washington, D.C.:
January 2003).
[10] U.S. General Accounting Office, DOD Financial Management:
Important Steps Underway But Reform Will Require a Long-term
Commitment, GAO-02-784T (Washington, D.C.: June 4, 2002).
[11] U.S. General Accounting Office, Department of Defense: Status of
Financial Management Weaknesses and Progress Toward Reform, GAO-03-931T
(Washington D.C.: June 25, 2003).
[12] The Clinger-Cohen Act of 1996, Pub. L. No. 104-106, Div. E, Title
LI, sections 5122 and 5125, 110 Stat. 679, 683-85, Feb. 10, 1996
(codified, as amended, at 40 U.S.C. sections 11312 and 11315(b)(2)).
[13] OMB Circular No. A-130, Management of Federal Information
Resources (Nov. 28, 2000).
[14] J.A. Zachman, "A Framework for Information Systems Architecture,"
IBM Systems Journal 26, no. 3 (1987).
[15] See, for example, U.S. General Accounting Office, DOD Business
Systems Modernization: Improvements to Enterprise Architecture
Development and Implementation Efforts Needed, GAO-03-458 (Washington,
D.C.: February 2003); U.S. General Accounting Office, Information
Technology: DLA Should Strengthen Business Systems Modernization
Architecture and Investment Activities, GAO-01-631 (Washington, D.C.:
June 2001); and U.S. General Accounting Office, Information Technology:
INS Needs to Better Manage the Development of Its Enterprise
Architecture, AIMD-00-212 (Washington, D.C.: August 2000).
[16] GAO-01-525.
[17] GAO-03-458.
[18] U.S. General Accounting Office, Information Technology:
Observations on Department of Defense's Draft Enterprise Architecture,
GAO-03-571R (Washington, D.C.: Mar. 28, 2003).
[19] GAO-03-584G.
[20] Chief Information Officer Council, A Practical Guide to Federal
Enterprise Architecture, Version 1.0 (February 2001).
[21] GAO-03-584G.
[22] See for example, Office of Management and Budget, Federal
Enterprise Architecture Business Reference Model, Version 1.0 (2002);
Chief Information Officer Council, A Practical Guide to Federal
Enterprise Architecture, Version 1.0 (February 2001); Office of
Management and Budget Circular A-130, Management of Federal Information
Resources (Nov. 28, 2000); M.A. Cook, Building Enterprise Information
Architectures: Reengineering Information Systems (Upper Saddle River,
N.J., Prentice Hall: 1996); and National Institute of Standards and
Technology, Information Management Directions: The Integration
Challenge, Special Publication 500-167 (September 1989).
[23] JFMIP is a joint undertaking of the Department of the Treasury,
GAO, the Office of Management and Budget, and the Office of Personnel
Management, working with each other, other agencies, and the private
sector to improve financial management in the federal government. JFMIP
issues a series of requirements in support of agency operations.
[24] National Defense PP&E assets include weapons systems and support
PP&E owned by DOD or its component entities for use in the performance
of military missions.
[25] SFFAS No. 23, Eliminating the Category National Defense Property,
Plant, and Equipment, May 2003.
[26] The three sponsoring agencies are the Department of the Treasury,
the Office of Management and Budget, and the General Accounting Office.
[27] The consumption method of accounting requires operating materials
and supplies to be capitalized when purchased and reported as an
operating expense when they are consumed. Under the purchases method,
operating materials and supplies are reported as an operating expense
when they are purchased if their amounts are insignificant, they are in
the hands of the end user for use in normal operations, or it is not
cost effective to apply the consumption method.
[28] Subsection 1004(b)(2) of the act also specifies that DOD's
enterprise architecture shall "include policies, procedures, data
standards, and system interface requirements that are to apply
uniformly throughout the Department."
[29] See for example, Office of Management and Budget, Federal
Enterprise Architecture Business Reference Model, Version 1.0 (2002);
Chief Information Officer Council, A Practical Guide to Federal
Enterprise Architecture, Version 1.0 (February 2001); Office of
Management and Budget, Management of Federal Information Resources,
Circular No. A-130 (Nov. 28, 2000); Cook, M.A., Building Enterprise
Information Architectures: Reengineering Information Systems (Prentice
Hall Inc.: 1996); and National Institute of Standards and Technology,
Information Management Directions: The Integration Challenge, Special
Publication 500-167 (September 1989).
[30] The architecture does not satisfy any aspects of this key
architectural element.
[31] The architecture partially satisfies some aspects of this key
architectural element but does not satisfy at least one significant
aspect.
[32] The Computer Security Act of 1987, Pub. L. No. 100-235, 101 Stat.
1724, Jan. 8, 1988.
[33] See for example, Office of Management and Budget, Federal
Enterprise Architecture Business Reference Model, Version 1.0 (2002);
Chief Information Officer Council, A Practical Guide to Federal
Enterprise Architecture, Version 1.0 (February 2001); Office of
Management and Budget, Management of Federal Information Resources,
Circular No. A-130 (Nov. 28, 2000); Cook, M.A., Building Enterprise
Information Architectures: Reengineering Information Systems (Prentice
Hall Inc.: 1996); and National Institute of Standards and Technology,
Information Management Directions: The Integration Challenge, Special
Publication 500-167 (September 1989).
[34] Troux Technologies, Inc. http://www.eacommunity.com/sponsor/
troux_061903.htm.
[35] See for example, Office of Management and Budget, Federal
Enterprise Architecture Business Reference Model, Version 1.0 (2002);
Chief Information Officer Council, A Practical Guide to Federal
Enterprise Architecture, Version 1.0 (February 2001); Office of
Management and Budget, Management of Federal Information Resources,
Circular No. A-130 (Nov. 28, 2000); Cook, M.A., Building Enterprise
Information Architectures: Reengineering Information Systems (Prentice
Hall Inc.: 1996); and National Institute of Standards and Technology,
Information Management Directions: The Integration Challenge, Special
Publication 500-167 (September 1989).
[36] See for example, Office of Management and Budget, Federal
Enterprise Architecture Business Reference Model, Version 1.0 (2002);
Chief Information Officer Council, A Practical Guide to Federal
Enterprise Architecture, Version 1.0 (February 2001); and Office of
Management and Budget, Management of Federal Information Resources,
Circular No. A-130 (Nov. 28, 2000).
[37] Section 1004 of Public Law 107-314.
[38] MITRE Technical Report: Review of Financial Management Enterprise
Architecture (FMEA), Version 1.0 (June 2003).
[39] See the background section of this report for a description of
OMB's Federal Enterprise Architecture.
[40] GAO-01-525.
[41] GAO-03-458.
[42] GAO-03-571R.
[43] GAO-03-877R.
[44] GAO-03-584G.
[45] External requirements are those that are obtained from
authoritative sources and constrain various aspects of the
architecture.
[46] We used nine JFMIP systems requirements documents: JFMIP-SR-03-01,
Revenue System Requirements (January 2003); JFMIP-SR-02-02,
Acquisition/Financial Systems Interface Requirements (June 2002);
JFMIP-SR-02-01, Core Financial System Requirements (November 2001);
JFMIP-SR-99-5, Human Resources & Payroll Systems Requirements (April
1999); JFMIP-FFMSR-8, System Requirements for Managerial Cost
Accounting (February 1998); JFMIP-FFMSR-7, Inventory System
Requirements (June 1995); JFMIP-SR-99-9, Travel System Requirements
(July 1999); JFMIP-SR-00-4, Property Management Systems Requirements
(October 2000); JFMIP-SR-01-01, Benefit System Requirements (September
2001).
[47] We reviewed version 1.0 of DOD's BEA including the transition
plan, which was completed on April 30, 2003, and according to program
officials, approved on May 8, 2003, by the department's Comptroller.
[48] See, for example, Office of Management and Budget, Federal
Enterprise Architecture Business Reference Model, Version 1.0 (2002);
Chief Information Officers Council, A Practical Guide to Federal
Enterprise Architecture, Version 1.0 (February 2001); Office of
Management and Budget, Management of Federal Information Resources,
Circular No. A-130 (Nov. 28, 2000); M.A. Cook, Building Enterprise
Information Architectures: Reengineering Information Systems (Upper
Saddle River, N.J., Prentice Hall: 1996); and National Institute of
Standards and Technology, Information Management Directions: The
Integration Challenge, Special Publication 500-167 (September 1989).
[49] MITRE Technical Report: Review of Financial Management Enterprise
Architecture (FMEA), Version 1.0 (June 2003).
[50] GAO-03-458.
GAO's Mission:
The General Accounting Office, the 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 the Internet. GAO's Web site ( www.gao.gov ) contains
abstracts and full-text files of current reports and testimony and an
expanding archive of older products. The Web site features a search
engine to help you locate documents using key words and phrases. You
can print these documents in their entirety, including charts and other
graphics.
Each day, GAO issues a list of newly released reports, testimony, and
correspondence. GAO posts this list, known as "Today's Reports," on its
Web site daily. The list contains links to the full-text document
files. To have GAO e-mail this list to you every afternoon, go to
www.gao.gov and select "Subscribe to e-mail alerts" under the "Order
GAO Products" heading.
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. General Accounting 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: fraudnet@gao.gov
Automated answering system: (800) 424-5454 or (202) 512-7470:
Public Affairs:
Jeff Nelligan, managing director, NelliganJ@gao.gov (202) 512-4800 U.S.
General Accounting Office, 441 G Street NW, Room 7149 Washington, D.C.
20548:
