Information Technology
Observations on Department of Defense's Draft Enterprise Architecture
Gao ID: GAO-03-571R March 28, 2003
The fiscal year 2003 Defense Authorization Act requires the Department of Defense (DOD) to develop by May 1, 2003, a financial management enterprise architecture, including a transition plan, that meets certain requirements. The act also requires that GAO submit to congressional defense committees an assessment of the architecture and transition plan within 60 days of their approval. As part of our ongoing work to satisfy this legislative requirement and at the request of Senate Subcommittee on Readiness and Management Support, Committee on Armed Services, staff, we briefed the Subcommittee on Readiness and Management Support, Senate Committee on Armed forces on March 4, 2003, on our preliminary assessment of the DOD draft architecture products dated February 7, 2003. As further requested by the staff, this letter transmits the observations we made during the briefing.
Based on our preliminary assessment of DOD's draft architecture products, we made the following observations during our March 4, 2003, briefing to Congress. To DOD's credit, it is (1) following its Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance Architecture framework and planning to develop most of the products called for by this framework; (2) using an automated tool to create and maintain the architecture products; and (3) following a defined process for identifying the federal regulatory and legal requirements associated with federal accounting standards and financial management and reporting requirements (e.g., Joint Financial Management Improvement Program and Title 10 U.S. Code--Armed Forces) for the seven business process areas2 within the "to be" architecture. However, we also stated that the department had yet to provide a clear definition of the intended purpose of the April 30, 2003, architecture, which, according to federal guidance, is needed to establish the architecture's scope and depth (i.e., the boundaries and level of detail to be provided in the architecture). Further, according to DOD officials' statements and DOD's architecture plans and schedules, the April 30, 2003, version of the architecture will not fully satisfy the requirements contained within Section 1004 of Public Law 107-314. In addition, we stated that the draft architecture did not include a number of items recommended by relevant architectural guidance, such as the "as is" architecture environment, including descriptions of existing business operations and supporting technology; a "to be" security architecture view, which defines the security requirements (e.g., policies, procedures, and controls), including relevant standards to be applied in implementing these controls; "to be" architecture descriptions for all key stakeholders (e.g., DOD top executives and the Congress), which are intended to provide each with sufficient understanding of the architecture to allow for meaningful input; "to be" architecture organization and location views, which define the entities/people who will perform the functions, processes, and activities, and specify the locations where the functions, processes, and activities will be performed; an explicit definition of architecture drivers and governing principles, which are the constraints and requirements that lead to major decisions about the "to be" architecture (e.g., the use of centralized versus distributed processing, and the standardization of business rules to minimize effect on implementation); and defined structure and linkages among "to be" architecture views, such as the linkages among (1) applications and services, (2) organizations using the applications and services, and (3) applicable technical standards. Given that the draft architecture products are not intended to be complete, we also noted that our assessment and observations were limited to the state of the draft products as of February 7, 2003, and that because these products are still being developed, later versions may include missing views and items.
GAO-03-571R, Information Technology: Observations on Department of Defense's Draft Enterprise Architecture
This is the accessible text file for GAO report number GAO-03-571R
entitled 'Information Technology: Observations on Department of
Defense's Draft Enterprise Architecture' which was released on March
28, 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.
March 28, 2003:
The Honorable John Ensign:
Chairman:
The Honorable Daniel K. Akaka:
Ranking Minority Member:
Subcommittee on Readiness and Management Support:
Committee on Armed Services:
United States Senate:
Subject:Information Technology: Observations on Department of
Defense‘s Draft Enterprise Architecture:
The fiscal year 2003 Defense Authorization Act[Footnote 1] requires the
Department of Defense (DOD) to develop by May 1, 2003, a financial
management enterprise architecture, including a transition plan, that
meets certain requirements. The act also requires that we submit to
congressional defense committees an assessment of the architecture and
transition plan within 60 days of their approval. (See enclosure I for
the requirements of this law.) As part of our ongoing work to satisfy
this legislative requirement and at the request of your staff, we
briefed your offices on March 4, 2003, on our preliminary assessment of
the DOD draft architecture products dated February 7, 2003. As further
requested by your staff, this letter transmits the observations we made
during the briefing. (See enclosure II for a summary of our assessment
approach.):
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 or homeland security).
This picture consists of snapshots of both the enterprise‘s current
operational and technological environment and its target environment,
as well as a capital investment road map for transitioning from the
current to the target environment. These snapshots further consist of
’views,“ which are basically one or more architecture products that
provide conceptual or logical representations of the enterprise.
Based on our preliminary assessment of DOD‘s draft architecture
products, we made the following observations during our March 4, 2003,
briefing to your staff. To DOD‘s credit, it is:
* following its Command, Control, Communications, Computers,
Intelligence, Surveillance, and Reconnaissance Architecture framework
and planning to develop most of the products called for by this
framework;
* using an automated tool to create and maintain the architecture
products; and:
* following a defined process for identifying the federal regulatory
and legal requirements associated with federal accounting standards and
financial management and reporting requirements (e.g., Joint Financial
Management Improvement Program and Title 10 U.S. Code--Armed Forces)
for the seven business process areas[Footnote 2] within the ’to be“
architecture.
However, we also stated that the department had yet to provide a clear
definition of the intended purpose of the April 30, 2003, architecture,
which, according to federal guidance, is needed to establish the
architecture‘s scope and depth (i.e., the boundaries and level of
detail to be provided in the architecture). Further, according to DOD
officials‘ statements and DOD‘s architecture plans and schedules, the
April 30, 2003, version of the architecture will not fully satisfy the
requirements contained within Section 1004 of Public Law 107-314. (See
enclosure III for a summary of DOD‘s architecture development and
implementation schedule.):
In addition, we stated that the draft architecture did not include a
number of items recommended by relevant architectural
guidance,[Footnote 3] such as:
* the ’as is“ architecture environment, including descriptions of
existing business operations and supporting technology;
* a ’to be“ security architecture view, which defines the security
requirements (e.g., policies, procedures, and controls), including
relevant standards to be applied in implementing these controls;
* ’to be“ architecture descriptions for all key stakeholders (e.g., DOD
top executives and the Congress), which are intended to provide each
with sufficient understanding of the architecture to allow for
meaningful input;
* ’to be“ architecture organization and location views, which define
the entities/people who will perform the functions, processes, and
activities, and specify the locations where the functions, processes,
and activities will be performed;
* an explicit definition of architecture drivers and governing
principles, which are the constraints and requirements that lead to
major decisions about the ’to be“ architecture (e.g., the use of
centralized versus distributed processing, and the standardization of
business rules to minimize effect on implementation); and:
* defined structure and linkages among ’to be“ architecture views, such
as the linkages among (1) applications and services, (2) organizations
using the applications and services, and (3) applicable technical
standards.[Footnote 4]
Given that the draft architecture products are not intended to be
complete, we also noted that our assessment and observations were
limited to the state of the draft products as of February 7, 2003, and
that because these products are still being developed, later versions
may include missing views and items.
In commenting on a draft of this letter, DOD Comptroller officials,
including the Director, Business Management Systems Integration Office,
stated that they generally agreed with our assessment of the February
7, 2003, draft architecture products. The director also commented that
the state of DOD‘s ’as is“ architecture products is appropriate at this
point in time and that DOD accepts the risk of not investing further in
defining these products until development of the transition plan
requires it to do so. We agree that further development of the ’as is“
can coincide with the development of the transition plan, but also note
that not having defined ’as is“ operations and technology at this
juncture is risky because it defers too late in the architecture
development cycle a very important set of tasks.
The director also commented that the April 30, 2003, version of the
architecture would address all the requirements of the act, but that
the degree to which they are addressed would vary and that subsequent
versions of the architecture would provide missing details. We agree
that the April 30, 2003, version of the architecture will likely
address, to some degree, the architecture requirements in the act.
However, our observation was that this version of the architecture
would not fully satisfy the act‘s requirements. DOD‘s comment is
consistent with our observations.
We will be sending copies of this letter to interested congressional
committees and the Director, Office of Management and Budget. This
letter will also be available at no charge on our Web site at
www.gao.gov.
If you have any questions concerning this information, please contact
us at (202) 512-3439 or (202) 512-9095, respectively. We can also be
reached by E-mail at hiter@gao.gov or kutzg@gao.gov. GAO contacts and
key contributors to this letter are listed in appendix IV.
Randolph C. Hite:
Director, Information Technology Architecture and Systems Issues:
Gregory D. Kutz:
Director, Financial Management and Assurance:
Signed by Randolph C. Hite and Gregory D. Kutz:
Enclosures:
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--:
(1) 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:
(1) 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‘.
Summary of Assessment Approach:
As part of our ongoing work under Section 1004 of Public Law 107-314,
we performed a preliminary assessment of Department of Defense (DOD)
draft enterprise architecture products dated February 7, 2003. This
assessment included analyzing relevant criteria[Footnote 5] to identify
the architecture views that are needed to provide key stakeholders a
complete understanding of the architecture and searching all the draft
products to determine whether these views existed. In searching the
products, we specifically focused on governing principles, standards,
and security, because they are fundamental elements of a well-defined
and enforceable architecture. In addition, we traced linkages between
the different views to determine if these linkages had been
specifically identified to ensure ease of stakeholder navigation and
understanding. We also reviewed DOD‘s schedule of deliverables and its
October 2002 transition plan strategy to ascertain the department‘s
future plans for later versions of the architecture.
To determine whether DOD had a defined process for identifying the
federal regulatory and legal requirements associated with federal
accounting standards and financial management and reporting (e.g.,
Joint Financial Management Improvement Program and Title 10 U.S. Code-
-Armed Forces), we obtained and performed a preliminary review of the
traceability matrices prepared by the DOD program office that
documented these requirements for each of the seven business process
areas within the ’to be“ architecture. We also interviewed program
officials to obtain an understanding of the methodology being used to
identify, track, validate, and update the information contained within
these matrices. We did not evaluate the completeness or validity of the
requirements developed as part of the draft architecture. Also, we did
not review the process related to investment management as described in
Section 1004 of Public Law 107-314. Additionally, because we assessed
draft architecture products as of February 7, 2003, our observations
are limited to the state of these products as of that date.
We performed our work from February 2003 through March 2003 in
accordance with generally accepted government auditing standards.
Summary of Architecture Development and Implementation Schedule:
Notes: GAO analysis based on DOD information.
OV is Operational View. OV is to depict the organization-wide business
environment and activities that need to occur to achieve the ’to be“
state.
SV is Systems View. SV is to describe the set of system capabilities
that are to provide DOD with accurate, reliable, and timely access to
business management and associated financial information.
TV is Technical View. TV is to contain the set of rules that govern
system implementation and operation.
According to DOD, subsequent architecture versions (9/30/2003) will
include (1) relevant standards (e.g., data) to guide projects and
investments, (2) life-cycle costs for systems, and (3) security in OV
and SV products.
GAO Contacts and Staff Acknowledgments:
GAO ContactsCynthia Jackson, (202) 512-5086
Jenniffer Wilson, (202) 512-9192:
AcknowledgmentsIn addition to the individuals named above, key
contributors to this letter included Nabajyoti Barkakati, Barbara
Collier, Neelaxi Lakhmani, Anh Le, Evelyn Logue, Mai Nguyen, Stacey
Smith, Al Steiner, Randolph Tekeley, and William Wadsworth.
(310253):
FOOTNOTES
[1] Section 1004 of Public Law 107-314.
[2] The seven business process areas are (1) accounting;
(2) collection, accounts receivable, and cash management;
(3) financial and management reporting; (4) human resource management;
(5) logistics; (6) procurement, payables, acquisition, and disbursing;
and (7) strategic planning and budgeting.
[3] See, for example, Institute of Electrical and Electronics Engineers
Standard 1471; Software Engineering Institute Open Systems
publications; Federal Enterprise Architecture Framework; Zachman
Framework; and Command, Control, Communications, Computers,
Intelligence, Surveillance and Reconnaissance Architecture framework.
[4] Technical standards provide the set of rules that govern system
implementation and operation.
[5] See, for example, Institute of Electrical and Electronics Engineers
Standard 1471, Software Engineering Institute Open Systems
publications, Federal Enterprise Architecture Framework, Zachman
Framework, and Command, Control, Communications, Computers,
Intelligence, Surveillance and Reconnaissance Architecture framework.