This is the accessible text file for GAO report number GAO-04-777 
entitled 'Homeland Security: Efforts Under Way to Develop Enterprise 
Architecture, but Much Work Remains' which was released on August 17, 
2004.

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

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

Report to the Subcommittee on Technology, Information Policy, 
Intergovernmental Relations and the Census, Committee on Government 
Reform, House of Representatives: 

August 2004: 

HOMELAND SECURITY: 

Efforts Under Way to Develop Enterprise Architecture, but Much Work 
Remains: 

[Hyperlink, http://www.gao.gov/cgi-bin/getrpt?GAO-04-777]: 

GAO Highlights: 

Highlights of GAO-04-777, a report to Chairman, Subcommittee on 
Technology, Information Policy, Intergovernmental Relations and the 
Census, Committee on Government Reform, House of Representatives.

Why GAO Did This Study: 

The Department of Homeland Security (DHS) is attempting to integrate 22 
federal agencies, each specializing in one or more interrelated aspects 
of homeland security. An enterprise architecture is a key tool for 
effectively and efficiently accomplishing this. In September 2003, DHS 
issued an initial version of its architecture. Since 2002, the Office 
of Management and Budget (OMB) has issued various components of the 
Federal Enterprise Architecture (FEA), which is intended to be, among 
other things, a framework for informing the content of agencies’ 
enterprise architectures. GAO was asked to determine whether the 
initial version of DHS’s architecture (1) provides a foundation upon 
which to build and (2) is aligned with the FEA.

What GAO Found: 

DHS’s initial enterprise architecture provides a partial foundation 
upon which to build future versions. However, it is missing, either in 
part or in total, all of the key elements expected to be found in a 
well-defined architecture, such as descriptions of business processes, 
information flows among these processes, and security rules associated 
with these information flows, to name just a few (see figure below for 
a summary of key elements present). Moreover, the key elements that 
are at least partially present in the initial version were not derived 
in a manner consistent with best practices for architecture 
development. Instead, they are based on assumptions about a DHS or 
national corporate business strategy and, according to DHS, are largely 
the products of combining the existing architectures of several of the 
department’s predecessor agencies, along with their respective 
portfolios of system investment projects. DHS officials agreed that 
their initial version is lacking key elements, and they stated that 
this version represents what could be done in the absence of a 
strategic plan, with limited resources, and in the 4 months that were 
available to meet an OMB deadline for submitting the department’s 
fiscal year 2004 information technology budget request. In addition, 
they stated that the next version of the architecture, which is to be 
issued in September 2004, would have much more content. As a result, 
DHS does not yet have the necessary architectural blueprint to 
effectively guide and constrain its ongoing business transformation 
efforts and the hundreds of millions of dollars that it is investing in 
supporting information technology assets. Without this, DHS runs the 
risk that its efforts and investments will not be well integrated, will 
be duplicative, will be unnecessarily costly to maintain and interface, 
and will not optimize overall mission performance.

The department’s initial enterprise architecture can be traced 
semantically with the FEA, which means that similar terms and/or 
definitions of terms can be found in the respective architectures. 
However, traceability in terms of architecture structures and functions 
is not apparent. Because of this, it is not clear whether the substance 
and intent of the respective architectures are in fact aligned, meaning 
that, if both were implemented, they would produce similar outcomes. 
This is due at least in part to the fact that OMB has yet to clearly 
define what it expects the relationship between agencies’ enterprise 
architectures and the FEA to be, including what it means by 
architectural alignment.

Summary of Extent to Which Version 1.0 Satisfies Key Elements Governing 
Architectural Content: 

[See PDF for image]

[End of figure]

What GAO Recommends: 

GAO is making recommendations to the Secretary of Homeland Security 
aimed at improving the department’s architecture content and 
development approach. GAO is also making a recommendation to the 
Director of OMB to clarify the expected relationship between agencies’ 
enterprise architectures and the FEA. In comments on this report, DHS 
stated that it was not realistic for the initial version of its 
architecture to satisfy all of the key elements recommended by GAO, but 
that future versions would do so. OMB stated that it would address the 
FEA and agency architecture relationship issues that GAO reported.

www.gao.gov/cgi-bin/getrpt?GAO-04-777.

To view the full product, including the scope and methodology, click on 
the link above. For more information, contact Randolph C. Hite at (202) 
512-3439 or hiter@gao.gov.

[End of section]

Contents: 

Letter: 

Results in Brief: 

Background: 

Initial Version of DHS's Architecture Provides a Partial Foundation 
upon Which to Build, but Not a Sufficient Basis to Guide Investment 
Decisions: 

Initial Architecture Can Be Partially Traced to the Federal Enterprise 
Architecture, but the Extent of Alignment Is Unclear: 

Conclusions: 

Recommendations for Executive Action: 

Agency Comments and Our Evaluation: 

Appendixes: 

Appendix I: Objectives, Scope, and Methodology: 

Appendix II: Detailed Results of GAO's Analyses of Version 1.0 of DHS's 
"To Be" Architecture: 

Appendix III: Detailed Results of GAO's Analyses of Version 1.0 of 
DHS's Transition Plan: 

Appendix IV: Comments from the Department of Homeland Security: 

GAO Comments: 

Appendix V: GAO Contact and Staff Acknowledgments: 

GAO Contact: 

Staff Acknowledgments: 

Tables: 

Table 1: Overview of Key DHS Component Organizations' Roles: 

Table 2: Summary of Key Architecture Entities and Individuals and Their 
Responsibilities: 

Table 3: GAO's Framework for Enterprise Architecture Management 
Maturity: 

Table 4: Service Domains, the Capabilities That They Describe, and 
Associated Service Types: 

Figures: 

Figure 1: Simplified Diagram of DHS Organizational Structure: 

Figure 2: Summary of Extent to Which Version 1.0 Satisfies Key Elements 
Governing Architectural Content: 

Abbreviations: 

CIO: chief information officer: 

CURE: create, update, reference, and eliminate: 

DHS: Department of Homeland Security: 

DOD: Department of Defense: 

EAI: enterprise application integration: 

FEA: Federal Enterprise Architecture: 

GIG: Global Information Grid: 

IT: information technology: 

OMB: Office of Management and Budget: 

TRM: technical reference model: 

Letter August 6, 2004: 

The Honorable Adam H. Putnam: 
Chairman, Subcommittee on Technology, Information Policy, 
Intergovernmental Relations and the Census: 
Committee on Government Reform: 
House of Representatives: 

Dear Mr. Chairman: 

Following September 11, 2001, homeland security emerged as a more 
prominent federal mission. To improve the federal government's ability 
to fulfill this mission, Congress passed and the President signed the 
Homeland Security Act of 2002. Among other things, this act created the 
Department of Homeland Security (DHS) by merging 22 separate agencies, 
each specializing in one or more interrelated and interdependent 
aspects of homeland security, such as intelligence analysis, law 
enforcement, border security, transportation security, biological 
research, critical infrastructure protection, and disaster recovery. 
The effective interaction, integration, and synergy of these agencies 
are critical to homeland security mission performance.

Because of the importance of the department's mission operations and 
the enormity of the challenges associated with creating the federal 
government's third largest department, we designated the implementation 
and transformation of DHS as a high-risk area in January 2003.[Footnote 
1] We also reported in June 2002 that DHS needed to, among other 
things, develop and implement an enterprise architecture to aid in 
optimizing departmentwide operations and its supporting systems 
environments.[Footnote 2] As we have repeatedly reported,[Footnote 3] a 
well-defined enterprise architecture is essential to an organization's 
ability to transform its operations and supporting systems in a way 
that eliminates duplication, promotes interoperability, reduces costs, 
and optimizes mission performance.

Recognizing the pivotal role that an architecture will play in 
successfully merging the diverse operating and systems environments 
that the department inherited, DHS issued an initial version in 
September 2003. The department also stated its intention to improve on 
this initial version and issue a second version in September 2004. You 
requested that we determine whether the initial version of the 
architecture (1) provides a foundation upon which to build and (2) is 
aligned with the Office of Management and Budget's (OMB) Federal 
Enterprise Architecture (FEA).[Footnote 4] We performed our work in 
accordance with generally accepted government auditing standards. 
Details on our objectives, scope, and methodology are in appendix I.

Results in Brief: 

The department's initial enterprise architecture provides a partial 
basis upon which to build future versions. However, it is missing most 
of the content necessary to be considered a well-defined architecture. 
Moreover, the content in this version was not systematically derived 
from a DHS or a national corporate business strategy; rather, it was 
more the result of an amalgamation of the existing architectures that 
several of DHS's predecessor agencies already had, along with their 
respective portfolios of system investment projects. Such a development 
approach is not consistent with recognized architecture development 
best practices. DHS officials agreed with our content assessment of 
their initial architecture, stating that it is largely a reflection of 
what could be done without a strategic plan to drive architectural 
content and with limited resources and time. They also stated that the 
primary purposes in developing this version were to meet an OMB 
deadline for submitting the department's fiscal year 2004 information 
technology (IT) budget request and to mature the department's 
understanding of enterprise architecture and its ability to execute an 
approach and methodology for developing and using the next version of 
the architecture. Regardless, the fact remains that DHS does not yet 
have the architectural content that it needs to effectively guide and 
constrain its business transformation efforts and the hundreds of 
millions of dollars it is investing in supporting systems. Without such 
content, DHS runs the risk that its investments will not be well 
integrated, will be duplicative, will be unnecessarily costly to 
maintain and interface, and will not effectively optimize mission 
performance. To their credit, the department's chief information 
officer and senior architecture officials recognize the architecture's 
limitations and are in the process of developing a new version.

DHS's initial enterprise architecture can be aligned semantically with 
the FEA,[Footnote 5] that is, similar terms and/or definitions of terms 
can be found in the respective architectures. However, alignment in 
terms of architecture structures and functions is not apparent. Because 
of this, it is not clear whether the substance and intent of each has 
the same meaning and would produce similar outcomes if implemented. 
This is at least in part due to the fact that OMB has yet to clearly 
define what it expects the relationship to be between agencies' 
enterprise architectures and the FEA, including what OMB means by the 
term architectural alignment.

To assist DHS in developing a well-defined enterprise architecture, we 
are recommending 41 actions aimed at having DHS's architecture 
executive steering committee provide the resources necessary to add 
needed architecture content and ensure that architecture development 
best practices are employed. In addition, to assist DHS and other 
agencies in developing and evolving their respective architectures, we 
are making a recommendation to OMB to clarify the expected relationship 
between the FEA and federal agencies' architectures.

In written comments on a draft of our report that was signed by the 
Director, Bankcard Programs and GAO/OIG Liaison within the Office of 
the Chief Financial Officer, DHS stated that it took exception to 
several aspects of our report, including the appropriateness and prior 
disclosure of the criteria that we used to evaluate the initial version 
of its architecture and to the premature nature of our recommendations, 
given the limited scope and intent of this initial version. 
Nevertheless, DHS agreed with our position that much work remains to 
develop an architecture that can support business and IT 
transformation. Moreover, despite taking exception to the criteria and 
our recommendations, the department also stated that it would ensure 
that the criteria we used to evaluate the initial version, which we 
reference in our recommendations, are addressed to the extent possible 
in the next version of its architecture. While we do not agree with 
DHS's view of the criteria we used and the recommendations we made--for 
reasons discussed later in this report--or with other comments that DHS 
provided stating that some of our facts about the content of the 
initial version are not correct, we do agree with the department's 
decision to address our recommendations incrementally. As we have long 
held and reported, enterprise architecture development should be 
incremental, with each version of the architecture adding more depth 
and detail to an enterprisewide, business-driven foundation. 
Accordingly, the intent of our recommendations is to provide DHS with a 
constructive road map, grounded in explicit criteria, for incrementally 
developing a mission-derived blueprint for business and technology 
transformation.

In its oral comments on a draft of this report, OMB's Office of E-
Government and Information Technology and Office of General Counsel 
stated that its continuing evolution of the FEA will clarify the FEA's 
relationship with agencies' architectures and will address issues 
raised in our report.

Background: 

The creation of DHS in November 2002[Footnote 6] represents the most 
significant transformation of the U.S. government since 1947, when the 
various branches of the U.S. Armed Forces were combined into the 
Department of Defense (DOD) to better coordinate the nation's defense 
against military threats. In January 2003, we cited numerous management 
and leadership challenges facing DHS as it attempted to merge 22 
separate federal agencies, and we designated the department's 
transformation as high risk.[Footnote 7] Shortly thereafter, the 
department stated that it faced significant transformational 
challenges, such as (1) developing new business processes, (2) unifying 
multiple organizational structures, (3) integrating multiple border-
security and interior-enforcement functions, (4) integrating 
information technology (application systems and infrastructures), and 
(5) improving information sharing. The magnitude of these challenges is 
enormous. For example, DHS reports that it has redundancies in such 
business processes as human resources management, financial management, 
and procurement--including about 300 application systems that support 
inconsistent and duplicative processes. DHS also reports that it plans 
to invest about $4.1 billion during fiscal year 2004 in IT for both new 
and existing systems, to more effectively and efficiently support its 
mission operations and business processes.

An enterprise architecture is a key tool for effectively and 
efficiently overcoming the kinds of transformational challenges that 
face DHS. In short, it is a business and technology blueprint that 
links an organization's strategic plan to the program and supporting 
system implementations that are needed to systematically move the 
organization from how it operates today to how it intends to operate 
tomorrow. As we have repeatedly reported,[Footnote 8] without an 
enterprise architecture to guide and constrain IT investments, it is 
unlikely that an organization will be able to transform its business 
processes and modernize its supporting systems in a way that minimizes 
overlap and duplication, and thus costs, and maximizes interoperability 
and mission performance.

DHS's Mission and Organizational Structure: A Brief Description: 

According to DHS's strategic plan, its mission is to lead a unified 
national effort to secure America by preventing and deterring terrorist 
attacks and protecting against and responding to threats and hazards to 
the nation. DHS also is to ensure safe and secure borders, welcome 
lawful immigrants and visitors, and promote the free flow of commerce. 
As part of its responsibilities, the department must also coordinate 
and facilitate the sharing of information both among its component 
agencies and with other federal agencies, state and local governments, 
the private sector, and other entities.

As illustrated in DHS's organizational structure (see fig. 1), to 
accomplish its mission it has five under secretaries with 
responsibility over the directorates or offices for management, science 
and technology, information analysis and infrastructure protection, 
border and transportation security, and emergency preparedness and 
response. Each DHS directorate is responsible for leading its specific 
homeland security mission area and coordinating relevant efforts with 
other federal agencies and state and local governments. The department 
is also composed of other component organizations, such as the U.S. 
Coast Guard and the U.S. Secret Service. Table 1 describes the primary 
roles of these five directorates and several of these component 
organizations.

Figure 1: Simplified Diagram of DHS Organizational Structure: 

[See PDF for image] 

[End of figure] 

Table 1: Overview of Key DHS Component Organizations' Roles: 

Key organizations: Management; 
Roles: Manages budgets, appropriations, expenditure of funds, 
accounting and finance, procurement, human resources and personnel, 
information technology, facilities, property, and equipment in support 
of the other four directorates.

Key organizations: Science and technology; 
Roles: Organizes scientific and technological resources to prevent or 
mitigate the effects of catastrophic terrorism; unifies and coordinates 
efforts to develop and implement scientific and technological 
countermeasures; sponsors research and evaluates new vaccines, 
antidotes, diagnostics, and therapies against biological and chemical 
warfare agents.

Key organizations: Information analysis and infrastructure protection; 
Roles: Analyzes intelligence and information obtained from other 
agencies (including the Central Intelligence Agency, Federal Bureau of 
Investigation, and National Security Agency) involving threats to 
homeland security; evaluates vulnerabilities in the nation's 
infrastructure; and works with stakeholders to develop and implement 
an integrated national plan for the physical and cyberprotection of 
critical infrastructures and key assets.

Key organizations: Border and transportation security; 
Roles: Prevents the illegal entry of people or goods while facilitating 
the unimpeded flow of lawful commerce and people across our borders, 
secures our nation's transportation systems, and enforces immigration 
laws.

Key organizations: Emergency preparedness and response; 
Roles: Prepares for, mitigates the effects of, responds to, and 
recovers from major domestic disasters, both natural and man-made, 
including incidents of terrorism.

Key organizations: Coast Guard; 
Roles: Protects the public, the environment, and U.S. economic and 
security interests in international waters and America's coasts, ports, 
and inland waterways.

Key organizations: Secret Service; 
Roles: Protects the President and other government leaders, provides 
security for designated national events, and preserves the integrity of 
the nation's financial and critical infrastructures.

Key organizations: Citizenship and immigration services; 
Roles: Administers services, such as immigrant and nonimmigrant 
sponsorship, adjustment of status, work authorization and other 
permits, naturalization of qualified applicants for U.S. citizenship, 
and asylum or refugee processing.

Key organizations: Counter narcotics; 
Roles: Coordinates policy and operations within the department and 
between the department and other federal agencies with respect to 
illegal drug trafficking and its terrorist-related ramifications; 
facilitates the tracking and severing of connections between drug 
trafficking and terrorism.

Key organizations: State and local coordination; 
Roles: Facilitates and coordinates departmental programs that affect 
state, local, territorial, and tribal governments.

Key organizations: National capital region coordination; 
Roles: Oversees and coordinates federal programs and domestic 
preparedness initiatives for state, local, and regional authorities in 
the National Capital Region, including the District of Columbia, 
Maryland, and Virginia.

Source: DHS.

[End of table]

Within the Management directorate is the DHS Office of the Chief 
Information Officer (CIO), which has primary responsibility for 
addressing departmentwide information technology integration issues. 
According to the CIO, this office's responsibilities include developing 
and facilitating the implementation of such integration enablers as 
the department's IT strategic plan and its enterprise architecture. The 
CIO released an initial version of the enterprise architecture in 
September 2003 and plans to issue the next version in September 2004. 
According to the CIO, updated releases of the architecture will be 
issued on an annual basis. To provide the necessary leadership, 
direction, and management to create the architecture, the CIO 
established various entities and assigned specific responsibilities to 
each. Table 2 describes the key architecture entities and individuals 
involved in developing and maintaining the architecture, along with 
their respective responsibilities.

Table 2: Summary of Key Architecture Entities and Individuals and Their 
Responsibilities: 

Entity/position: Office of Planning and Enterprise Architecture; 
Responsibilities: Manages the department's architecture program and is 
led by the chief architect, who oversees the development, verification, 
and adoption of the architecture. Reports to the department's CIO.

Entity/position: Enterprise architecture executive steering committee 
(also called the DHS Management Council); 
Responsibilities: Is accountable and responsible for the enterprise 
architecture. Makes decisions that affect the enterprise architecture 
and the associated program; determines projects' compliance with the 
architecture. Provides advice or guidance to the department's CIO. 
Composed of senior executives from technical and business organizations 
across the department (e.g., DHS CIO, Under Secretary for Border and 
Transportation Security, the Commandant of the Coast Guard, and the 
Director of the U.S. Secret Service).

Entity/position: Enterprise architecture core team; 
Responsibilities: Trains users and core team members. Promotes and 
evaluates the architecture program. Collects and analyzes performance 
data on architecture activities. Provides consulting support to project 
personnel to help achieve compliance with the architecture.

Entity/position: Enterprise architecture configuration control board 
working group; 
Responsibilities: Controls changes to architecture products and 
processes in accordance with configuration management principles. 
Establishes and oversees the processes for submitting, evaluating, and 
implementing change requests, and is directed by the chief architect. 

Source: DHS.

[End of table]

Enterprise Architecture: A Brief Description: 

Effective use of enterprise architectures is a trademark of successful 
public and private organizations. For a decade, we have promoted the 
use of architectures to guide and constrain systems modernization, 
recognizing them as a crucial means to a challenging goal: establishing 
agency operational structures that are optimally defined in both 
business and technological environments. Congress, OMB, and the federal 
CIO Council have also recognized the importance of an architecture-
centric approach to modernization. The Clinger-Cohen Act of 1996 
mandates that an agency's CIO develop, maintain, and facilitate the 
implementation of an IT architecture. This should provide the means for 
managing the integration of business processes and supporting systems. 
Further, the E-Government Act of 2002[Footnote 9] requires OMB to 
oversee the development of enterprise architectures within and across 
agencies.

Generally speaking, an enterprise architecture connects an 
organization's strategic plan with program and system solution 
implementations by providing the fundamental information details needed 
to guide and constrain implementable investments in a consistent, 
coordinated, and integrated fashion. An enterprise architecture 
provides a clear and comprehensive picture of an entity, whether it is 
an organization (e.g., federal department) or a functional or mission 
area that cuts across more than one organization (e.g., homeland 
security). 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 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.

The suite of products and their content that form a given entity's 
enterprise architecture are largely governed by the framework used to 
develop the architecture. Since the 1980s, various frameworks have 
emerged and been applied. For example, John Zachman developed a 
structure or framework for defining and capturing an 
architecture.[Footnote 10] This framework provides for six windows from 
which to view the enterprise, which Zachman calls "perspectives" on how 
a given entity operates: the perspectives 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 that are 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.

Other frameworks also exist. Each of these frameworks use somewhat 
unique nomenclatures to define themselves. However, they all generally 
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 for both the enterprise's 
current or "As Is" environment and its target or "To Be" environment, 
as well as a transition plan for moving from the "As Is" to the "To Be" 
environment.

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.

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 to 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 
an organization's operational and IT environments will be configured to 
optimize mission performance. Our experience with federal agencies has 
shown that investing in IT without defining these investments in the 
context of an architecture often results in systems that are 
duplicative, not well integrated, and unnecessarily costly to maintain 
and interface.[Footnote 11]

Our Prior Work Has Emphasized the Need for a DHS Enterprise 
Architecture: 

For the last 2 years, we have promoted the development and use of a 
homeland security enterprise architecture. In June 2002, we 
testified[Footnote 12] on the need to define the homeland security 
mission and the information, technologies, and approaches necessary to 
perform this mission in a way that is divorced from organizational 
parochialism and cultural differences. At that time, we stressed that a 
particularly critical function of a homeland security architecture 
would be to establish processes and information/data protocols and 
standards that could facilitate information collection and permit 
sharing.

In January 2003, when we designated DHS's transformation as high risk, 
we again emphasized the need to develop and implement an enterprise 
architecture. In May 2003 testimony,[Footnote 13] we reiterated this 
need, stating that, for DHS to be successful in addressing threats of 
domestic terrorism, it would need to establish effective systems and 
processes to facilitate information sharing among and between 
government entities and the private sector. We stated that to 
accomplish this the department would need to develop and implement an 
enterprise architecture.

In August 2003,[Footnote 14] we reported that DHS had begun to develop 
an enterprise architecture and that it planned to use this architecture 
to assist its efforts to integrate and share information between 
federal agencies and among federal agencies, state and city 
governments, and the private sector. In November 2003,[Footnote 15] we 
reported on DHS's progress in establishing key enterprise architecture 
management capabilities, as described in our architecture management 
maturity framework.[Footnote 16] This framework associates specific 
architecture management capabilities with five hierarchical stages of 
management maturity, starting with creating architecture awareness and 
followed by building the architecture management foundation, developing 
the architecture, completing the architecture, culminating in 
leveraging the architecture to manage change (see table 3 for a more 
detailed description of the stages).

Table 3: GAO's Framework for Enterprise Architecture Management 
Maturity: 

Maturity stage: Stage 1: Creating enterprise architecture 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 architecture activity, these agencies' efforts 
are ad hoc and unstructured, lack institutional leadership and 
direction, and do not provide the management foundation that is 
necessary for successful architecture development.

Maturity stage: Stage 2: Building the enterprise architecture 
management foundation; 
Description: Organization recognizes that the architecture is a 
corporate asset by vesting accountability for it in an executive body 
that represents the entire enterprise. At this stage, an organization 
assigns architecture management roles and responsibilities and 
establishes plans for developing enterprise architecture products and 
for measuring program progress and product quality; it also commits 
the resources necessary for developing an architecture--people, 
processes, and tools.

Maturity stage: Stage 3: Developing the enterprise architecture; 
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 
enterprise architecture products. The scope of the architecture has 
been defined to encompass the entire enterprise, whether organization-
based or function-based.

Maturity stage: Stage 4: Completing the enterprise architecture; 
Description: Organization has completed its enterprise architecture 
products, meaning that the products have been approved by the 
architecture 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 architecture products. Additionally, 
evolution of the approved products is governed by a written 
architecture maintenance policy approved by the head of the 
organization.

Maturity stage: Stage 5: Leveraging the enterprise architecture to 
manage change; 
Description: Organization has secured senior leadership approval of 
the enterprise architecture products and a written institutional 
policy stating that IT investments must comply with the architecture 
unless they are 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 architecture benefits or return on investment, and 
adjustments are continuously made to both the architecture management 
process and the enterprise architecture 
products.

Source: GAO.

[End of table]

Based on information provided by DHS, we reported that the department 
had established an architecture management foundation and was 
developing architecture products, and we rated the department to be at 
stage 3 of our maturity framework. In particular, we reported that it 
had (1) established a program office responsible for developing and 
maintaining the architecture; (2) assigned a chief architect to oversee 
the program; (3) established plans for developing metrics for measuring 
progress, quality, compliance, and return on investment; and (4) placed 
the architecture products under configuration management. 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. An 
enterprise with these characteristics would need to satisfy all of the 
requirements associated with stage 3 of our framework, and many of the 
requirements of stages 4 and 5.

In addition, we reported in May 2004[Footnote 17] that DHS was in the 
process of defining its strategic IT management framework for, among 
other things, integrating its current and future systems and aligning 
them with the department's strategic goals and mission. We also 
reported that a key component of this initiative was the development of 
the department's enterprise architecture. Accordingly, we recommended 
that, until the framework was completed, the department limit its 
spending on IT investments to cost-effective efforts that: 

* are congressionally directed;

* take advantage of near-term, relatively small, low-risk opportunities 
to leverage technology in satisfying a compelling homeland security 
need;

* support operations and maintenance of existing systems that are 
critical to DHS's mission;

* involve deploying an already developed and fully tested system; or: 

* support establishment of a DHS strategic IT management framework, 
including IT strategic planning, enterprise architecture, and 
investment management.

Prior DHS Testimony Has Recognized the Importance of an Enterprise 
Architecture for Departmental Transformation: 

In May 2003,[Footnote 18] the department's CIO testified that 
development of the homeland security enterprise architecture had begun 
in July 2002 and that the department expected to complete the "As Is" 
and "To Be" architectures by June and August 2003, respectively. The 
CIO also stated that the department would develop a migration or 
transition strategy and plan by fall 2003 in order to achieve its 
target environment. Moreover, the CIO testified that DHS had 
coordinated its architecture development efforts with other key federal 
agencies (e.g., the Departments of Justice, Energy, and Defense), the 
intelligence community, and the National Association of State and Local 
CIOs.

In October 2003,[Footnote 19] DHS's CIO testified that the department 
had completed the first version of its target architecture in September 
2003 and was beginning to implement the objectives of its transition 
strategy. The CIO stated that the department had designed and delivered 
a comprehensive and immediately useful business-driven target 
architecture in under 4 months and that the architecture was enabling 
DHS to make IT investment decisions.

OMB's Federal Enterprise Architecture: A Brief Description: 

On February 6, 2002, OMB established the FEA Program Management Office 
and charged it with responsibility for developing the FEA. According to 
OMB, the FEA is intended to provide a governmentwide framework to guide 
and constrain federal agencies' enterprise architectures and IT 
investments and is now being used by agencies to help develop their 
budgets and to set strategic goals. The FEA is composed of five 
reference models: Performance, Business, Service, Data, and Technical. 
To date, versions of all but the data reference model have been 
released for use by the agencies. More information on each reference 
model follows.

Performance reference model. The performance reference model is 
intended to describe a set of performance measures for major IT 
initiatives and their contribution to program performance. According to 
OMB, this model will help agencies produce enhanced performance 
information; improve the alignment and better articulate the 
contribution of inputs, such as technology, to outputs and outcomes; 
and identify improvement opportunities that span traditional 
organizational boundaries. Version 1.0 of the model was released in 
September 2003.

Business reference model. The business reference model serves as the 
foundation for the FEA. It is intended to describe the federal 
government's businesses, independent of the agencies that perform them. 
The model consists of four business areas: (1) services for citizens, 
(2) mode of delivery, (3) support delivery of services, and 
(4) management of government resources.

Thirty-nine lines of business, which together are composed of 153 
subfunctions, make up the four business areas. Examples of lines of 
business under the "services for citizens" business area are homeland 
security, law enforcement, and economic development. Each of these 
lines of business includes a number of subfunctions. For example, for 
the homeland security line of business, a subfunction is border and 
transportation security; for law enforcement, a subfunction is citizen 
protection; and for economic development, a subfunction is financial 
sector oversight.

Version 1.0 of the business reference model was released to agencies in 
July 2002, and OMB reports that it was used in the fiscal year 2004 
budget process. According to OMB, Version 1.0 helped to reveal that 
many federal agencies were involved in each line of business and that 
agencies' proposed IT investments for fiscal year 2004 offered 
multibillion-dollar consolidation opportunities. In June 2003, OMB 
released Version 2.0 which, according to OMB, addresses comments from 
agencies and reflects changes to align the model as closely as possible 
with other governmentwide management frameworks (e.g., budget function 
codes[Footnote 20]) and improvement initiatives (e.g., the President's 
Budget Performance Integration Initiative[Footnote 21]) without 
compromising its intended purpose. OMB expects agencies to use the 
model, as part of their capital planning and investment control 
processes, to help identify opportunities to consolidate IT investments 
across the federal government.

Service component reference model. The service component reference 
model is intended to identify and classify IT service (i.e., 
application) components that support federal agencies and promote the 
reuse of components across agencies. According to OMB, this model is 
intended to provide the foundation for the reuse of applications, 
application capabilities, components (defined as "a self-contained 
business process or service with predetermined functionality that may 
be exposed through a business or technology interface"), and business 
services, and is organized as a hierarchy beginning with seven service 
domains, as shown in table 4.

Table 4: Service Domains, the Capabilities That They Describe, and 
Associated Service Types: 

Service domain: Customer services; 
Description: Interaction between the business and the customer and 
customer-driven activities or functions (directly related to the end 
customer); 
Service types: Customer preferences, customer relationship management, 
and customer-initiated assistance.

Service domain: Process automation services; 
Description: Automation of process and activities that support managing 
the business; 
Service types: Tracking and workflow, and routing and automation.

Service domain: Business management services; 
Description: Management and execution of business functions and 
organizational activities that maintain continuity across the business 
and value chain participants; 
Service types: Management of process, organizational management, supply 
chain management, and investment management.

Service domain: Digital asset services; 
Description: Generation, management, and distribution of intellectual 
capital and electronic media across the business and extended 
enterprise; 
Service types: Content management, knowledge management, document 
management, and records management.

Service domain: Business analytical services; 
Description: Extraction, aggregation, and presentation of information 
to facilitate decision analysis and business evaluation; 
Service types: Analysis and statistics, business intelligence, 
visualization, and reporting.

Service domain: Back office services; 
Description: Management of enterprise planning transactional-based 
functions; 
Service types: Data management, human resources, financial management, 
assets/materials management, development and integration, and human 
capital/workforce management.

Service domain: Support services; 
Description: Cross-functional capabilities that can be leveraged 
independent of service domain objective and mission; 
Service types: Security management, systems management, forms, 
communications, collaboration, and search. 

Source: OMB.

[End of table]

These service domains are decomposed into 29 service types, which 
together are further broken down into 168 components. For example, the 
customer services domain is made up of 3 service types: customer 
relationship management, customer preferences, and customer-initiated 
assistance. Components of the customer relationship management service 
type include call center management and customer analytics; components 
of the customer preferences service type include personalization and 
subscriptions; and components of the customer-initiated assistance 
service type include online help and online tutorials.

Version 1.0 of the service component reference model was released in 
June 2003. According to OMB, the model is a business-driven, functional 
framework that classifies service components with respect to how they 
support business and/or performance objectives. Further, the model is 
structured across horizontal service areas that, independent of the 
business functions, is intended to provide a leverageable foundation 
for the reuse of applications, application capabilities, components, 
and business services.

Data and information reference model. The data and information 
reference model is intended to describe the types of data and 
information that support program and business-line operations and the 
relationships among these types. The model is intended to help describe 
the types of interactions and information exchanges that occur between 
the government and its customers. OMB officials told us that the 
release of Version 1.0 is to occur imminently.

Technical reference model. The technical reference model is intended to 
describe the standards, specifications, and technologies that 
collectively support the secure delivery, exchange, and construction of 
service components. OMB describes the model as being made up of the 
following four core service areas: 

Service access and delivery: the collection of standards and 
specifications that support external access, exchange, and delivery of 
service components.

Service platform and infrastructure: the delivery platforms and 
infrastructure that support the construction, maintenance, and 
availability of a service component or capability.

Component framework: the underlying foundation, technologies, 
standards, and specifications by which service components are built, 
exchanged, and deployed.

Service interface and integration: the collection of technologies, 
methodologies, standards, and specifications that govern how agencies 
will interface internally and externally with a service component.

Each of these service areas is made up of service categories, which 
identify lower levels of technologies, standards, and specifications; 
service standards, which define the standards and technologies that 
support the service category; and the service specification, which 
details the standard specification or the provider of the 
specification. For example, within the first core service area (service 
access and delivery), an example of a service category is access 
channels, and examples of service standards are Web browsers and 
wireless personal digital assistants. Examples of service 
specifications for the Web browser service standard are Internet 
Explorer and Netscape Navigator.

Version 1.0 of the technical reference model was released in January 
2003, followed in August 2003 by Version 1.1, which reflected minor 
revisions that were based, in part, on agencies' comments. Version 1.1 
was used during the 2005 budget process. The model is intended to help 
agencies define their target technical architectures.

In May 2004, we testified[Footnote 22] that, through the FEA, OMB is 
attempting to provide federal agencies and other decision makers with a 
common frame of reference or taxonomy for informing agencies' 
individual enterprise architecture efforts and their planned and 
ongoing investment activities and to do so in a way that, among other 
things, identifies opportunities for avoiding duplication of effort and 
launching initiatives to establish and implement common, reusable, and 
interoperable solutions across agency boundaries. We testified that we 
supported these goals. However, we also recognized that development and 
use of the FEA is but the first step in a multistep process to realize 
the promise of interagency solutions. In addition, because the FEA is 
still maturing both in content and in use, we raised a number of 
questions that we believed OMB needed to address in order to maximize 
understanding about the tool and thus facilitate its advancement. 
Specifically, we asked the following: 

* Should the FEA be described as an enterprise architecture? As we 
discussed earlier, a true enterprise architecture is intended to 
provide a blueprint for optimizing an organization's business 
operations and implementing the IT that supports them. Accordingly, 
well-defined enterprise architectures describe, in meaningful models, 
both the enterprise's "As Is" and "To Be" environments, along with the 
plan for transitioning from the current to the target environment. To 
be meaningful, these models should be inherently consistent with one 
another, in view of the many interrelationships and interdependencies 
among, for example, business functions, the information flows among the 
functions, the security needs of this information, and the services and 
applications that support these functions.

Our reading of the four available reference models does not demonstrate 
to us that this kind of content exists in the FEA and thus we believe 
that it is more akin to a point-in-time framework or classification 
scheme for federal government operations. Accordingly, if agencies use 
the FEA as a model for defining the depth and detail for their own 
architectures, the agencies' enterprise architectures may not provide 
sufficient content for driving the implementation of their systems.

* Is the expected relationship between agencies' enterprise 
architectures and the FEA clearly articulated? Among other things, the 
FEA is to inform agencies' enterprise architectures. For example, OMB 
has stated that although it is not mandating that the business 
reference model serve as the foundation for every agency's business 
architecture, agencies should invest time mapping their respective 
business architectures to the FEA. Similarly, OMB has stated that 
agencies' alignment of their respective architectures to the services 
component reference model and the technical reference model will enable 
each agency to categorize its IT investments according to common 
definitions.

In our view, such descriptions of the agency enterprise architecture/
FEA relationship are not clear, in part because definitions of such key 
terms as alignment, mapping, and consistency are not apparent in the 
FEA. As with any endeavor, the more ambiguity and uncertainty there is 
in requirements and expectations, the greater the use of assumptions; 
the more assumptions that are made, the higher the risk of deviation 
from the intended course of action. This is particularly true in the 
area of enterprise architecture.

* How will the security aspects of the FEA be addressed? Our work has 
found that a well-defined enterprise architecture should include 
explicit discussion of security, including descriptions of security 
policies, procedures, rules, standards, services, and tools.[Footnote 
23] Moreover, security is an element of the very fabric of architecture 
artifacts and models and thus should be woven into them all. As our 
experience in reviewing agency security practices and our research into 
leading practices shows, security cannot be an afterthought when it 
comes to engineering systems or enterprises.[Footnote 24]

OMB has stated that it plans to address security through what it refers 
to as a "security profile" to be added to the FEA. However, OMB could 
not comment on the profile's status or on development plans for it, 
beyond stating that the CIO Council is taking the lead in developing 
the profile.

Initial Version of DHS's Architecture Provides a Partial Foundation 
upon Which to Build, but Not a Sufficient Basis to Guide Investment 
Decisions: 

The initial version of DHS's enterprise architecture is missing many of 
the key elements[Footnote 25] of a well-defined architecture. Further, 
those elements that are in the initial version are not based on the 
department's strategic business plan, as architecture development best 
practices advocate. Instead, the architecture is largely the result of 
combining the architectures and ongoing IT investments that several of 
the 22 agencies brought with them when the department was formed. 
According to DHS senior architecture officials, including the chief 
architect, Version 1.0 was developed in this manner because it pre-
dated completion of the department's first strategic plan, only had 
limited staff assigned to it, and needed to be done in only 4 months in 
order to meet OMB's deadline for submitting the department's fiscal 
year 2004 IT budget. They also stated that this initial version was 
intended to mature the department's approach and methodology for 
developing the next version of the architecture, rather than to develop 
a version of the architecture that could be acted on and implemented. 
As a result, even though Version 1.0 provides a partial foundation upon 
which to build a well-defined architecture, DHS has spent and continues 
to spend large sums of money on IT investments without having such an 
architecture to effectively guide and constrain these investments. Our 
experience with federal agencies has shown that this often results in 
systems that are duplicative, are not well integrated, are 
unnecessarily costly to maintain and interface, and do not effectively 
optimize mission performance.

Initial Version of Architecture Is Missing Important Content: 

As previously discussed, the various frameworks used to develop 
architectures consistently provide for describing a given enterprise in 
both logical and technical terms, and for doing so for both the 
enterprise's current or "As Is" environment and its target or "To Be" 
environment; these frameworks also provide for defining 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 what the architecture is to be used 
for (i.e., its intended purpose).

DHS's stated intention is to use an architecture as the basis for 
departmentwide and national operational transformation and supporting 
systems modernization and evolution. The CIO stated that the department 
was already using the architecture to help guide IT investment 
decisions. This purpose necessitates that the architecture products 
provide considerable depth and detail, as well as logical and rational 
structuring and internal linkages. More specifically, it means that 
these architecture products should contain sufficient scope and detail 
so that, for example, (1) duplicative business operations and systems 
are eliminated; (2) business operations are standardized and integrated 
and supporting systems are interoperable; (3) use of enterprisewide 
services is maximized; and (4) related shared solutions are aligned, 
like OMB's e-government initiatives.[Footnote 26] Moreover, this scope 
and detail should be accomplished in a way that (1) provides 
flexibility in adapting to changes in the enterprise's internal and 
external environments; (2) facilitates the architecture's usefulness 
and comprehension from varying perspectives, users, or stakeholders; 
and (3) provides for properly sequencing investments to recognize, for 
example, the investments' respective dependencies and relative business 
value.

While the initial version of the architecture does provide some content 
that can be used to further develop it, it does not contain sufficient 
breadth and depth of departmentwide operational and technical 
requirements to effectively guide and constrain departmentwide business 
transformation and systems modernization efforts. More specifically, we 
found that DHS's "To Be" architecture products (Version 1.0) do not 
satisfy 14 of 34 (41 percent) key elements and only partially satisfy 
the remaining 20 (59 percent), and that its transition plan only 
partially satisfies 3 of 5 elements (60 percent) and does not satisfy 
the remaining 2 (40 percent) (see fig. 2.). This means that while 
Version 1.0 does provide some of the foundational content that can be 
used to extend and expand the architecture, it does not yet provide an 
adequately defined frame of reference to effectively inform business 
transformation and system acquisition and implementation decision 
making. Our specific analysis of the "To Be" and transition plan 
products follows.

Figure 2: Summary of Extent to Which Version 1.0 Satisfies Key Elements 
Governing Architectural Content: 

[See PDF for image] 

[End of figure] 

"To Be" Architecture: According to relevant guidance,[Footnote 27] a 
"To Be" architecture should capture the vision of future business 
operations and supporting technology. That is, it should describe the 
desired capabilities, structures (e.g., entities, activities, and 
roles), and relationships among these structures at a specified time 
frame in the future. It should also describe, for example, future 
business processes, information needs, and supporting infrastructure 
characteristics, and it should be fiscally and technologically 
achievable. More specifically, a well-defined "To Be" architecture 
should provide, among other things, a description of: 

* the enterprise's business strategy, including its desired future 
concept of operations, its strategic goals and objectives, and the 
strategic direction to be followed to achieve the desired future state;

* future business processes, functions, and activities that will be 
performed to support the organization's mission, including the entities 
that will perform them and the locations where they will be performed;

* a logical database model that identifies the primary data categories 
and their relationships, which are needed to support business processes 
and to guide the creation of the physical databases where information 
will be stored;

* the systems to be acquired or developed and their relative importance 
in supporting the business operations;

* the enterprise application systems and system components and their 
interfaces;

* the policies, procedures, processes, and tools for selecting, 
controlling, and evaluating application systems;

* the technical standards to be implemented and their anticipated life 
cycles;

* the physical infrastructure (e.g., hardware and software) that will 
be needed to support the business systems;

* common policies and procedures for developing infrastructure systems 
throughout their life cycles;

* security and information assurance-related terms;

* the organizations that will be accountable for implementing security 
and the tools to be used to secure and protect systems and data;

* a list of the protection mechanisms (e.g., firewalls and intrusion 
detection software) that will be implemented to secure the department's 
assets; and: 

* the metrics that will be used to evaluate the effectiveness of 
mission operations and supporting system performance in achieving 
mission goals and objectives.

Architectures that include these elements can provide the necessary 
frame of reference to enable the engineering of business solutions 
(processes and systems) in a manner that optimally supports 
departmentwide goals and objectives, such as information sharing.

Version 1.0 of the department's "To Be" architecture provides some of 
the descriptive content mentioned above. For example, it contains (1) a 
high-level business strategy that includes a vision statement and a 
list of projects that may become future technology solutions; (2) a 
list of systems to be acquired or developed; (3) a description of the 
enterprise application systems and system components; (4) the technical 
standards to be implemented; (5) a description of the physical 
infrastructure (e.g., hardware and software) that will be needed to 
support the business systems; (6) definitions of security and 
information assurance-related terms; (7) a list of protection 
mechanisms, such as firewalls; and (8) high-level performance metrics.

However, the business strategy does not define the desired future 
concept of operations, the business-specific objectives to be achieved, 
and the strategic direction to be followed. Such content is important 
because the "To Be" architecture must be based on and driven by 
business needs. In contrast to this, the DHS "To Be" architecture is 
primarily focused on how to employ technology to improve current 
mission operations and services, instead of on identifying and 
addressing needed business changes through the use of technology. In 
addition, the systems listed are not described in terms of their 
relative importance to achieving the department's vision based on 
business value and technical performance, and the application systems 
and system components are not linked to the specific business processes 
they will support. Further, the technical standards are incomplete 
(e.g., do not specify standards that support narrowband wireless 
access) and do not include the anticipated life cycle of each standard. 
The physical infrastructure description is too high level (e.g., it 
does not define networks and their configurations or relate the 
technology platforms to specific applications and business functions). 
The architecture also does not define certain security and information 
assurance-related terms (e.g., security services) and, in some 
instances, it defines other terms (e.g., authentication and 
availability) differently than do the department's homeland security 
partners. For example, DHS's definitions of authentication, 
availability, confidentiality, and integrity differ from DOD's 
definitions of these terms. In addition, the list of protection 
mechanisms is neither complete, nor does it describe all of the 
mechanisms shown and the interrelationships among them.

Other key elements that are not included are (1) a description of 
future business processes, functions, and activities that will be 
performed to support the organization's mission, including the entities 
or people that will perform them and the locations where they will be 
performed; (2) a logical database model; (3) the policies, procedures, 
processes, and tools for selecting, controlling, and evaluating 
application systems; (4) common policies and procedures for developing 
infrastructure systems throughout their life cycles; (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) explicit metrics for the department's primary (e.g., identifying 
threats and vulnerabilities and facilitating the flow of people and 
goods) and mission-support (e.g., human resources and budget and 
finance) business areas. Detailed results of our analysis are provided 
in appendix II.

Transition Plan: According to relevant guidance and best 
practices,[Footnote 28] the transition plan should provide a temporal 
road map 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--a comparison of the "As Is" and "To Be" architectures 
to identify differences. Other important steps include analyses of 
technology opportunities and marketplace 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 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, and they do so in light 
of resource constraints such as budget, people, acquisition/development 
process maturity, and associated time frames.

Version 1.0 of DHS's transition plan generally does not possess any of 
these attributes. Specifically, it does not (1) include a gap analysis 
identifying the needed changes to current business processes and 
systems; (2) identify the legacy systems that will not become part of 
the "To Be" architecture or the time frames for phasing them out; 
(3) show a time-based strategy for replacing legacy systems, including 
identifying intermediate (i.e., migration) systems that may be 
temporarily needed; or (4) define the resources (e.g., funding and 
staff) needed to transition to the target environment. The result is 
that DHS does not have a meaningful and reliable basis for managing the 
disposition of its legacy systems or for sequencing the introduction of 
modernized business operations and supporting systems. Detailed results 
of our analysis are in appendix III.

A DHS contractor responsible for evaluating the quality of Version 1.0 
reported weaknesses that are similar to ones that we identified. For 
example, the contractor reported the following: 

* The "To Be" architecture did not address the reality that the 
department's systems would be a federated combination of legacy and new 
systems for many years. Rather, it assumes that its systems will be 
transformed into an ideal future state in the near term.

* The "To Be" architecture did not consistently address topics at the 
same level of detail, and it contained inconsistencies (i.e., some 
topics were addressed in more detail than others).

* The architecture did not sufficiently address security (i.e., 
network, data, physical, and information).

DHS's senior enterprise architecture officials, including the chief 
architect, agreed with the results of our analysis and stated that 
considerable work remained to adequately address all of the key 
architectural elements. According to the CIO and these officials, this 
initial version was prepared in 4 months, with limited resources (i.e., 
three DHS staff and minimal contractor support), based on the 
information available at that time. Further, it was prepared primarily 
to meet OMB's fiscal year 2004 IT budget submission deadline and to 
help educate DHS's senior executives about the importance of this 
architecture in the department's overall transformation effort. Senior 
architecture officials also stated that a transition plan was not 
intended to be part of the scope of Version 1.0, and that the 
department's initial focus was on maturing its ability to execute an 
approach and methodology for developing the next version of the 
architecture.

Notwithstanding these reasons, constraints, and intentions, the fact 
remains that Version 1.0 is missing important content and, without this 
content, the department--as well as homeland security stakeholders in 
other federal agencies, state and local governments, and the private 
sector--will not have the sufficiently detailed, authoritative frame of 
reference that is needed to provide a common understanding of future 
homeland security operational, business, and supporting technology 
needs. Such a frame of reference is important to effectively guide and 
constrain the transformation of mission operations, business functions, 
and associated IT investments. Without it, DHS and other homeland 
security stakeholders will be challenged in their ability to 
effectively leverage technology to affect the kind of logical and 
systematic institutional change needed to optimize enterprisewide 
mission performance.

Content of Initial Architecture Is Based on Strategic Business 
Assumptions and Existing Agencies' Architectures Rather Than 
Departmental Strategic Vision: 

The various architecture frameworks and architecture management best 
practices recognize the need to define the "To Be" environment using a 
top-down, business-driven approach in which the content of the 
organization's strategic plan (mission, goals, objectives, scope, and 
outcomes) drives operational processes, functions, activities, and 
associated information needs, which in turn drive system application 
and services and supporting technology standards. The architecture 
development methodology[Footnote 29] being employed by DHS also calls 
for this top-down, mission-and business-driven approach, which engages 
mission and business area subject matter experts. It specifically 
states that an architecture should be based on a functional business 
model that reflects the nature of the operational mission, the business 
strategy, and the information to be used to accomplish them.

DHS did not follow this approach in developing Version 1.0 of its 
architecture, primarily because the department did not issue a 
strategic plan until February 2004. Specifically, the department 
released its initial architecture in September 2003, approximately 5 
months before it issued its strategic plan. Without an explicit 
strategic direction to inform the architecture, the architecture's 
business representation was derived from the existing architectures and 
the ongoing and planned IT investments of some of its component 
agencies (i.e., Immigration and Naturalization Service, Customs and 
Border Protection, Coast Guard, and the Federal Emergency Management 
Agency). As a result, Version 1.0 did not contain a departmentwide and 
national corporate business strategy that described such things as 
(1) the desired future state of its mission operations and business 
activities, (2) the specific goals and objectives to be strategically 
achieved, and (3) the strategic direction to be followed by the 
department to realize the desired future state. Rather, the 
architecture's strategic operational and business content is basically 
the sum of its component agencies' business strategy parts. Moreover, 
although the department is using generally accepted architecture 
development techniques, the architecture artifacts that have been 
derived using these techniques (i.e., the value chain 
analysis,[Footnote 30] CURE matrix,[Footnote 31] conceptual data model, 
and sequencing diagram) do not provide a consistent view of the scope 
of the department's mission. In some instances, the vision focuses 
internally on departmental activities only, while in other instances, 
it focuses on homeland security at a national level (i.e., addresses 
other homeland security stakeholders, such as other federal agencies 
and state and local government). The architecture's business strategy 
also does not identify corporate priorities and constraints to be 
considered when making departmentwide and national decisions about 
future homeland security activities. The DHS contractor responsible for 
evaluating the quality of Version 1.0 made similar comments concerning 
the architecture's business strategy. Specifically, the contractor 
reported that the scope of the architecture was unclear, at times being 
internally focused on only the department, while at other times being 
more broadly focused on national homeland security. Further, the 
contractor reported that the business strategy did not include all DHS 
mission activities.

According to the chief architect, the fiscal year 2004 IT budget 
submission deadline did not allow the department to delay development 
of the architecture until the strategic plan had been completed. A 
senior architecture official also stated that this time constraint 
(i.e., 4-month development period) did not allow subject matter experts 
(i.e., both internal and external DHS stakeholders) to be consulted and 
to participate in developing Version 1.0. According to the CIO, subject 
matter experts are now participating in the department's architecture 
development activities.

As stated above, having a mission-and business-driven enterprise 
architecture is a fundamental principle. Until the department uses an 
enterprisewide understanding of its mission operations and business as 
the basis for developing its architecture, its architecture's utility 
will be greatly diminished, and it is unlikely that changes to existing 
operations and systems that are based on this architecture will provide 
for optimization of mission performance and satisfaction of stakeholder 
needs. Moreover, because DHS did not base Version 1.0 on such an 
understanding, the content of this version may prove to be invalid if 
future work shows that the strategic business assumptions used to 
develop it were inaccurate. This in turn would limit the value of 
Version 1.0 as a basis for building the next version.

Initial Architecture Can Be Partially Traced to the Federal Enterprise 
Architecture, but the Extent of Alignment Is Unclear: 

OMB guidance does not explicitly require agency enterprise 
architectures to align with the FEA. However, a requirement for 
alignment is implicit in the OMB guidance. For example, this guidance 
states that agencies' major IT investments must align with each of the 
FEA's published reference models (business, performance, services, and 
technical), and that agencies' nonmajor IT investments must align with 
the business reference model.[Footnote 32] Since an agency's enterprise 
architecture is to include a transition plan that strategically 
sequences its planned IT investments in a way that moves the agency 
from its current architectural environment to its target environment, 
this means that the agency's investments would need to align with both 
the FEA and the agency enterprise architecture, which in turn would 
necessitate alignment between the FEA and the agency architecture. 
Aligning agencies' architectures with the FEA is also an implied 
requirement in recently released OMB guidance for its enterprise 
architecture assessment tool.[Footnote 33] According to this guidance, 
agency enterprise architectures are "a basic building block to support 
the population of the FEA." Further, OMB states that one of the 
purposes of the FEA is to inform agency efforts to develop their 
agency-specific enterprise architectures.

We have previously reported that OMB's expected relationship between 
the FEA and agency enterprise architectures has not been clearly 
articulated, in part because OMB has not defined key terms, such as 
architectural alignment.[Footnote 34] In the absence of clear 
definitions, we also reported that assumptions must be made about what 
alignment means, and that the greater the use of assumptions, the 
greater the chances of expectations about these relationships not being 
met and intended outcomes not being realized. For the purposes of this 
report, we have assumed that alignment can be examined from three 
perspectives: functional, structural, and semantic. Functional 
alignment means that the architecture and the reference models have 
been decomposed to the same level of detail to determine if the 
business operations, services, and technology components are similar in 
nature and purpose. Structural alignment means that the architecture 
and the reference models are both constructed similarly, for example, 
they may share the same hierarchical construct whereby information is 
grouped by common levels of detail. Semantic alignment means that the 
department's architecture and the FEA reference models use similar 
terms and/or definitions that can be mapped to one another.

The FEA and Version 1.0 of DHS's enterprise architecture are not 
aligned functionally or structurally. Specifically, we could not map 
Version 1.0 to the FEA from either of these perspectives because the 
DHS architecture is not decomposed to the same level of detail as the 
reference models and thus does not permit association of the respective 
functional components and because the DHS architecture is not 
structured in a hierarchical fashion as the reference models are.

However, the terms or definitions used in the business, services, and 
technical components of Version 1.0 could be mapped to similar terms in 
the FEA business, services, and technical reference models. The results 
of this mapping are discussed below.

* We mapped all 79 of the high-level activities that we found in the 
business view of the DHS architecture to similar terms in the FEA 
business reference model. To achieve this degree of mapping, however, 
we needed to trace the 79 high-level activities to multiple levels of 
the reference models, including business areas, lines of business, and 
subfunctions. For example, for the DHS high-level business activity 
"stockpile and deploy supplies" (defined as including managing 
immunizations, as well as identification, acquisition, development, 
maintenance, and distribution of other pharmaceutical and medical 
supplies) we needed to go to the reference model's subfunction level to 
find "immunization management." In addition, we were not able to map 
any terms in the DHS architecture to several areas in the business 
reference model that would appear relevant to DHS, such as the business 
area "mode of delivery" or the line of business "defense and national 
security." 

* We also mapped Version 1.0's applications/services view to the FEA 
services reference model. In this case, the initial architecture 
contained terms that could be associated with all of the FEA reference 
model's 7 service domains, 29 service types, and 168 service 
components.

* We also mapped terms used for technical services in the Version 1.0 
technical view to the FEA technical reference model. However, this 
mapping was again based on associating high-level descriptions in 
Version 1.0 with lower-level descriptions in the FEA. Moreover, some 
terms for technology elements in Version 1.0 could not be mapped to the 
FEA technical reference model, such as "narrowband wireless and 
broadband wireless." Conversely, some technical services and standards 
in the reference model that should be applicable to DHS were not 
evident in Version 1.0, such as software engineering (including test 
management services) and database middleware standards, respectively. 
In those instances where we could not semantically associate 
Version 1.0 to the FEA reference models, we found no associated 
explanations. As a result, we could not determine whether future 
alignment is envisioned or not.

According to the CIO and the chief architect, the steps that DHS took 
to align the initial architecture with the FEA reference models 
represent the most that could be done in the time available. The 
architect also stated that changes would be made to the technical views 
of the architecture to more closely reflect the content within the 
FEA's technical reference model. However, given that what is meant by 
agency architectural alignment to the FEA is not well defined, the 
degree to which DHS and other agencies can establish the intended 
relationship between the two is both challenging and uncertain. This in 
turn will constrain OMB's ability to meet the goals it has set for the 
FEA.

Conclusions: 

Having and using an enterprise architecture that reflects the 
department's strategic operational and business needs and enables it to 
make informed decisions about competing investment options is critical 
to DHS's business transformation and supporting system modernization 
efforts. DHS recognizes this and has produced an initial architecture 
in a short time with limited resources and is working on its next 
version. Nevertheless, the department is in the midst of transforming 
itself and investing hundreds of millions of dollars in supporting 
systems without a well-defined architecture to effectively guide and 
constrain these activities. Following this approach is a risky 
proposition, and the longer DHS goes without a well-defined and 
enforced architecture the greater the risk. Therefore, it is important 
that DHS ensure that the next version is based on a top-down, strategic 
business-based approach that involves key stakeholders, as advocated by 
best practices. It is also important for DHS to ensure that its 
architecture includes the necessary content. Until this is done, it 
will be prudent for the department to limit new system investments to 
those meeting certain criteria, as we have previously recommended. To 
do less puts the department at risk of investing hundreds of millions 
of dollars in efforts that will not promote integration and 
interoperability and will not optimize mission performance.

Further, the relationships that OMB expects between the FEA and agency 
architectures, including DHS's are not clear. Until OMB clarifies what 
it means by architectural alignment, it is unlikely that the outcomes 
it envisions and desires through architectural alignment will result.

Recommendations for Executive Action: 

To ensure that DHS has a well-defined architecture to guide and 
constrain pressing transformation and modernization decisions, we 
recommend that the Secretary of Homeland Security direct the 
department's architecture executive steering committee, in 
collaboration with the CIO, to (1) ensure that the development of DHS's 
enterprise architecture is based on an approach and methodology that 
provides for identifying the range of mission operations and the focus 
of the business strategy and involving relevant stakeholders (external 
and internal) in driving the architecture's scope and content; and 
(2) develop, approve, and fund a plan for incorporating into the 
architecture the content that is missing.

In addition, we are recommending 39 actions to ensure that future 
versions of the architecture include (1) the six key elements governing 
the business view of the "To Be" architectural content that our report 
identified as not being fully satisfied, (2) the three key elements 
governing the performance view of the "To Be" architectural content 
that our report identified as not being fully satisfied, (3) the seven 
key elements governing the information view of the "To Be" 
architectural content that our report identified as not being fully 
satisfied, (4) the five key elements governing the services/
applications view of the "To Be" architectural content that our report 
identified as not being fully satisfied, (5) the six key elements 
governing the technical view of the "To Be" architectural content that 
our report identified as not being fully satisfied, (6) the seven key 
elements governing the security view of the "To Be" architectural 
content that our report identified as not being fully satisfied, and 
(7) the five key elements governing the transition plan content that 
our report identified as not being fully satisfied.

In addition, to assist DHS and other agencies in developing and 
evolving their respective architectures, we recommend that the Director 
of OMB direct the FEA Program Management Office to clarify the expected 
relationship between the FEA and federal agencies' architectures. At a 
minimum, this clarification should define key terms, such as 
architectural alignment.

Agency Comments and Our Evaluation: 

In DHS's written comments on a draft of this report, signed by the 
Director, Bankcard Programs and GAO/OIG Liaison within the Office of 
the Chief Financial Officer (reprinted in app. IV), the department 
agreed that much work remains to develop both a target enterprise 
architecture and a transition plan to support business and IT 
transformation, and it stated that it would ensure that the 
architecture criteria that we cite in our report, which our 
recommendations reference, are addressed to the extent possible in 
Version 2.0 of its architecture. Notwithstanding these statements, the 
department also stated that it took exception to several aspects of our 
report, including our criteria and recommendations. In particular, it 
stated that (1) the criteria were not realistic and assumed the 
existence of a comprehensive enterprise architecture, the development 
of which was inconceivable in the time available, (2) the criteria had 
not been provided to the federal community and were not available when 
Version 1.0 of DHS's architecture was being developed, and (3) the 
recommendations did not take into consideration the department's 
limited resources. DHS stated that it had accomplished one of the most 
important goals of Version 1.0, which was "positioning the department 
to more actively engage with our business representatives, with a 
strategic plan in hand and a greater awareness of the need for and 
value of an enterprise architecture generally on the part of our senior 
and executive management." DHS also provided specific comments on our 
findings relative to each criterion that we assessed Version 1.0 
against. These comments fell into two general categories: agree that 
content is missing but content was not intended to be part of 
Version 1.0, and do not agree that content is missing (i.e., factually 
incorrect).

We do not agree with the department's comments concerning the criteria 
and our recommendations. In particular, our report does not state that 
DHS should have ensured that Version 1.0 of its enterprise architecture 
satisfied all of the criteria that we cite. We have long held and 
reported the position that enterprise architecture development should 
be done incrementally,[Footnote 35] with each version of an 
architecture providing greater depth and detail to an enterprisewide, 
business-driven foundational layer. We provide in the report an 
analytical assessment of where Version 1.0 stands against a benchmark 
of where it will need to be in order to be an effective blueprint to 
guide and constrain major investment decisions for organizational 
transformation. In doing so, we have provided the department with a 
road map, grounded in explicit criteria, for incrementally developing a 
mission-derived blueprint.

In addition, the criteria that we used in our review and cite in our 
report came from published literature on the content of enterprise 
architectures, which we structured into categories consistent with 
federal enterprise architecture guidance and have used in prior 
evaluations of other agencies' enterprise architectures, the results of 
the first of which we issued in September 2003.[Footnote 36] We shared 
these criteria and categories with DHS at the time that we began our 
review, and we shared the results of our review relative to each 
criterion with DHS enterprise architecture program and contractor 
officials over a 2-day period after we completed our review. At that 
time, both the DHS and the contractor officials agreed with our 
results. While we acknowledge that we had yet to publish our 
categorization of the criteria at the time that Version 1.0 of DHS's 
architecture was being developed, the criteria that we drew from and 
used were both well established and publicly available.

In addition, we recognize in both the report and its recommendations 
the point made in DHS's comments about the initial architecture 
development effort being constrained by resources. It is because of 
this that our recommendations call for DHS's architecture executive 
steering committee, which is composed of those department business and 
technology executives who collectively control billions of dollars in 
resources, to develop, approve, and fund a plan for completing the 
architecture. In our view, the resource point cited in DHS's comments 
is a departmental funding allocation and prioritization decision, 
rather than a resource shortage issue.

Also, we do not question the department's comment concerning the intent 
and goal of Version 1.0, or whether its goal has been accomplished. 
Rather, the purpose and scope of our work was to determine the extent 
to which the initial architecture version contained the building blocks 
of a well-defined blueprint and to thereby identify what, if anything, 
remained to be accomplished. If more needed to be done, our objective 
was to determine whether the initial version provided a foundation upon 
which to build any missing content. As we previously stated, 
development of a well-defined enterprise architecture is by necessity 
incremental, and our report is intended to provide DHS with a criteria-
based road map for incrementally accomplishing this. To avoid any 
misunderstanding about the need to develop the architecture 
incrementally, we have added further detail on this topic to this 
report.

With respect to DHS's specific comments on each of the findings and 
recommendations that acknowledged missing content, we support the 
department's statements indicating that it will address this missing 
content in the next or subsequent versions of the architecture. 
However, we do not agree with DHS's comments when it stated that our 
findings were factually incorrect or when it disagreed with the 
criteria. Our responses to DHS's comments for each of these areas of 
disagreement are provided in appendix IV.

In their oral comments on a draft of this report, OMB's Office of 
E-Government and Information Technology and the Office of General 
Counsel officials stated that OMB's Administrator for Electronic 
Government, Information and Technology had recently testified that 
additional work was needed to mature the FEA. In addition, the 
officials stated that OMB is committed to working to evolve the FEA and 
agency enterprise architectures, and that this work will clarify many 
of the issues raised in our report.

As agreed with your office, unless you publicly announce the contents 
of this report earlier, we plan no further distribution until 30 days 
from the report date. At that time, we will send copies of this report 
to the Secretary of Homeland Security and to the Director of OMB. We 
will also make copies available to others upon request. In addition, 
the report will be: 

available at no charge on the GAO Web site at [Hyperlink, 
http://www.gao.gov]. If you have any questions on matters discussed in 
this report, please contact me at (202) 512-3439 or 
[Hyperlink, hiter@gao.gov]. Key contributors to this report are 
acknowledged in appendix V.

Sincerely yours,

Signed by: 

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

[End of section]

Appendixes: 

Appendix I: Objectives, Scope, and Methodology: 

Our objectives were to determine whether the initial version of the 
Department of Homeland Security's (DHS) enterprise architecture 
(1) provides a foundation upon which to build and (2) is aligned with 
the Federal Enterprise Architecture (FEA).

To address the first objective, we followed the approach that we have 
previously used to evaluate the content of an agency's enterprise 
architecture.[Footnote 37] Specifically, we first segmented 
Version 1.0 of the architecture into the three primary component parts 
of any architecture: the "As Is," the "To Be," and the transition plan. 
We then further divided the "As Is" and "To Be" architectures into five 
architectural components similar to the Office of Management and 
Budget's (OMB) architecture reference models and defined in our 
enterprise architecture maturity framework: 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 its relevance to the other five 
architectural components.[Footnote 38] Because the department is 
currently investing about $4.1 billion in fiscal year 2004 for IT 
systems and supporting infrastructure, we focused our evaluation on the 
"To Be" architecture and the transition plan and did not analyze 
whether DHS's "As Is" architecture satisfied relevant "As Is" guidance. 
For each of these six architectural components, we used the key 
architectural requirements that we previously reported as necessary for 
a well-defined "To Be" architecture.[Footnote 39] We also used the key 
architectural requirements that we previously reported as necessary for 
a well-defined transition plan.[Footnote 40] We then compared the 
"To Be" architecture and transition plan (Version 1.0) against the key 
elements. In doing so, we used the following criteria to determine 
whether the key element was fully,[Footnote 41] partially,[Footnote 42] 
or not satisfied.[Footnote 43]

To assess the extent to which the architecture was aligned with the 
FEA, we compared the "To Be" architecture with the FEA business, 
services-and technical reference models, Versions 2.0, 1.0, and 1.1, 
respectively. We did not select the performance, information/
data,[Footnote 44] and security models[Footnote 45] because department 
officials told us that these models were not part of the scope of their 
effort in developing Version 1.0. We, therefore, focused on the 
business, services, and technical models and attempted to map the 
architecture and FEA reference models at three levels: semantic, 
functional, and structural.[Footnote 46] However, we were unable to do 
so from a functional or structural standpoint because the DHS 
architecture was neither decomposed to the same level of detail, nor 
constructed in a hierarchical fashion like the reference models. We 
therefore mapped key elements of the DHS architecture (e.g., business 
activities, target applications, and services) to the reference models 
by identifying similar terms and/or definitions. To augment our 
documentation reviews and analyses of the architecture, we also 
interviewed various officials, including the chief information officer 
and chief architect to determine, among other things, these officials' 
comments on our detailed analysis.

We also met with OMB officials to discuss its process for reviewing 
agencies' enterprise architectures and the results of its review of 
DHS's architecture. According to OMB officials, its review of DHS's 
architecture is still ongoing and thus we were not provided a copy of 
the review results.

We conducted our work at DHS headquarters in Washington, D.C. We 
performed our work from November 2003 to May 2004 in accordance with 
generally accepted government auditing standards.

[End of section]

Appendix II: Detailed Results of GAO's Analyses of Version 1.0 of DHS's 
"To Be" Architecture: 

Business: Key architectural element: A business assessment[A] that 
includes the enterprise's purpose, scope (e.g., organizations, business 
areas, and internal and external stakeholders' concerns), limitations 
or assumptions, and methods;

A gap analysis[B] that describes the target outcomes and shortfalls, 
including strategic business issues, conclusions reached as a result of 
the analysis (e.g., missing capabilities), causal information, and 
rationales;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not contain a 
business assessment or gap analysis results;

However, the architecture recognizes the need to perform a business 
assessment and project-specific gap analyses. It also identifies 
possible concerns (e.g., inefficiencies in business function and 
technology) that may be addressed by the department.

Business: Key architectural element: A business strategy that describes 
the desired future state of the business, the specific objectives to be 
achieved, and the strategic direction that will be followed by the 
enterprise to realize the desired future state;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not have a 
business strategy that adequately describes the desired future state of 
the business, the objectives to be achieved, and the strategic 
direction to be followed.

Business: Key architectural element: The business strategy should 
include:

Element satisfied? Explanation of partially satisfied: However, the 
architecture does address to a limited degree the characteristics of a 
business strategy, as discussed below.

Business: Key architectural element: * A vision statement that 
describes the business areas requiring strategic attention based on the 
gap analysis;

Element satisfied? Explanation of partially satisfied: The architecture 
does contain a vision statement; however, this statement does not 
highlight opportunities for strategic change to business processes, nor 
does it present a consistent view of the national responsibilities for 
homeland security at the various levels (i.e., federal, state, local, 
and international).

Business: Key architectural element: * A description of the business 
priorities and constraints, including their relationships to, at a 
minimum, applicable laws and regulations, executive orders, 
departmental policy, procedures, guidance, and audit reports;

Element satisfied? Explanation of partially satisfied: The architecture 
recognizes that homeland security processes, procedures, and decisions 
about IT management should comply with applicable laws, regulations, 
and guidance, particularly those associated with privacy requirements. 
The architecture also specifically mentions the National Strategy for 
Homeland Security. However, the architecture does not explicitly 
identify, reconcile, prioritize, or align the applicable laws, 
regulations, and guidance. As a result, business priorities and 
constraints are not identified.

Business: Key architectural element: * A description of the scope of 
business change that is to occur to address identified gaps and realize 
the future desired business state. The scope of change, at a minimum, 
should identify expected changes to strategic goals, customers, 
suppliers, services, locations, and capabilities;

Element satisfied? Explanation of partially satisfied: The architecture 
does not explicitly identify what will be changed in the "As Is" 
environment. It also does not explicitly identify key customers, 
suppliers, products, services, locations, and capabilities for homeland 
security at the national level.

Business: Key architectural element: * A description of the measurable 
strategic business objectives to be met to achieve the desired change;

Element satisfied? Explanation of partially satisfied: The architecture 
does not describe measurable strategic business objectives; however, it 
does contain objectives in the transition strategy that may be used to 
develop strategic business objectives.

Business: Key architectural element: * A description of the measurable 
tactical business goals to be met to achieve the strategic objectives;

Element satisfied? Explanation of partially satisfied: The architecture 
does not describe measurable tactical business goals; however, it does 
describe some high-level performance measures for several of its 
business areas.

Business: Key architectural element: * A listing of opportunities to 
unify and simplify systems or processes across the department, 
including their relationships to solutions that align with the 
strategic initiatives to be implemented to achieve strategic objectives 
and tactical goals;

Element satisfied? Explanation of partially satisfied: The architecture 
does not align all opportunities for change with strategic initiatives 
and potential investments. However, the architecture does identify 
conceptual[C] projects and opportunities to address inefficiencies in 
systems and processes.

Business: Key architectural element: Common (standard and 
departmentwide) policies, procedures, and business and operational 
rules for consistent implementation of the architecture;

Element satisfied? No.

Business: Key architectural element: A description of key business 
processes and how they support the department's mission, including the 
organizational units responsible for performing the business processes 
and the locations where the business processes will be performed. This 
description should provide for the consistent alignment of (1) 
applicable federal laws, regulations, and guidance; (2) department 
policies, procedures, and guidance; (3) operational activities; (4) 
organizational roles; and (5) operational events and information;

Element satisfied? No.

Business: Key architectural element: A description of the operational 
management processes to ensure that the department's business 
transformation effort remains compliant with the business rules for 
fault, performance, security, configuration, and account management;

Element satisfied? No.

Business: Key architectural element: A description of the 
organizational approach (processes and organizational structure) for 
communications and interactions among business lines and program areas 
for (1) management reporting, (2) operational functions, and (3) 
architecture development and use (i.e., how to develop the architecture 
description, implement the architecture, and govern/manage the 
development and implementation of the architecture);

Element satisfied? No.

Performance: Key architectural element: A description of the processes 
for establishing, measuring, tracking, evaluating, and predicting 
business performance regarding business functions, baseline data, and 
service levels;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not describe 
these processes;

However, the architecture recognizes the need for such processes and 
identifies a conceptual project and a business activity that will be 
used to establish these processes.

Performance: Key architectural element: A description of measurable 
business goals and outcomes for business products and services, 
including strategic and tactical objectives;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not describe 
explicit measurable business goals and outcomes for any of the 
department's primary and secondary business areas (e.g., identify 
threats and vulnerabilities; and prevent, prepare and recover from 
incidents);

However, the architecture does provide a description of customer-
focused, measurable business goals and outcomes (e.g., the average time 
taken to resolve customer inquiries) for all of the department's 
primary and secondary business areas (e.g., human resources and budget 
and finance), with one exception (i.e., the architecture does not 
contain customer-focused, measurable goals and outcomes for the primary 
line of business entitled "facilitate the flow of people and goods").

Performance: Key architectural element: A description of measurable 
technical goals and outcomes for managing technology products and 
services for the "To Be" architecture that enables the achievement of 
business goals and outcomes;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not contain 
measurable technical goals and outcomes for managing technology 
products and services that enables the achievement of business goals 
and outcomes (e.g., identifying threats and preventing terrorist 
attacks);

However, the architecture does contain performance measures for 
managing technology (e.g., percentage of data or information shared 
across organizational units and time to produce, create, and deliver 
products or services). The architecture also lists conceptual projects 
focused on improving technology management performance with respect to 
information sharing (e.g., infrastructure consolidation).

Information/data: Key architectural element: A description of data 
management policies, procedures, processes, and tools (e.g., CURE 
matrix[D] ) for analyzing, designing, building, and maintaining 
databases in an enterprise architected environment;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not describe 
or reference enterprise data management policies, procedures, or 
processes;

However, the architecture does contain a CURE matrix. The utility of 
this CURE matrix for planning purposes is questionable because the 
relationships among business functions and applications are ambiguous-
-not uniquely identified or defined.

Information/data: Key architectural element: A description of the 
business and operational rules[E] for data standardization to ensure 
data consistency, integrity, and accuracy, such as business and 
security rules that govern access to, maintenance of, and use of data;

Element satisfied? No.

Information/data: 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 does not contain a 
data dictionary;

However, the architecture does contain an information dictionary that, 
while incomplete, does identify some data objects (e.g., cargo, 
incident, and weapon). As a result, this information glossary could be 
used to facilitate the creation of a data dictionary.

Information/data: Key architectural element: A conceptual data model 
that describes the fundamental things/objects (e.g., business or 
tourist visas, shipping manifests) that make up the business, without 
regard for how they will be physically stored. A conceptual data model 
contains the content needed to derive facts about the business and to 
facilitate the creation of business rules. It represents the 
consolidated structure of business objects to be used by business 
applications;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not provide a 
conceptual data model that contains the content needed to derive facts 
about the business and to facilitate the creation of business rules to 
build databases. The content is at such a high level (e.g., labels and 
terms) that it can be interpreted in numerous ways;

However, the architecture does provide a high-level conceptual data 
model that identifies "super-classes" or groupings of objects without 
the required business context, such as (1) the complete definitions for 
information categories or classes and (2) concrete business objects. 
This information can be used to build the conceptual data model.

Information/data: Key architectural element: A logical database model 
that provides (1) a normalized (i.e., nonredundant) data structure that 
supports information flows and (2) the basis for developing the schemas 
for designing, building, and maintaining physical databases;

Element satisfied? No.

Information/data: Key architectural element: A metadata[F] model that 
specifies the rules and standards for representing data (e.g., data 
formats) and accessing information (e.g., data protocols) according to 
a documented business context that is complete, consistent, and 
practical;

Element satisfied? No.

Information/data: Key architectural element: A description of the 
information flows and relationships among organizational units, 
business operations, and system elements;

Element satisfied? No.

Services/applications: Key architectural element: A description of the 
services and their relationships to key end-user services to be 
provided by the application systems;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not specify 
all the end-user services to be provided by application systems (e.g., 
the use of e-mail as an end-user service for various applications), nor 
does it provide a rationale for this exclusion. It also does not 
specify the various relationships between the end-user services and the 
entities that will provide these services;

The architecture also contains inconsistencies in the descriptions of 
the relationships between user services and application systems, which 
affect its utility. For example, in one instance, the architecture 
notes that correspondence management may involve "maintaining logs and 
references to pieces of correspondence that are of interest to the 
enterprise for tracking purposes and that these pieces of 
correspondence may be e-mails, paper letters, phone conversations, 
etc." In another instance, the architecture does not recognize the use 
of this e-mail service for managing correspondence;

However, the architecture does contain high-level descriptions of the 
types of application systems that will be needed (e.g., a financial 
management application that can manage all financial aspects of general 
accounting, budgeting, capital assets, and investment control). It also 
notes that "To Be" applications will be derived and created based on 
how each user class uses data while performing business activities.

Services/applications: Key architectural element: A list of application 
systems (acquisition/ development and production portfolio) and their 
relative importance to achieving the department's vision, based on 
business value and technical performance;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not identify 
the applications' relative importance to the overall vision. For 
example, it does not explicitly identify and describe application 
systems that support functionality across organizational boundaries 
(e.g., local, state, and federal agencies). In addition, priorities are 
not explicitly defined for the target applications;

However, the architecture provides a list of the types of candidate 
applications (e.g., financial, grant, and property management) and 
links these application types to business functions by providing an 
application-to-function cross-reference matrix;

In addition, it identifies conceptual projects that may provide target 
capabilities or applications and it prioritizes these projects 
according to scheduled completion times. For example, some conceptual 
projects are placed within a category labeled "Rationalize," which 
means they are scheduled for completion within 6 months.

Services/applications: Key architectural element: A description of the 
policies, procedures, processes, and tools for selecting, controlling, 
and evaluating application systems to enable effective IT investment 
management;

Element satisfied? No.

Services/applications: Key architectural element: A description of the 
enterprise application systems and system components and their 
interfaces;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not describe 
applications in terms of the business process flows that each 
application will support (e.g., how to identify and report threats and 
vulnerabilities), nor does the architecture describe the business 
process flows. The architecture also does not reflect how application 
selection decisions can or will be made without this information. 
Further, it does not identify human/ machine boundaries, inputs, 
outputs, controls, and standard application programming interfaces;

However, the architecture contains a list and graphic depictions of the 
types of application systems that would satisfy the department's 
business needs, including a brief description of the functionality to 
be provided by these systems. For example, it describes a generic 
"financial management" application that could be satisfied by many 
application packages or development components.

Services/applications: Key architectural element: A description of the 
system development life cycle process for application development or 
acquisition and the integration of the process with the architecture, 
including policies, procedures, and architectural techniques and 
methods for acquiring systems throughout their life cycles. The common 
technical approach should also describe the process for integrating 
legacy systems with the systems to be developed/acquired;

Element satisfied? No.

Technical: Key architectural element: A list of infrastructure systems 
and a description of the systems' hardware and software infrastructure 
components. The description should also reflect the system's relative 
importance to achieving the department's vision based on constraints, 
business value, and technical performance;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not provide a 
complete list of the "To Be" infrastructure systems, nor does it 
describe the functional characteristics, capabilities, and 
interconnections for the infrastructure projects listed. It also does 
not reflect the systems' relative importance to achieving DHS's vision. 
For example, the relationship between the department's vision for 
infrastructure projects and their value in preventing terrorist attacks 
has not been defined; However, it does identify a conceptual project 
(i.e., OneDHS) that may be used to consolidate the infrastructure. It 
also identifies a list of conceptual applications (e.g., a 
communications management application to manage connectivity between 
networks) that may provide certain infrastructure capabilities and 
functions for OneDHS. Further, it identifies associated subprojects, 
such as a secure network, server and storage consolidation, and a 
standard desktop environment, and it associates them with the business 
areas;

The architecture also lists several existing infrastructure systems, 
such as the Department of Defense's (DOD) Secure Internet Protocol 
Routing Network, which may be used by the department and its homeland 
security partners;

The architecture outlines an approach for establishing a framework to 
enable DHS to sequence the delivery of capabilities over time based on 
homeland security priorities.

Technical: Key architectural element: A description of the policies, 
procedures, processes, and tools for selecting, controlling, and 
evaluating infrastructure systems to enable effective IT investment 
management;

Element satisfied? No.

Technical: Key architectural element: A description of the technical 
reference model (TRM[G] ) that describes the enterprise infrastructure 
services,h including specific details regarding the functionality and 
capabilities that these services will provide to enable the development 
of application systems;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not contain a 
TRM that describes all enterprise infrastructure services. The list of 
technical services is likely incomplete because the architecture does 
not identify all DHS organizations and its homeland security partners 
that supply and consume technical services. For example, the 
architecture indicates the use of DOD's Secure Internet Protocol 
Routing Network, which is a Global Information Grid (GIG)[I] enterprise 
service, to exchange information among homeland security organizations. 
However, it does not list the technical services that are provided by 
this network. The architecture also does not show whether these TRM 
services are common or reusable;

In addition, the architecture does not describe the functionality and 
capabilities that will be provided by the services that are identified;

However, it does contain a high-level TRM that provides a structure and 
vocabulary that can be used to describe DHS's enterprise infrastructure 
services. It also contains application principles (e.g., there will be 
only one enterprise application for each function area, to be used by 
all departmental organizations) and technology patterns (e.g., use of 
commercial-off-the-shelf software for implementing relational 
databases) that can be used to guide technology development and 
acquisition decisions.

Technical: Key architectural element: A description in the TRM that 
identifies and describes (1) the technical standards[J] to be 
implemented for each enterprise service and (2) the anticipated life 
cycle of each standard;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not contain a 
complete standards profile (i.e., it excludes technical standards that 
support a number of the services reflected in the TRM). For example, 
the profile does not identify standards that support "narrowband 
wireless access," even though there are applicable homeland security 
applications that require this service (e.g., Land Mobile Radio, Air to 
Ground Communications, Mobile Operations IT). It also does not list the 
actual life cycles (e.g., "sunset" dates for current products and 
standards, and dates for when new developments will use target 
technologies) of many of the standards and products identified in the 
architecture;

However, it does contain a list of technical standards that the 
department and/or its partners may implement.

Technical: Key architectural element: A description of the physical IT 
infrastructure needed to design and acquire systems, including the 
relationships among hardware, software, and communications devices;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not provide a 
description of the physical IT infrastructure that will be needed to 
support future operations. Specifically, it does not fully describe 
networks and their topologies and configurations for the department's 
internal and/or shared spaces. For example, the architecture does not 
identify the component parts of the DHS consolidated network. It also 
does not relate the technology platforms to applications and business 
functions;

However, the architecture does provide a vision for the technology 
environment, such as a high-level diagram that depicts information 
sharing among user groups. It also identifies telecommunications 
backbone options for exchanging data, such as use of the Internet for 
sensitive but unclassified data. The architecture also identifies types 
of technology platforms, including computing, storage, and 
communication devices and software.

Technical: Key architectural element: Common policies and procedures 
for developing infrastructure systems throughout their life cycles, 
including requirements management, design, implementation, testing, 
deployment, operations, and maintenance. These policies and procedures 
should also address how the applications will be integrated, including 
legacy systems;

Element satisfied? No.

Security: Key architectural element: A description of the policies, 
procedures, goals, strategies, principles, and requirements relevant to 
information assurance and security and how they (the policies, 
procedures, goals, strategies, and requirements) align and integrate 
with other elements of the architecture (e.g., security services);

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not describe 
the policies, procedures, goals, strategies, principles, and 
requirements that are relevant to information assurance and security, 
nor their alignment and integration with other architecture elements;

However, it does contain (1) a high-level diagram that depicts a data 
classification schema to facilitate information sharing (e.g., 
sensitive but unclassified or top secret); (2) a security pattern that 
can be used to provide capabilities to secure and protect IT resources 
(e.g., confidentiality via encryption, authorization and access control 
via single sign-on, and intrusion detection and prevention using 
firewalls); and (3) a security principle that reflects the requirement 
for sharing information contained within nonclassified systems. This 
information could be used to develop a strategy.

Security: Key architectural element: Definitions of terms related to 
security and information assurance;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not define 
all key terms that are listed (e.g., "information assurance" and 
"security services"). In addition, there are discrepancies between 
DHS's security terms and others involved in homeland security, such as 
DOD. For example, DOD's definitions for authentication, availability, 
confidentiality, and integrity differ from DHS's definitions for the 
same terms;

However, the architecture does contain definitions for some security-
related terms (e.g., "identification and authorization" and "audit 
trail").

Security: Key architectural element: A listing of accountable 
organizations and their respective responsibilities for implementing 
enterprise security services. It is important to show organizational 
relationships in an operational view because they illustrate 
fundamental roles (e.g., who conducts operational activities) and 
management relationships (e.g., what is the command structure or 
relationship to other key players) and how these influence the 
operational nodes;

Element satisfied? No.

Security: Key architectural element: A description of operational 
security rules that are derived from security policies;

Element satisfied? No.

Security: 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 relationship of these services to protective mechanisms;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture's TRM does not 
explicitly identify the security services, making it difficult to 
ensure that there are no redundant services, nor does it clearly define 
what constitutes a technical security service. In addition, the 
architecture identifies DOD's Secure Internet Protocol Routing Network, 
thereby implying the use of a GIG enterprise service, but it does not 
reconcile how or whether these services will be used by DHS and other 
homeland security entities;

However, the architecture does provide some guidance on security 
services, and it lists several services to be used to secure and 
protect resources, such as confidentiality, data integrity, 
authentication, and policy enforcement.

Security: Key architectural element: A description of the security 
standards to be implemented for each enterprise service. These 
standards should be derived from security requirements. This 
description should also address how these services will align and 
integrate with other elements of the architecture (e.g., security 
policies and requirements);

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not contain a 
complete list of standards. For example, it does not include standards 
for several security services (e.g., network security/intrusion 
detection systems and single sign-on) nor does it provide a rationale 
for excluding them;

Further, the architecture does not explain how DHS will communicate 
with other extended architecture systems (e.g., DOD and Department of 
State) if those systems require certain standards to support DHS 
systems;

However, the architecture does contain a list of several security 
standards that may be associated with security services.

Security: Key architectural element: A description of the protection 
mechanisms (e.g., firewalls and intrusion detection software) that will 
be implemented to secure the department's assets, including a 
description of the interrelationships among these protection 
mechanisms;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not contain a 
complete list of the protection mechanisms needed, nor does it describe 
all these mechanisms and the interrelationships among them. For 
example, protection mechanisms have not been identified for monitoring 
and auditing activities, biometrics, control and protection, computer 
forensics tools, and computer intrusion and alarm. Moreover, the 
architecture indicates that security requirements have not been 
analyzed, thereby bringing into question the validity of the protection 
mechanisms identified;

However, the architecture does contain a list of protection mechanisms, 
such as firewalls.

Source: GAO analysis of DHS data.

[A] A business assessment is a comprehensive analysis of the business, 
from both an internal and an external perspective, to reach conclusions 
on what requires strategic management focus and action.

[B] A gap analysis is the process of comparing an existing state with a 
desired state and determining what changes must be made to achieve the 
desired state.

[C] DHS defines a conceptual project as a project that is "derived from 
business activities and their associated applications and components. 
Conceptual projects are the highest level of categorization for a set 
of capabilities that can be combined and developed to satisfy a set of 
business requirements.":

[D] A CURE (create, update, reference, and eliminate) matrix shows the 
business functions and applications that create, update, reference, 
and/or eliminate specific data elements, enabling the organization to 
develop applications.

[E] Business and operational rules define specific constraints for the 
data, such as security needs (e.g., confidentiality and accessibility 
of data) and actions that should or should not occur, such as updating 
or deleting data.

[F] Metadata are "data about data" that enable automation and 
consistent management and use of information, such as rules and 
standards.

[G] The technical reference model (TRM) describes (1) how technology is 
supporting the delivery of service components and (2) the relevant 
standards for implementing the technology. The TRM is a generally 
accepted representation of the generic components of an information 
system. It allows designers, developers, and users to agree on 
definitions, have a common understanding of the services to be 
provided, and identify and resolve issues affecting such requirements 
as interoperability, portability, reliability, scalability, and 
serviceability.

[H] Examples of enterprise services include application services, such 
as Web services, and collaboration services, such as instant messaging 
and video conferencing.

[I] DOD defines the Global Information Grid 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.

[J] Technical standards are strict rules and protocols governing how a 
given enterprise service is to be implemented.

[End of table]

[End of section]

Appendix III: Detailed Results of GAO's Analyses of Version 1.0 of 
DHS's Transition Plan:

Key architectural element: Analysis of the gaps between the baseline 
and the target architecture for business processes, information/data, 
and services/application systems to define missing and needed 
capabilities;

Element satisfied? No.

Key architectural element: A high-level strategy[A] for implementing 
the enterprise architecture;

This strategy should include:

Key architectural element: * Specific time-phased milestones for 
acquiring and deploying systems;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not have 
specific milestones for any actual projects that will deploy systems;

However, the architecture does identify specific time-phased milestones 
for conceptual projects. For example, it notes that projects 
categorized as "Quick Hits" will be completed within 6 months, projects 
to consolidate duplicate systems within less than 2 years, and projects 
that optimize systems after 2 years.

Key architectural element: * Performance metrics for determining 
whether business value is being achieved;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not contain 
explicit metrics that can be implemented or assessed, but it recognizes 
the need for such metrics;

However, the architecture does contain high-level metrics, such as "the 
percent of data/information shared across organizational units" that 
may be used to establish detailed metrics.

Key architectural element: * Financial and nonfinancial resources 
needed to achieve the business transformation;

Element satisfied? No.

Key architectural element: * A listing of the legacy systems that will 
not be part of the "To Be" environment and the schedule for terminating 
these systems;

Element satisfied? No.

Key architectural element: * A description of the training strategy/ 
approach that will be implemented to address the changes made to the 
business operations (processes and systems) to promote operational 
efficiency and effectiveness. This plan should also address any changes 
to existing policies and procedures that affect day-to-day operations, 
as well as resource needs (staffing and funding);

Element satisfied? No.

Key architectural element: * A list of the systems to be developed, 
acquired, or modified to achieve business needs and a description of 
the relationship between the system and the business need(s);

Element satisfied? No.

Key architectural element: A strategy for employing enterprise 
application integration (EAI) plans, methods, and tools to, for 
example, provide for efficiently reusing applications that already 
exist, concurrent with adding new applications and databases;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not contain a 
strategy for employing EAI plans, methods, and tools, nor does it 
describe how EAI will be used to integrate legacy and future systems;

However, it does list technologies, products, and standards for EAI. It 
also contains a vision for a service-oriented architecture[ B] that may 
be developed into an EAI strategy.

Key architectural element: A technical (systems, infrastructure, and 
data) migration plan that shows:

Key architectural element: * the transition from legacy to replacement 
systems, including explicit sunset dates and intermediate systems that 
may be temporarily needed to sustain existing functionality during the 
transition period;

Element satisfied? No.

Key architectural element: * an analysis of system interdependencies, 
including the level of effort required to implement related systems in 
a sequenced portfolio of projects that includes milestones, time lines, 
costs, and capabilities;

Element satisfied? No.

Key architectural element: * a cost estimate for the initial phase(s) 
of the transition and a high-level cost projection for the transition 
to the target architecture;

Element satisfied? No.

Key architectural element: * A strategy that describes the 
architecture's governance and control structure and the integrated 
procedures, processes, and criteria (e.g., investment management and 
security) to be followed to ensure that the department's business 
transformation effort remains compliant with the architecture;

Element satisfied? Partially;

Explanation of partially satisfied: The architecture does not include 
an architecture governance and control structure and the integrated 
procedures, processes, and criteria to be followed;

However, the architecture recognizes the need for a governance 
structure and contains a high-level discussion of governance that 
focuses on identifying the most critical governance issues and 
challenges, making general recommendations for dealing with these, and 
establishing the context in which appropriate managers, process owners, 
and subject matter experts will develop process details. 

Source: GAO analysis of DHS data.

[A] Acquisition/business strategy is a plan or action for achieving a 
specific goal or result through contracting for software products and 
services.

[B] A service-oriented architecture is a collection of services that 
must communicate with each other. The communication might involve only 
simple data passing, or it could involve two or more services 
coordinating some activity. It requires a means for connecting the 
services to each other.

[End of table]

[End of section]

Appendix IV: Comments from the Department of Homeland Security: 

U.S. Department of Homeland Security: 
Washington, DC 20528:

Mr. Randolph Hite:

Director, Architecture and Systems Issues: 
Government Accountability Office: 
Washington, DC 20548:

JUL 23 2004:

Re: GAO-04-777; Homeland Security: Efforts Underway to Develop 
Enterprise Architecture, But Much Work Remains, GAO Engagement Number 
310272:

Dear Mr. Hite:

Thank you for the opportunity to review the findings referenced in the 
draft report, GAO 04-777. Homeland Security: Efforts Underway to 
Develop Enterprise Architecture But Much Work Remains.

GAO Recommendations:

To assist DHS in developing a well defined architecture, GAO is making 
recommendations to the Secretary of Homeland Security that are aimed at 
improving the department's architecture development approach and the 
content of its architecture. GAO is also making a recommendation to the 
Director of OMB to clarify the expected relationship between agencies' 
enterprise architectures and the Federal Enterprise Architecture.

Response:

The Department of Homeland Security (DHS) acknowledges that much work 
does remain to create a target enterprise architecture (EA) and 
transition plan to support business and information technology 
transformation; however, we take exception to several aspects of the 
report and its recommendations.

The DHS EA was evaluated against an unrealistic expectation that the 
first version would comprehensively address the full national scope of 
the homeland security enterprise. While this full scope is one of the 
highest priorities of the EA effort, the scope is long term and 
collaborative in nature. The report does not fully recognize the "blank 
sheet of paper" DHS had on March 2003 d the need with limited resources 
to guide DHS transformation and to engage our business community in 
this transformation.

It is important to recognize that the DHS EA was evaluated against 
criteria that has not yet been provided to the federal community, and 
was not available when Version 1.0 was being developed.,

One of the most significant outcomes of Version 1.0 was the positioning 
of the Department to more actively engage with our business 
representatives from a strategic perspective; and thereby gain a 
greater appreciation of the need for and value of EA generally on the 
part of our senior and executive management. We accomplished this goal 
with Version 1.0, and intend to continuously improve the content and 
processes of our EA program over time.

The recommendations do not take into consideration limited resources. 
The report explicitly expects that DHS would have fully decomposed all 
aspects of all elements of an EA when in fact (given time, resources 
and the maturity of the department), we selectively focused on those 
areas of the EA that were most transformational in nature. It would 
also have been helpful to have received the recommendations in a 
prioritized framework so that the most cost-effective impact on 
transforming DHS as mandated by the establishment of the Department can 
be realized. Notwithstanding the absence of prioritization, the DHS EA 
program will ensure that the criteria are addressed to the extent 
possible (given resources and time) in Version 2. Aspects of the 
criteria that are not incorporated into Version 2 will be integrated 
into subsequent versions in the most cost effective and technically 
disciplined manner possible. Our response to each key architectural 
element under Appendix II, Detailed Results of GAO's Analyses of DHS's 
"To Be" Architecture and Appendix III, Detailed Results of GAO's 
Analyses of Version 1.0 of DHS's Transition Plan are enclosed.

We again thank you for the opportunity to provide comments on this 
report.

Signed by: 

Anna Dixon:

Director, Bankcard Programs and GAO/OIG Liaison: 
Office of the Chief Financial Officer:
U.S. Department of Homeland Security:

Enclosure:

APPNDX II: 1;
RECOMMENDATION: BUSINESS: A business assessment that includes the 
enterprise's purpose, scope (e.g., organizations, business areas, and 
internal and external stakeholders' concerns), limitations or 
assumptions, and methods;
ISSUE: Business Assessment;
COMMENT: A high-level business assessment was included as the Business 
Model Overview document which describes and characterizes of the 
business model in terms of scope and methods.

APPNDX II: 2;
RECOMMENDATION: BUSINESS: A gap analysis that describes the target 
outcomes and shortfalls including strategic business issues, 
conclusions reached as a result of the analysis (e.g., missing 
capabilities), causal information, and rationales;
ISSUE: Gap Analysis;
COMMENT: Concur. as additional information is collected for version 2.0 
a more detailed gap analysis can be conducted. The primary intent of 
the EA version 1 was to describe the target business environment in 
terms of functions and data. A high-level assessment was conducted in 
order to develop the sequence diagram for the transition strategy which 
draws relationships between current investments and target functions/
activities. If anything, rather than gaps there are/is a lot of 
redundancy in terms of investments.

APPNDX II: 3;
RECOMMENDATION: BUSINESS: A business strategy that describes the 
desired future state of the business, the specific objectives to be 
achieved, and the strategic direction that will be followed by the 
enterprise to realize the desired future state;
ISSUE: Business Strategy:
COMMENT: The intent of the EA version 1.0 was to describe the business 
in terms of the top to rows of the Zachman framework. The EA Business 
strategy that describes the EA Program scope, objectives and strategic 
directions was not within the scope of the initial architecture 
description.

In regards to the business strategy (mission, goals and objectives) for 
the Department that is defined in the DHS strategic plan. EA planning 
and implementation does not dictate the DHS strategic direction, 
mission and goals but rather is complementary to the strategic plan and 
brings that plan into life.

APPNDX II: 3a:
RECOMMENDATION: BUSINESS: A vision statement that describes the 
business areas required strategic attention based on the gap analysis;
ISSUE: Vision Statement;
COMMENT: See response to 3.

APPNDX II: 3b:
RECOMMENDATION: BUSINESS: A description of the business priorities and 
constraints, including their relationships to, at a minimum, applicable 
laws and regulations, executive orders, departmental policy, 
procedures, guidance, and audit reports;
ISSUE: Business Priorities & Constraints;
COMMENT: Concur with comment. Version 2.0 will better define the 
business priorities and constraints, however mapping to applicable laws 
and regulations, executive orders, departmental policy, procedures, 
guidance, and audit reports will be a huge resource intensive exercise 
and will not be completed until a later date.

APPNDX II: 3c;
RECOMMENDATION: BUSINESS: A description of the scope of business change 
that is to occur to address identified gaps and realize the future 
desired business state. The scope of change, at a minimum, should 
identify expected changes to strategic goals, customers, suppliers, 
services, locations, and capabilities;
ISSUE: Scope of Business Change;
COMMENT: The intent of the EA version 1.0 was to describe the business 
in terms of the top two rows of the Zachman framework. Once information 
is collected and vetted then the true analysis can begin. This is a 
critical step in understanding the long term changes that will need to 
be managed across the Department. Preliminary analysis will begin in 
the Summer of 2004.

APPNDX II: 3d;
RECOMMENDATION: BUSINESS: A description of the measurable strategic 
business objectives to be met to achieve the desired change;
ISSUE: Measurable Strategic Business Objectives;
COMMENT: The intent of the EA version 1.0 was to describe the business 
terms in of the top two rows of the Zachman framework. The measurable 
business objectives are defined in the DHS strategic plan. The 
relationship between the EA business view and the strategic objectives 
is described in terms of related business activities to strategic 
objectives.

In terms of the business objectives of the EA program, those are 
described in the Governance strategy and DHS EA Governance Plan, which 
is being implemented incrementally.

APPNDX II: 3e;
RECOMMENDATION: BUSINESS: A description of the measurable tactical 
business goals to be met to achieve the strategic objectives;
ISSUE: Measurable Tactical Business Goals;
COMMENT: The intent of the EA version 1.0 was to describe the business 
terms in of the top two rows of the Zachman framework. The measurable 
business goals are defined in the DHS strategic plan. The relationship 
between the EA business view and the strategic goals is described in 
terms of related business activities to strategic objectives 
(associated with the strategic goal).

In terms of the business qoals of the EA program, those are described 
in the Governance strategy and DHS EA Governance Plan, which is being 
implemented incrementally.

APPNDX II: 3f;
RECOMMENDATION: BUSINESS: A listing of opportunities to unify and 
simplify systems or processes across the department, including their 
relationships to solutions that align with the strategic initiatives to 
be implemented to achieve strategic objectives and tactical goals;
ISSUE: Listing - Unify / Simplify Systems or Processes;
COMMENT: The intent of the EA version 1.0 was to describe the business 
in terms of the top two rows of the Zachman framework. Once information 
is collected and vetted then the true analysis can begin. This is a 
critical step in understanding the long term changes that will need to 
be managed across the Department. More detailed analysis will be part 
of the transition plan analysis to be conducted during the Summer of 
2004 and be delivered along with the EA V2 materials:

APPNDX II: 4;
RECOMMENDATION: BUSINESS: Common (standard and department wide) 
policies, procedures, and business and operational rules for consistent 
implementation of the architecture;
ISSUE: Standard Business Policies, Procedures, Rules;
COMMENT: In terms of the business goals of the EA program, those are 
described in the Governance strategy and DHS EA Governance Plan, which 
is being implemented incrementally - to include EA policy, procedures 
and rules.

APPNDX II: 5;
RECOMMENDATION: BUSINESS: A description of key business processes and 
how they support the department's mission, including the organizational 
units responsible for performing the business processes and the 
locations where the business processes will be performed;
ISSUE: Key Business Processes;
COMMENT: This statement is false. Key business processes are described 
in terms of the business function/activity descriptions contained in 
the business model. These functions/activities were derived from the 
Homeland Security Act of 2002 and the National Strategy for Homeland 
Security.

APPNDX II: 5a;
RECOMMENDATION: BUSINESS: this description should provide for the 
consistent alignment of: a) applicable federal laws, regulations, and 
guidance;
ISSUE: Applicable Federal Laws, Regulations & Guidance;
COMMENT: The functions/activities were derived from the National 
Strategy for Homeland Security and the Homeland Security Act of 2002. 
While these are not a specific mapping of the activities to each 
requirement additional resources are required to conduct more detailed 
analysis. See response to 3b.

APPNDX II: 5b;
RECOMMENDATION: BUSINESS: this description should provide for the 
consistent alignment of: b) departmental policies, procedures, and 
guidance;
ISSUE: Department Policies, Procedures & Guidance;
COMMENT: The intent of the EA version 1.0 was to describe the business 
in terms of the top two rows of the Zachman framework. Alignment to 
department policy, procedures and guidance is described in the 
governance strategy and DHS EA Governance Plan, which is being 
implemented incrementally.

APPNDX II: 5c;
RECOMMENDATION: BUSINESS: this description should provide for the 
consistent alignment of: c) operational activities;
ISSUE: Operational Activities;
COMMENT: This statement is false. Operational activities are described 
in terms of the business function/ activity descriptions contained in 
the business model These functions/activities were derived from the 
Homeland Security Act of 2002 and the National Strategy for Homeland 
Security.

APPNDX II: 5d;
RECOMMENDATION: BUSINESS: this description should provide for the 
consistent alignment of: d) organizational roles;
ISSUE: Organizational Roles;
COMMENT: DHS organizations are attributed to each of the business 
activities as appropriate. While the specific roles are not defined, 
the information collected provides a starting point to understanding 
the relationship between the organizational elements and the functions 
they perform. This will be further analyzed to better define the 
organizational roles within the Department. Version 2.0 provides an 
organizational description in terms of mission and function. This 
information will be used in that analysis.

APPNDX II: 5e;
RECOMMENDATION: BUSINESS: this description should provide for the 
consistent alignment of: e) operational events and information;
ISSUE: Operational Events;
COMMENT: The intent of the EA version 1.0 was to describe the business 
in terms of the top two rows of the Zachman framework. Part of that 
information is indeed key business events. Future work is planned 
involving key DHS internal stakeholders in defining and describing key 
events and the relationship of those events to the business:

functions/activities.

APPNDX II: 6;
RECOMMENDATION: BUSINESS: A description of the operational management 
processes to ensure that the department's business transformation 
effort remains compliant with the business rules for fault, 
performance, security, configuration, and account management;
ISSUE: Operational Management Processes;
COMMENT: The intent of the EA version 1.0 was to describe the business 
in terms of the top to rows of the Zachman framework. Alignment to 
organizational management processes is described in the governance 
strategy and DHS EA Governance Plan, which is being implemented 
incrementally.

APPNDX II: 7;
RECOMMENDATION: BUSINESS: A description of the organizational approach 
(processes and organizational structure) for communications and 
interactions among business lines and program areas for:
ISSUE: Organizational Communications Processes and Structure;
COMMENT: The intent of the EA version 1.0 was to describe the business 
in terms of the top to rows of the Zachman framework. The 
organizational approach to the EA processes and organizational 
structure for communications and interactions among business lines and 
program areas is described in the governance strategy, DHS EA 
Governance Plan, and DHS EA Communications Plan - which is being 
implemented incrementally.

APPNDX II: 7a;
RECOMMENDATION: BUSINESS: A description of the organizational approach 
(processes and organizational structure) for communications and 
interactions among business lines and program areas for: a) management 
reporting;
ISSUE: Management Reporting;
COMMENT: See response to 7. If the proper information is collected 
during the EA Planning phase analysis can be conducted inform 
management of the most effective methods of management reporting. The 
EA Planning team has only considered management reporting in terms of 
the EA program.

APPNDX II: 7b;
RECOMMENDATION: BUSINESS: A description of the organizational approach 
(processes and organizational structure) for communications and 
interactions among business lines and program areas for: b) operational 
functions;
ISSUE: Operational Functions;
COMMENT: The intent of the EA version 1.0 was to describe the business 
in terms of the top to rows of the Zachman framework. In terms of the 
management structure of the Department, that information was provided 
and used from the DHS organizational chart provided to the EA team. 
Business functions/activities were attributed by organizations that 
perform those functions. This information (once more detailed 
information can be collected) can be used to allow management to make 
informed decisions and understand the impact to the organization of 
those decisions.

APPNDX II: 7c;
RECOMMENDATION: BUSINESS: A description of the organizational approach 
(processes and organizational structure) for communications and 
interactions among business lines and program areas for: c) 
architectural development and use (i.e., how to develop the 
architecture description, implement the architecture, and govern/
manage the development and implementation of the architecture;
ISSUE: Architectural Development & Use;
COMMENT: Architecture development and use is described in the 
Governance strategy and DHS EA Governance Plan, which is being 
implemented incrementally.

APPNDX II: 8;
RECOMMENDATION: PERFORMANCE: A description of the processes for 
establishing, measuring, tracking, evaluating, and predicting business 
performance regarding business functions, baseline data, and service 
levels.
ISSUE: Process - Business Performance Metrics;
COMMENT: Version 2.0 of the EA will provide an enhanced business model 
that will be a solid foundation for establishing performance measures. 
The individual business activities identified in Version 2.0 should 
each have performance measures and metrics, baseline data, and service 
levels associated with them. The overall process for developing this 
performance information needs to be defined by the business area and 
performance measurement staff of DHS. This is a substantial process 
that must involve a wide range of DHS components working together. To 
the extent these processes are developed, they will be referenced and/
or included in Version 2.0. The conceptual project and business 
activity related to this area in Version 1.0 will be expanded upon in 
Version 2.0 by the DHS EA Project team.

APPNDX II: 9;
RECOMMENDATION: PERFORMANCE: A description of measurable business goals 
and outcomes for business products and services, including strategic 
and tactical objectives;
ISSUE: Goals & Outcomes - Business Products & Services;
COMMENT: Version 2 of the EA will provide an enhanced business model 
that will be a solid foundation for establishing business goals and 
outcomes. The individual business activities or value chain areas 
identified in Version 2 can each have measurable goals and outcomes 
associated with them. The development of the specific quantitative 
goals and outcomes needs to be done by each business area and 
performance measurement staff of DHS. To the extent these goals and 
outcomes are developed, they will be referenced or included in Version 
2. The description of customer focused, measurable business goals 
included in Version 1 will be expanded upon in Version 2.

APPNDX II: 10;
RECOMMENDATION: PERFORMANCE: A description of measurable technical 
goals and outcomes for managing technology products and services for 
the "To Be" architecture that enable the achievement of business goals 
and outcomes.
ISSUE: Goals & Outcomes - Technology Products;
COMMENT: Version 2.0 of the EA will provide an improved foundation for 
describing technical goals and outcomes. The technology-related 
quantitative goals and outcomes need to be defined by the CIO and 
performance measurement staff of DHS. To the extent these goals and 
outcomes are developed, they will be referenced and/or included in 
Version 2.0. The performance measures for measuring technology and the 
technology management conceptual projects included in Version 1.0 will 
be expanded upon in Version 2.0.

APPNDX II: 11;
RECOMMENDATION: INFORMATION / DATA: A description of data management 
policies, procedures, processes, and tools (e.g., CURE matrix) for 
analyzing, designing, building, and maintaining databases in an 
enterprise architected environment;
ISSUE: Data Management Policies, Procedures, Processes & Tools;
COMMENT: The intent and scope of the version 1.0 effort was to collect 
the terms and facts that represent the common nouns (data objects) of 
the business. The data management policy, practices, processes and 
tools will be defined in the data management governance documents at a 
later date:

The CURE matrix is a data usage planning tool, in that is provides 
high-level relationships between the business functions/activities and 
how those functions/activities may act on a particular data object. 
This tool is instrumental in the application/component architecture 
definition phase.

This version of DHS EA data architecture represents conceptual data 
model and it was not intended to define data mgmt policies, procedures, 
processes and tools at this level. Acceptance criteria did not identify 
this as a requirement.

APPNDX II: 12;
RECOMMENDATION: INFORMATION / DATA: 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 address to, maintenance of, and use of data;
ISSUE: Data Standardization - Business &Operational Rules;
COMMENT: The intent and scope of the version 1.0 effort was to collect 
the terms and facts that represent the common nouns (data objects) of 
the business. The data management policy, practices (including business 
and security rules), processes and tools will be defined at a later 
date as the EA plan is refined and the architecture matures.

APPNDX II: 13;
RECOMMENDATION: INFORMATION / DATA: A data dictionary, which is a 
repository of standard data definitions for applications;
ISSUE: Data Dictionary.

APPNDX II: 14;
RECOMMENDATION: INFORMATION / DATA: A conceptual data model that 
describes the fundamental things/objects (e.g., business or tourist 
visas, shipping manifests) that make up the business, without regard 
for how they will be physically stored. A conceptual data model 
contains the content needed to derive facts about the business and to 
facilitate the creation of business rules. It represents the 
consolidated structure of business objects to be used by business 
applications;
ISSUE: Conceptual Data Model;
COMMENT: This is not accurate. A conceptual data model was delivered 
consisting of a list of primary data object definitions and 
characteristics, associated business subject areas and even some high-
level subject area diagrams. Conceptual data models are usually 
abstract, however necessary to begin to form the underlying structure 
of the business needs. The intent and scope of the version 1 effort was 
to collect the terms and facts that represent the common nouns (data 
objects) of the business to understand the types of information of 
which the department has a need to collect and store. The purpose of 
conceptual data model is to provide common vocabulary for the 
enterprise and to depict fundamental structure of the enterprise in 
terms of data. It was not intended to provide rules for building 
databases.

APPNDX II: 15;
RECOMMENDATION: INFORMATION / DATA: A logical database model that 
provides (1) a normalized (I/e/, non-redundant) data structure that 
supports information flows and (2) the basis for developing the schemes 
for designing, building, and maintaining physical databases;
ISSUE: Logical Database Model;
COMMENT: The main focus of the EA version 1.0 effort was to describe 
the DHS enterprise in terms of the top two rows of the Zachman 
framework. Clearly, a logical data model does not fall within that 
scope, but rather a logical data model would be defined by a "solution" 
architecture using the structure provided and defined by the conceptual 
data model. That is ensuring that information and data used by a 
solution is reflective within the enterprise conceptual data model. 
There was not our objective to develop logical data model at this 
point:

APPNDX II: 16;
RECOMMENDATION: INFORMATION / DATA: A metadata model that specifies the 
rules and standards for representing data (e.g., data formats) and 
accessing information (e.g., data protocols) according to a documented 
business context that is complete, consistent, and practical;
ISSUE: Metadata Model;
COMMENT: The intent and scope of the version 1 effort was to collect 
the terms and facts that represent the common nouns (data objects) of 
the business. The data management policy, practices, processes 
(including rules and standards for representing data) and tools will be 
defined in the data management governance documents at a later date.

APPNDX II: 17;
RECOMMENDATION: INFORMATION / DATA: A description of the information 
flows and relationships among organizational units, business 
operations, and system elements;
ISSUE: Information Flows & Relationships;
COMMENT: The main focus of the EA version 1.0 effort was to describe 
the DHS enterprise in terms of the top two rows of the Zachman 
framework. As the EA Plan continues to evolve information flows will 
created to describe the information flow among organizational entities 
as well as with external entities;

APPNDX II: 18;
RECOMMENDATION: SERVICES / APPLICATIONS: A description of the services 
and their relationships to key end-user services to be provided by the 
application systems;
ISSUE: Services - Key End Users;
COMMENT: The description of the Notional Application Architecture 
describes applications in terms of the user workflows they enable;

APPNDX II: 18a;
ISSUE: Specify End-User Services by Application Systems;
COMMENT: While it is not specifically mentioned, these applications 
were derived from the usage of business functions by user classes, as 
mapped in the business model. This relationship of user to business 
function to application will be much more apparent in version 2.

APPNDX II: 18b;
ISSUE: Inconsistency User Services / Application;
COMMENT: The consumption diagram for the Communication Systems 
Management Application specifically calls out the consumption of Email 
services for managing some of the correspondence.

APPNDX II: 19;
RECOMMENDATION: SERVICES / APPLICATIONS: A list of application systems 
(acquisition/development and production portfolio) and their relative 
importance to achieving the department's vision, based on business 
value and technical performance;
ISSUE: Application Systems - Relevance to DHS Vision;
COMMENT: The Application and Component Architectures indirectly link to 
the Value Chain, via the business functions. Relative importance should 
be noted via this linkage. However, Applications will cross both value 
chain and organizational boundaries. This is the basis of reuse that 
has been built into the architecture. Version 2.0 of the Application 
and Component Architecture should have more detail available to specify 
which organizations will be able to use each component. This will be 
based on the mapping of Components to the Business Functions they 
enable. Business Functions are then mapped to the organizations (both 
internal and external) that perform them.

APPNDX II: 20;
RECOMMENDATION: SERVICES / APPLICATIONS: A description of the policies, 
procedures, processes, and tools for selecting, controlling, and 
evaluating application systems to enable effective IT investment 
management;
ISSUE: Application Systems - IT Investment Management;
COMMENT: The notional application and component architecture describes 
the categories of information systems required to execute the 
enterprise mission. The GAO report is correct in that it does not 
describe the governance for selecting, controlling, and evaluating 
systems to enable investment management. This is an issue that should 
be addressed with governance;

APPNDX II: 21;
RECOMMENDATION: SERVICES / APPLICATIONS: A description of the 
enterprise application systems and system components and their 
interfaces;
ISSUE: Application Systems, System Components and Interfaces.

APPNDX II: 22;
RECOMMENDATION: SERVICES / APPLICATIONS: A description of the system 
development lifecycle process for application development or 
acquisition and the integration of the process with the architecture, 
including policies, procedures, and architectural techniques for 
acquiring systems throughout their lifecycles. The common technical 
approach should also describe the process for integrating legacy 
systems with the systems to be developed/acquired;
ISSUE: System Development Life Cycle Process - App. Dev;
COMMENT: The business functions and their interaction with data and 
user roles requires much further decomposition before we can begin to 
describe all of the system development life cycle processes, policies, 
procedures, and architectural techniques. At this stage of the 
architecture, we have defined the need for types of software to be 
required by the enterprise. Once the models are decomposed into 
specifications, then it would be more appropriate to define how the 
software will be provisioned.

APPNDX II: 23;
RECOMMENDATION: TECHNICAL: A list of infrastructure systems and a 
description of the systems' hardware and software infrastructure 
components. The description should also reflect the system's relative 
importance to achieving the department's vision based on constraints, 
business value, and technical performance:
ISSUE: Infrastructure Systems, Hardware & Software Components;
COMMENT: "One DHS" has become a real initiative sponsored by the 
Infrastructure Services section of the Office of the CIO. "One DHS" is 
creating the Roadmap to One DHS Infrastructure which will detail out 
the list of infrastructure systems (including descriptions, hardware 
and software components, and value characteristics) which will support 
DHS moving forward. The DHS EA effort is coordinating with "One DHS" in 
order to incorporate this information into the architecture. We require 
timely response from the Infrastructure Services unit for this 
information as it is surfaced through the "One DHS" activities. 
Resource constraints within Infrastructure Services has negatively 
affected this timely response.

APPNDX II: 24;
RECOMMENDATION: TECHNICAL: A description of the policies, procedures, 
processes, and tools for selecting, controlling, and evaluating 
infrastructure systems to enable effective IT investment management;
ISSUE: Policies, Procedures, Processes, Tools - Infrastructure Systems 
Evaluation;
COMMENT: Governance processes, procedures and policies have been 
adopted to guide decision making as to architectural alignment of 
proposed technology investments. These are being described within V2.0 
of the DHS EA.

APPNDX II: 25;
RECOMMENDATION: TECHNICAL: A description of the technical reference 
model (TRM) that describes the enterprise infrastructure services, 
including specific details regarding the functionality and capabilities 
that these services will provide to enable the development of 
application systems;
ISSUE: TRM - Description Infrastructure Services;
COMMENT: Governance processes, procedures and policies have been 
adopted to guide the evolution and maturation of the DHS EA TRM. Focus 
is rapidly moving from as-is descriptions to to-be targets. These are 
being described within V2.0 of the DHS EA.

APPNDX II: 26;
RECOMMENDATION: TECHNICAL: A description in the TRM that identifies and 
describes (a) the technical standards to be implemented for each 
enterprise service and:
ISSUE: TRM - Technical Standards for Enterprise Service;
COMMENT: The V2.0 DHS EA TRM contains both structure and content which 
support the to-be target infrastructure services. These items are under 
governance processes, procedures and policies at a DHS enterprise 
level. These are being described within V2.0 of the DHS EA.

APPNDX II: 26a;
RECOMMENDATION: TECHNICAL: A description in the TRM that identifies and 
describes (b) the anticipated life cycle of each standard;
ISSUE: TRM - Life Cycle of each Standard;
COMMENT: The anticipated lifecycle of the above referenced technical 
standards is incorporated into v2.0 of the DHS EA TRM. The content of 
the lifecycle information is under governance and will be described 
within the V2.0 DHS EA;

APPNDX II: 27;
RECOMMENDATION: TECHNICAL: A description of the physical IT 
infrastructure needed to design and acquire systems, including the 
relationships among hardware, software, and communications devices;
ISSUE: Physical IT Infrastructure Description;
COMMENT: The "One DHS" initiative is defining the physical 
infrastructure components required to support a DHS to-be target. DHS 
EA is coordinating with "One DHS" in order to incorporate these 
definitions, descriptions and requirements into the DHS EA. DHS 
Infrastructure Services resource constraints limit the effectiveness of 
our coordination. Information Sharing requirements and solution 
concepts are included within V2.0 of the DHS EA.

APPNDX II: 28;
RECOMMENDATION: TECHNICAL: Common policies and procedures for 
developing infrastructure systems throughout their life cycles, 
including requirements management, design, implementation, testing, 
deployment, operations, and maintenance. These policies and procedures 
should also address how the applications will be integrated, including 
legacy systems;
ISSUE: Policies & Procedures - Developing Infrastructure Systems;
COMMENT: Common policies and procedures for life cycle development of 
infrastructure capabilities are being developed through "One DHS". DHS 
EA is coordinating with "One DHS" in order to incorporate these items 
within the DHS EA. Applications integration (including legacy) is 
addressed in the DHS EA through a combination of Services/ 
Applications, Technical and the DHS EA Transition Plan. These 
perspectives come to bear on every investment quided by the DHS EA. 
Concepts of how this would work are described within V2.0 of the DHS 
EA.
RECOMMENDATION: SECURITY:
COMMENT: Currently developing a draft security document that addresses 
these issues.

APPNDX II: 29;
RECOMMENDATION: SECURITY: A description or the policies, procedures, 
goals, strategies, principals, and requirements relevant to information 
assurance and security and how they (the policies, procedures, goals, 
strategies, and requirements) align and integrate with other elements 
of the architecture (e.g., security services);
ISSUE: Policies & Procedures - Information Assurance;
COMMENT: Concur. Policies and procedures for information assurance and 
security are not contained in the EA. The Department (CISO) is 
developing policies and procedures for information assurance and 
security. Currently developing security goals, underlying principles, 
strategies, implementation approaches, and standards. Policies and 
procedures will be referenced as part of the requirements:

APPNDX II: 30;
RECOMMENDATION: SECURITY: Definitions of terms related to security and 
information assurance;
ISSUE: Definitions of Terms - Information Assurance;
COMMENT: Concur. The conceptual EA (V1.0) presented the outline of a 
security architecture approach and indicated some of the components 
from which it will be constructed. The Security Architecture under 
development will define all terms included. The Definitions of Terms 
for Information Assurance will be developed and will align with 
commonly accepted terminology.

APPNDX II: 31;
RECOMMENDATION: SECURITY: A listing of accountable organizations and 
their respective responsibilities for implementing enterprise security 
services. It is important to show organizational relationships in an 
operational view because they illustrate fundamental roles (e.g., who 
conducts operational activities) and management relationships (e.g., 
what is the command structure or relationship to other key players) and 
how these influence the operational nodes;
ISSUE: List Organizations - Enterprise Security Services;
COMMENT: Concur. A listing of organizations and roles and 
responsibilities will be provided in the Security Architecture under 
development Currently developing the security organization and a high 
level diagram will be completed for V2.0.

APPNDX II: 32;
RECOMMENDATION: SECURITY: A description of operational security rules 
that are derived from security policies;
ISSUE: Operational Security Rules;
COMMENT: Concur. A listing of operational security rules derived from 
security policies will be provided in the Security Architecture 
underdevelopment. There is a need for clarification on requirements and 
specific details from the Department in order to complete this effort.

APPNDX II: 33;
RECOMMENDATION: SECURITY: A description of enterprise security 
infrastructure services (e.g., identification and authentication) that 
will be needed to protect the department's assets, and the relationship 
of these services to protective mechanisms;
ISSUE: Enterprise Security Infrastructure Services;
COMMENT: The purpose of the conceptual EA (V1.0) is to provide an 
outline of the elements of the EA that require further detail to be 
provided in subsequent versions. The EA V1.0 does indicate the security 
infrastructure services required, but does not indicate the mechanisms 
by which they will be implemented. These have been identified and will 
be incorporated in V2.0;

APPNDX II: 34;
RECOMMENDATION: SECURITY: A description of the security standards to be 
implemented for each enterprise service. These standards should be 
derived from security requirements. This description should also 
address how these services will align and integrate with other elements 
of the architecture (e.g., security policies and requirements);
ISSUE: Security Standards for Each Service;
COMMENT: Concur. The EA (V1.0) does not contain a complete list of 
standards (security and other) Development of standards is underway and 
will be reflected in subsequent versions. Will identify and incorporate 
general requirements (such as FIPS) there is a need to address the 
organization specific requirements (such as DoD etc) that will require 
cooperative work and input from the organizations.

APPNDX II: 35;
RECOMMENDATION: SECURITY: A description of the protection mechanisms 
(e.g., firewalls and intrusion detection software) that will be 
implemented to secure the department's assets, including a description 
of the interrelationships among these protection mechanisms;
ISSUE: Protection Mechanisms to Secure Assets;
COMMENT: Concur. The EA (V1.0) does not contain a list and descriptions 
of protective mechanisms to be employed. The EA V1.0 is intended as an 
outline EA to indicate the areas where further detail is required and 
is under development. A high level analysis for assessment of 
Protection Mechanisms to Secure Assets is underway;

APPNDX III: 36;
RECOMMENDATION: SECURITY: Analysis of the gaps between the baseline and 
the target architecture for business processes, information/data and 
services/application systems to define missing and needed capabilities;
ISSUE: Gap Analysis - Baseline and Target Architecture;
COMMENT: Partial analysis provided. Version 1.0 provided legacy systems 
by mission area and provided a sequencing plan that could be correlated 
to those same mission areas. Problems identified with the legacy 
systems are addressed by the target. Further Gap analysis was planned 
for during the Rationalize phase (first 6 months) of the Transition 
Plan. Each conceptual project contains a sub-project called As-Is/
Target Gap analysis. This sub-project identifies target requirements 
and determines the gap between current capabilities and target 
requirements. Results from the Gap analysis plan indicate:

-Existing applications or 300s that can be used to satisfy target 
requirements:

-Portions of an existing applications or 300 can be used to satisfy 
target requirements:

-No existing application or 300 can be used to satisfy a target 
requirement:

-A portion of an existing application or 300 can be used during an 
interim time period to satisfy a target requirement.

APPNDX III: 37;
RECOMMENDATION: SECURITY: A high-level strategy for implementing the 
enterprise architecture;
ISSUE: High Level Strategy - Implementing EA.

APPNDX III: 37a;
RECOMMENDATION: SECURITY: Specific time-phased milestones for 
acquiring and deploying systems;
ISSUE: Time-phased Milestones;
COMMENT: Concur.

APPNDX III: 37b;
RECOMMENDATION: SECURITY: Performance metrics for determining whether 
business value is being achieved;
ISSUE: Performance Metrics;
COMMENT: Concur.

APPNDX III: 37c;
RECOMMENDATION: SECURITY: Financial and non-financial resources needed 
to achieve the business transformations;
ISSUE: Financial & Non-financial Resources;
COMMENT: Partial analysis provided. Version 1.0 provided a correlation 
between conceptual projects and the associated already approved 300s. 
The Gap Analysis Projects (Within Each Conceptual Project) Will 
Determine The Extent To Which Current 300s Can Be Used.

APPNDX III: 37d;
RECOMMENDATION: SECURITY: A listing of the legacy systems that will not 
be part of the "To Be" environment and the schedule for terminating 
these systems;
ISSUE: Listing - legacy systems to be terminated;
COMMENT: Partial analysis provided. The existing and planned systems 
can be correlated to a swim lane in version 1.0. All existing systems 
will be phased out eventually or built upon as part of the target 
architecture. The Gap analysis project in each swim lane will focus on 
reviewing 300s that might meet specific target requirements and 
determine a specific action plan.

APPNDX III: 37e;
RECOMMENDATION: SECURITY: A description of the training strategy/
approach that will be implemented to address the changes made to the 
business operations (processes and systems) to promote operational 
efficiency and effectiveness. This plan should also address any changes 
to existing policies and procedures that affect day-to-day operations, 
as well as resource needs (staffing and funding);
ISSUE: Training Strategy for changes - business operations and 
processes;
COMMENT: Partial Analysis provided. Changed management and training was 
planned for as a part of each conceptual project. Change Management 
(People) Activities: These Sub-projects Seek To Improve Organizational 
Collaboration And Cooperation. Some Of These Projects May Result In 
Organizational Changes, Some In New Training Programs, And Some In 
Improved Procedures.

APPNDX III: 37f;
RECOMMENDATION: SECURITY: A list of the systems to be developed, 
acquired, or modified to achieve business needs and a description of 
the relationship between the system and the business need(s);
ISSUE: List of Systems to be developed, acquired, modified;
COMMENT: Partial Analysis Provided. A list of Target applications was 
provided and the concept.

APPNDX III: 38;
RECOMMENDATION: SECURITY: A strategy for employing enterprise 
application integrations (EAI) plans, methods, and tools to, for 
example, provide for efficiently reusing applications that already 
exist, concurrent with adding new applications and databases;
ISSUE: Strategy - Enterprise Architecture Integration Plans;
COMMENT: Concur with Partially Satisfied. There is a Enterprise 
Application Integration (EAI) component development that is planned as 
part of the Governance conceptual project.

APPNDX III: 39;
RECOMMENDATION: SECURITY: A technical (systems, infrastructure, and 
data migration plan that shows:
ISSUE: A Technical Migration Plan:

APPNDX III: 39a:
RECOMMENDATION: SECURITY: A technical (systems, infrastructure, and 
data migration plan that shows: a) the transition from legacy to 
replacement systems, including explicit sunset dates and intermediate 
systems that may be temporarily needed to sustain existing 
functionality during the transition period;
ISSUE: Transition from legacy to replacement systems;
COMMENT: Version 2.0 will show the transition from legacy to 
replacement systems.

APPNDX III: 39b;
RECOMMENDATION: SECURITY: A technical (systems, infrastructure, and 
data migration plan that shows: b) an analysis of system 
interdependencies, including the level of effort required to implement 
related systems in a sequenced portfolio of projects that includes 
milestones, timelines costs and capabilities;
ISSUE: Analysis - system Interdependencies;
COMMENT: Partial Analysis provided - dependencies between components 
and conceptual projects are shown on the sequencing diagram.

APPNDX III: 39c;
RECOMMENDATION: SECURITY: A technical (systems, infrastructure, and 
data migration plan that shows: c) a cost estimate for the initial 
phase(s) of the transition and high-level cost projection for the 
transition to the target architecture;
ISSUE: Cost Estimate Initial Phase;
COMMENT: Version 2.0 will show the cost and schedule of projects.

APPNDX III: 40;
RECOMMENDATION: SECURITY: A strategy that describes the architecture's 
governance and control structure and the integrated procedures 
processes and criteria (e.g., investment management and security) to be 
followed to ensure that the department's business transformation effort 
remains compliant with the architecture.
ISSUE: Strategy - architecture's governance and control structure;
COMMENT: Concur with the Partially Satisfied assessment.

[End of table] 

The following are GAO's comments on the Department of Homeland 
Security's (DHS) letter dated July 23, 2004.

GAO Comments: 

1. See the "Agency Comments and Our Evaluation" section of this report. 

2. We agree that Version 1. 0 included a high-level (or overview) 
business model that offered some descriptive information on weaknesses, 
such as potential areas of inefficiencies or overlaps in current 
departmental business functions and technology. However, the underlying 
business assessment that would form the basis for a clear statement of 
the enterprise's purpose, scope, limitations, assumptions, and methods 
for successful business transformation was not present, and DHS 
provided no evidence that such an assessment had been performed. For 
example, for the areas that the business model overview identified as 
potential areas of inefficiency or overlap, the architecture did not 
provide the supporting analysis. The architecture also did not provide 
a time frame for completing such an assessment or state that one would 
be performed. Further, when we concluded our analysis and shared our 
findings with senior DHS architecture officials and supporting 
contractor personnel, they agreed with our finding. 

3. We acknowledge the department's comment that the business strategy 
and vision statement were not within the scope of the initial 
architecture description. However, we note that this comment is 
inconsistent with DHS's intent to describe the top two rows of the 
Zachman framework, because these rows include this information. 
Moreover, as stated in our report, best practices require that the 
architecture be based on the business strategy and states that to do 
otherwise negatively affects the architecture's utility and makes it 
unlikely that changes to existing operations and systems will provide 
for optimum mission performance and satisfaction of stakeholders' 
needs. In addition, while we do not question that the business strategy 
and vision statement are included in DHS's strategic plan, we did not 
evaluate this plan because it was issued 5 months after the approval of 
Version 1. 0. Further, when we concluded our analysis and shared our 
findings with senior DHS architecture officials and supporting 
contractor personnel, they agreed with our findings. 

4. As stated in the report, we do not question the department's intent 
for Version 1. 0 of the architecture or whether these goals have been 
achieved. However, our analysis shows that important architecture 
artifacts that would be expected to be included in this version and 
that are associated with the top two rows of the Zachman framework were 
not included in the architecture description. 

5. We acknowledge the department's comment that Version 1. 0 of the 
architecture did not contain measurable strategic business objectives 
or tactical business goals, as evidenced by our finding that this 
information was missing. In addition, while we do not question that 
this information is included in DHS's strategic plan, we would note 
that we did not evaluate this plan because it was issued 5 months after 
the approval of Version 1. 0. With respect to the governance strategy 
and plan, the former outlined the steps to be taken to develop such a 
strategy, and the latter was not contained within Version 1. 0, nor was 
it provided separately. Further, as previously noted, we do not 
question the intent of Version 1. 0. Further, when we concluded our 
analysis and shared our findings with senior DHS architecture officials 
and supporting contractor personnel, they agreed with our findings. 

6. We disagree. While we acknowledge that there are high-level business 
functions and activities in the business model, the model did not 
define business processes. Business process descriptions have a 
definitive beginning and end and reflect the interrelationships among 
business functions and activities. The functions and activities 
described in Version 1. 0 had not been decomposed to a sufficient level 
of operational detail to describe routine tasks (e. g. , develop 
mitigation strategies to minimize the impact of the threat). Further, 
when we concluded our analysis and shared our findings with 
architecture officials and supporting contractor personnel, they agreed 
with the criteria and with our findings. 

7. Version 1. 0 of the architecture did not include a communications 
plan, nor was such a plan provided separately. However, we do agree 
that effective management reporting will depend on DHS's ability to 
collect the right information for the architecture program. 

8. The organizational chart referred to in this comment was not 
provided to GAO. 

9. We disagree. While we acknowledge that the architecture contains a 
high-level or abstract conceptual data model, we found that the model 
lacked the information for the business owner's view of data and for 
the creation of a conceptual data model that can be used to develop the 
logical database model as required by the Zachman framework, which DHS 
has acknowledged that it is following to develop its architecture. 
Specifically, this would require that the conceptual data model 
(1) include concrete business objects, (2) enable facts about the 
business to be derived, and (3) facilitate the development and 
validation of business rules. Further, when we concluded our analysis 
and shared our findings with senior DHS architecture officials and 
supporting contractor personnel, they agreed with the criteria and our 
findings. 

10. The focus of our review was the content of Version 1. 0 of the 
architecture. We did not evaluate the "OneDHS" initiative as part of 
this effort because it was identified in the architecture as a 
conceptual project. 

11. We disagree. While we acknowledge that the architecture indicated 
the need to perform project-specific gap analyses, these analyses were 
not included in Version 1. 0, and DHS did not provide any evidence that 
such analyses had been performed. In addition, the department did not 
provide a time frame for completing them. Further, when we concluded 
our analysis and shared our findings with senior DHS architecture 
officials and supporting contractor personnel, they agreed with our 
findings. 

12. We disagree. While we acknowledge that conceptual projects were 
linked with proposed IT investments (i. e. , exhibit 300s), the 
architecture did not show the correlation among the projects and the 
potential investments. To show this correlation, DHS would have needed 
to reflect the extent to which the identified business need--which 
should be based on a gap analysis--would be addressed by the proposed 
investment, and this explanation would be documented within the 
architecture. However, the architecture did not contain this 
information or a time frame for when it would be provided. The 
architecture also did not include information on the approval status of 
these proposed investments. Further, when we concluded our analysis and 
shared our findings with senior DHS architecture officials and 
supporting contractor personnel, they agreed with our findings. 

13. We disagree. Version 1. 0 of the DHS architecture does not provide 
sufficient information to differentiate between existing and new 
systems. In addition, the architecture did not include an analysis that 
identified existing systems that would be terminated. Further, when we 
concluded our analysis and shared our findings with senior DHS 
architecture officials and supporting contractor personnel, they agreed 
with our findings. 

14. We disagree. The architecture does not contain detailed training 
approaches, strategies, or plans. Instead, the architecture contains 
high-level briefings that refer to planned activities to determine the 
needs for training based on anticipated changes. These needs, once 
identified, may be used to develop a business-specific plan for change 
management and training. Further, when we concluded our analysis and 
shared our findings with senior DHS architecture officials and 
supporting contractor personnel, they agreed with our findings. 

15. We disagree. While we acknowledge that the architecture listed the 
names of both existing systems and several systems under development, 
it did not identify which of these systems would be developed, 
modified, acquired, and/or used as intermediate systems until the 
target system has been deployed to meet specific future business needs. 
Further, when we concluded our analysis and shared our findings with 
senior DHS architecture officials and supporting contractor personnel, 
they agreed with our findings. 

16. We disagree. We acknowledge that the architecture included a 
sequencing diagram that graphically associated the components and the 
conceptual projects. However, the architecture did not provide either 
an explanation of the graphically depicted relationships or an analysis 
of the interdependencies. DHS also did not provide evidence that such 
an analysis had been performed. Further, when we concluded our analysis 
and shared our findings with senior DHS architecture officials and 
supporting contractor personnel, they agreed with our findings. 

[End of section]

Appendix V: GAO Contact and Staff Acknowledgments: 

GAO Contact: 

Cynthia Jackson, (202) 512-5086: 

Staff Acknowledgments: 

Staff who made key contributions to this report were Joseph Cruz, 
Joanne Fiorino, Anh Le, Randolph Tekeley, and William Wadsworth.

(310272): 

FOOTNOTES

[1] U.S. General Accounting Office, High-Risk Series: An Update, 
GAO-03-119 (Washington, D.C.: January 2003) and Major Management 
Challenges and Program Risks: Department of Homeland Security, 
GAO-03-102 (Washington, D.C.: January 2003).

[2] An enterprise architecture is a blueprint that defines, both in 
logical terms (including interrelated business processes and business 
rules, integrated functions, applications, systems, users, work 
locations, and information needs and flows) and in technical terms 
(including hardware, software, data, communications, and security), how 
an organization's information technology systems operate today, how 
they are to operate in the future, and a road map for the transition.

[3] See, for example, U.S. General Accounting Office, Information 
Technology: Architecture Needed to Guide NASA's Financial Management 
Modernization, GAO-04-43 (Washington, D.C.: Nov. 21, 2003); DOD 
Business Systems Modernization: Important Progress Made to Develop 
Business Enterprise Architecture, but Much Work Remains, GAO-03-1018 
(Washington, D.C.: Sept. 19, 2003); Information Technology: DLA Should 
Strengthen Business Systems Modernization Architecture and Investment 
Activities, GAO-01-631 (Washington, D.C.: June 29, 2001) and 
Information Technology: INS Needs to Better Manage the Development of 
Its Enterprise Architecture, AIMD-00-212 (Washington, D.C.: Aug. 1, 
2000).

[4] The Federal Enterprise Architecture (FEA) is a collection of five 
"reference models" developed by the Office of Management and Budget, 
which are intended to provide a governmentwide framework to guide and 
constrain federal agencies' enterprise architectures and information 
technology investments.

[5] For purposes of this review, we mapped the department's 
architecture to the FEA's business, services, and technical reference 
models.

[6] Homeland Security Act of 2002 (Public Law 107-296, Nov. 25, 2002).

[7] GAO-03-119.

[8] See, for example, U.S. General Accounting Office, Information 
Technology: Architecture Needed to Guide NASA's Financial Management 
Modernization, GAO-04-43 (Washington, D.C.: Nov. 21, 2003); DOD 
Business Systems Modernization: Important Progress Made to Develop 
Business Enterprise Architecture, but Much Work Remains, GAO-03-1018 
(Washington, D.C.: Sept. 19, 2003); Information Technology: DLA Should 
Strengthen Business Systems Modernization Architecture and Investment 
Activities, GAO-01-631 (Washington, D.C.: June 29, 2001); and 
Information Technology: INS Needs to Better Manage the Development of 
Its Enterprise Architecture, AIMD-00-212 (Washington, D.C.: Aug. 1, 
2000).

[9] E-Government Act of 2002, Public Law 107-347 (Dec. 17, 2002).

[10] J. A. Zachman, "A Framework for Information Systems Architecture," 
IBM Systems Journal 26, no. 3 (1987).

[11] 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.: Feb. 28, 2003); Information Technology: DLA Should Strengthen 
Business Systems Modernization Architecture and Investment Activities, 
GAO-01-631 (Washington, D.C.: June 29, 2001); and Information 
Technology: INS Needs to Better Manage the Development of Its 
Enterprise Architecture, AIMD-00-212 (Washington, D.C.: Aug. 1, 2000).

[12] U.S. General Accounting Office, National Preparedness: Integrating 
New and Existing Technology and Information Sharing into an Effective 
Homeland Security Strategy, GAO-02-811T (Washington, D.C.: June 7, 
2002).

[13] U.S. General Accounting Office, Homeland Security: Information 
Sharing Responsibilities, Challenges, and Key Management Issues, 
GAO-03-715T (Washington, D.C.: May 8, 2003).

[14] U.S. General Accounting Office, Homeland Security: Efforts to 
Improve Information Sharing Need to Be Strengthened, GAO-03-760 
(Washington, D.C.: Aug. 27, 2003). 

[15] U.S. General Accounting Office, Information Technology: Leadership 
Remains Key to Agencies Making Progress on Enterprise Architecture 
Efforts, GAO-04-40 (Washington, D.C.: Nov. 17, 2003). 

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

[17] U. S. General Accounting Office, Information Technology: Homeland 
Security Should Better Balance Need for System Integration Strategy 
with Spending for New and Enhanced Systems, GAO-04-509 (Washington, 
D.C.: May 21, 2004).

[18] Statement of Steven I. Cooper, Chief Information Officer, 
Department of Homeland Security, before the Committee on Government 
Reform, House of Representatives, May 8, 2003.

[19] Statement of Steven I. Cooper, Chief Information Officer, 
Department of Homeland Security, before the Subcommittee on Technology, 
Information Policy, Intergovernmental Relations and the Census, 
Committee on Government Reform, House of Representatives, October 8, 
2003.

[20] Budget function codes are used to describe the budget of the 
United States in terms of the major purpose served, such as national 
defense and international affairs. By grouping together functionally 
related items, regardless of the responsible agency, this 
classification enables Congress and the public to see what the 
government is doing or expects to do and, in general, focuses upon the 
ultimate purpose that the government programs are designed to solve. 

[21] This initiative is intended to support budget decision making by 
providing more useful performance information (i.e., better information 
on how inputs are used to produce outputs, which affect outcomes). 

[22] U.S. General Accounting Office, Information Technology: The 
Federal Enterprise Architecture and Agencies' Enterprise Architectures 
Are Still Maturing, GAO-04-798T (Washington, D.C.: May 19, 2004).

[23] U.S. General Accounting Office, DOD Business Systems 
Modernization: Important Progress Made to Develop Business Enterprise 
Architecture, but Much Work Remains, GAO-03-1018 (Washington, D.C.: 
Sept. 19, 2003).

[24] U.S. General Accounting Office, Executive Guide: Information 
Security Management--Learning From Leading Organizations, GAO/
AIMD-98-68 (Washington, D.C.: May 1998).

[25] These key elements are described in detail later in the report.

[26] OMB's E-Government Task Force identified 23 initiatives (two 
additional initiatives were subsequently added) aimed at improving 
service to individuals, service to businesses, intergovernmental 
affairs, and federal agency-to-agency efficiency and effectiveness.

[27] See, for example, Office of Management and Budget, Federal 
Enterprise Architecture Business Reference Model, Version 2.0 (June 
2003); 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); M.A. Cook, 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).

[28] See, for example, Office of Management and Budget, Federal 
Enterprise Architecture Business Reference Model, Version 2.0 (June 
2003); 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).

[29] Steven H. Spewak with Steven C. Hill, Enterprise Architecture 
Planning: Developing a Blueprint for Data, Applications, and Technology 
(Princeton, N.J.: John Wiley and Sons, Incorporated, 1992).

[30] The value chain provides a holistic view of business activities 
across the enterprise, showing high-level business functions that are 
central to mission fulfillment and add value to the services provided 
by the enterprise. The value chain cuts across organizational 
boundaries. 

[31] A CURE (create, update, reference, and eliminate) matrix shows the 
business functions and applications that create, update, reference, 
and/or eliminate specific data elements, enabling the organization to 
develop applications.

[32] Office of Management and Budget, Preparation, Submission, and 
Execution of the Budget, Circular No. A-11 (July 25, 2003; revised Nov. 
14, 2003).

[33] Office of Management and Budget, Enterprise Architecture 
Assessment Framework, Version 1.0, April 2004.

[34] GAO-04-798T.

[35] See, for example, DOD Business Systems Modernization: Important 
Progress Made to Develop Business Enterprise Architecture, but Much 
Work Remains, GAO-03-1018 (Washington, D.C.: Sept. 19, 2003).

[36] GAO-03-1018.

[37] See, for example, U.S. General Accounting Office, Information 
Technology: Architecture Needed to Guide NASA's Financial Management 
Modernization, GAO-04-43 (Washington, D.C.: Nov. 21, 2003); and DOD 
Business Systems Modernization: Important Progress Made to Develop 
Business Enterprise Architecture, but Much Work Remains, GAO-03-1018 
(Washington, D.C.: Sept. 19, 2003).

[38] See, for example, Office of Management and Budget (OMB), Federal 
Enterprise Architecture Business Reference Model, Version 2.0 (June 
2003); Chief Information Officers Council, A Practical Guide to Federal 
Enterprise Architecture, Version 1.0 (February 2001); OMB, Management 
of Federal Information Resources, Circular No. A-130 (Nov. 28, 2000); 
M.A. Cook, 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).

[39] GAO-04-43.

[40] GAO-04-43.

[41] The architecture satisfies all aspects of this key architectural 
element.

[42] The architecture partially satisfies some aspects of this key 
architectural element but does not satisfy at least one significant 
aspect.

[43] The architecture does not satisfy any aspects of this key 
architectural element.

[44] OMB has not officially released the data reference model.

[45] OMB has not yet developed a "security profile" for the FEA.

[46] For purposes of this report, we defined semantic alignment to mean 
that the department's architecture and the FEA reference models use 
similar terms and/or definitions that can be mapped to one another. We 
defined functional alignment to mean that the architecture and the 
reference models have been decomposed to the same level of detail to 
determine if the business operations, services, and technology 
components are similar in nature and purpose. We defined structural 
alignment to mean that the architecture and the reference models are 
both constructed similarly, for example, they may share the same 
hierarchical construct whereby information is grouped by common levels 
of detail.

GAO's Mission: 

The Government Accountability 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. Government Accountability Office

441 G Street NW, Room LM

Washington, D.C. 20548: 

To order by Phone: 



Voice: (202) 512-6000: 

TDD: (202) 512-2537: 

Fax: (202) 512-6061: 

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

Contact: 

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

E-mail: 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. Government Accountability Office,

441 G Street NW, Room 7149

Washington, D.C. 20548: