A Practical GuidetoFederal Enterprise ArchitectureCh.docx

A Practical Guide
to
Federal Enterprise Architecture
Chief Information Officer Council
Version 1.0
February 2001
iii
February 2001
Preface
An enterprise architecture (EA) establishes the Agency-wide
roadmap to achieve an Agency�s mission
through optimal performance of its core business processes
within an efficient information technology
(IT) environment. Simply stated, enterprise architectures are
�blueprints� for systematically and
completely defining an organization�s current (baseline) or
desired (target) environment. Enterprise
architectures are essential for evolving information systems and
developing new systems that optimize
their mission value. This is accomplished in logical or business
terms (e.g., mission, business functions,
information flows, and systems environments) and technical
terms (e.g., software, hardware,

communications), and includes a Sequencing Plan for
transitioning from the baseline environment to the
target environment.
If defined, maintained, and implemented effectively, these
institutional blueprints assist in optimizing the
interdependencies and interrelationships among an
organization�s business operations and the underlying
IT that support operations. The experience of the Office of
Management and Budget (OMB) and General
Accounting Office (GAO) has shown that without a complete
and enforced EA, federal agencies run the
risk of buying and building systems that are duplicative,
incompatible, and unnecessarily costly to
maintain and integrate.
For EAs to be useful and provide business value, their
development, maintenance, and implementation
should be managed effectively. This step-by-step process guide
is intended to assist agencies in defining,
maintaining, and implementing EAs by providing a disciplined
and rigorous approach to EA life cycle
management. It describes major EA program management
areas, beginning with suggested
organizational structure and management controls, a process for
development of a baseline and target
architecture, and development of a sequencing plan. The guide
also describes EA maintenance and
implementation, as well as oversight and control. Collectively,
these areas provide a recommended
model for effective EA management.
Background
Reflecting the general consensus in industry that large, complex
systems development and acquisition

efforts should be guided by explicit EAs, Congress required
Federal Agency Chief Information Officers
to develop, maintain, and facilitate integrated systems
architectures with the passage of the Clinger-Cohen
Act1in 1996. Additionally, OMB has issued guidance that
requires agency information systems
investments to be consistent with Federal, Agency, and bureau
architectures. Other OMB guidance
provides for the content of Agency enterprise architectures.2
Similarly, the Chief Information Officer
Council, the Department of the Treasury, the National Institute
of Standards Technology (NIST), and
GAO, have developed architecture frameworks or models that
define the content of enterprise
architectures.3
1 Public Law 104-106, section 5125, 110 Stat. 684 (1996).
2 OMB Circular A-130, Management of Federal Information
Resources, November 30, 2000.
3 Federal Enterprise Architecture Framework, Version 1.1,
Federal Chief Information Officers Council, September
1999; Treasury Enterprise Architecture Framework, Version 1,
the Department of the Treasury, July 3, 2000; the
National Institute of Standards and Technology�s Enterprise
Architectural Model, referenced in NIST Special
Publication 500-167, Information Management Directions: the
Integration Challenge; and Strategic Information
Planning: Framework for Designing and Developing System
Architectures (GAO/IMTEC-92-51, June 1992).
A Practical Guide to Federal Enterprise Architecture Preface
iv

February 2001
This guide builds upon, complements, and is directly linked to
the GAO Information Technology
Investment Management (ITIM) framework4 that was developed
to provide a common structure for
discussing and assessing IT capital planning and investment
control (CPIC) practices at Federal Agencies.
ITIM enhances earlier Federal IT investment management
guidance by extending the
Select/Control/Evaluate approach, mandated by the Clinger-
Cohen Act, into a growth and maturity
framework.5 It is also directly linked to the Federal Enterprise
Architecture Framework.
The Need for this Guide
While these frameworks and models provide valuable guidance
on the content of enterprise architectures,
there is literally no ffeeddeerraall guidance how to successfully
manage the process of creating, changing, and
using the enterprise architecture. This guidance is crucially
important. Without it, it is highly unlikely
that an organization can successfully produce a complete and
enforceable EA for optimizing its systems�
business value and mission performance. For example,
effective development of a complete EA needs a
corporate commitment with senior management sponsorship.
The enterprise architecture development
should be managed as a formal project by an organizational
entity that is held accountable for success.
Since the EA facilitates change based upon the changing
business environment of the organization, the
architect is the organization�s primary change agent. Effective
implementation requires establishment of
system compliance with the architecture, as well as continuous

assessment and enforcement of
compliance. Waiver of these requirements may occur only after
careful, thorough, and documented
analysis. Without these commitments, responsibilities, and
tools, the risk is great that new systems will
not meet business needs, will be incompatible, will perform
poorly, and will cost more to develop,
integrate, and maintain than is warranted.
Conclusion
The processes described in this guide represent fundamental
principles of good EA management. Since
the guide is not a one-size-fits-all proposition, Agencies or
organizations should adapt its
recommendations and steps to fit their individual needs. We
encourage you to consider these EA
processes and best practices carefully before pursuing other
approaches.
An electronic version of this guide is available at the following
Internet address: http://www.cio.gov.
If you have questions or comments about this guide, please
contact Rob C. Thomas II at (703) 921-6425,
by email at [email protected], or by mail at:
U.S. Customs Service
7681 Boston Boulevard
Springfield, VA 22153
4 Information Technology Investment Management: A
Framework for Assessing and Improving Process Maturity
(GAO/AIMD-10.1.23, Exposure Draft, 2000).
5 In the Select Phase, the costs and benefits of all available

projects are assessed and the optimal portfolio of projects
is selected. During the Control Phase, the portfolio is
monitored and corrective action is applied where needed. In
the Evaluate Phase, implemented projects are reviewed to
ensure that they are producing the benefits expected and
adjustments are made where appropriate.
mailto:[email protected]
v
February 2001
Credits
This document was produced by the Federal Architecture
Working Group (FAWG) under the strategic
direction of the Enterprise Interoperability and Emerging
Information Technology Committee (EIEITC)
of the Federal Chief Information Officer Council.
The following persons contributed to accomplishing this Guide.
Name Title Agency
Rob C. Thomas, II Dir., Tech. & Arch. Group, Chief Architect
U.S. Customs Service
Randolph C. Hite Dir., Information Technology Systems Issues
General Accounting Office
Ray Beamer Senior Principal Scientist The MITRE Corporation
William H. McVay Senior Policy Analyst Office of Management
and Budget
Elaine Ward Principal Engineer The MITRE Corporation
Keith Rhodes Chief Technologist General Accounting Office
Mary Lou Collins Lead Engineer The MITRE Corporation

George Brundage Chief Architect U.S. Department of the
Treasury
Scott Bernard Management Consultant Booz-Allen & Hamilton,
Inc.
Lester Diamond Assistant Director General Accounting Office
Michael A. Tiemann Dir., Arch. & Stnds. Div., Chief Architect
U.S. Department of Energy
Thomas P. Cullen Policy Analyst U.S. Customs Service
William Lew Technical Assistant Director General Accounting
Office
John Anderson Principal Engineer The MITRE Corporation
Daryl Knuth Information Architect U.S. Customs Service
Barbara Scott Management Analyst U.S. Department of
Education
Paul J. Paradis Management Analyst U.S. Department of Energy
Naba Barkakati Technical Assistant Director General
Accounting Office
Kathy Sowell Lead Engineer The MITRE Corporation
Wayne Shiveley Senior Computer Scientist Federal Bureau of
Investigation
vi
February 2001
vii
February 2001
Table of Contents
Prefaceiii

1.
Introduction............................................................................
............................................................. 1
1.1.
Purpose...................................................................................
..................................................... 1
1.2.
Scope......................................................................................
..................................................... 1
1.3. Audience
...............................................................................................
...................................... 1
1.4. Document Organization
...............................................................................................
............... 2
1.5. How to Use this Guide
...............................................................................................
................. 3
1.6. Related Documents
...............................................................................................
...................... 4
2. Definitions, Drivers, and Principles
...............................................................................................
... 5
2.1. Enterprise Architecture Defined
...............................................................................................
.. 5

2.2. The Uses and Benefits of Enterprise Architecture
...................................................................... 5
2.3. Legislation and other Guidance
...............................................................................................
... 6
2.4. Architecture
Principles................................................................................
................................ 7
2.5. The Enterprise Life Cycle
...............................................................................................
............ 8
2.6. The Enterprise Architecture Process
........................................................................................... 9
3. Initiate Enterprise Architecture
Program..................................................................................
.... 11
3.1. Obtain Executive Buy-in and Support
...................................................................................... 11
3.1.1. Ensure Agency Head Buy-in and Support
................................................................... 11
3.1.2. Issue an Executive Enterprise Architecture Policy
...................................................... 11
3.1.3. Obtain Support from Senior Executives and Business
Units....................................... 12
3.2. Establish Management Structure and
Control........................................................................... 13
3.2.1. Establish a Technical Review Committee
................................................................... 14

3.2.2. Establish a Capital Investment Council
....................................................................... 14
3.2.3. Establish an EA Executive Steering Committee
.......................................................... 14
3.2.4. Appoint Chief
Architect.................................................................................
.............. 14
3.2.5. Establish an Enterprise Architecture Program
Management Office ............................ 15
3.3. Enterprise Architecture Program Activities and Products
........................................................ 17
3.3.1. Develop an EA Marketing Strategy and Communications
Plan .................................. 17
3.3.2. Develop an EA Program Management Plan
................................................................ 18
3.3.3. Initiate Development of the Enterprise Architecture
................................................... 18
4. Define an Architecture Process and Approach
.............................................................................. 21
4.1. Define the Intended Use of the
Architecture.......................................................................... ..
. 22
4.2. Define the Scope of the Architecture
........................................................................................ 22
4.3. Determine the Depth of the Architecture
.................................................................................. 22
4.4. Select Appropriate EA Products
...............................................................................................
23
4.4.1. Select Products that Represent the Business of the

Enterprise .................................... 23
4.4.2. Select Products that Represent Agency Technical Assets
........................................... 24
4.5. Evaluate and Select a Framework
.............................................................................................
24
4.5.1. Federal Enterprise Architecture Framework
................................................................ 25
A Practical Guide to Federal Enterprise Architecture Contents
viii
February 2001
4.5.2. DoD C4ISR Architecture
Framework..........................................................................
27
4.5.3. Treasury Enterprise Architecture
Framework.............................................................. 28
4.6. Select an EA
Toolset....................................................................................
............................. 30
5. Develop the Enterprise Architecture
..............................................................................................
33
5.1. Collect Information
...............................................................................................
.................... 34
5.2. Generate Products and Populate EA

Repository....................................................................... 35
5.2.1. Essentials in Building the Baseline Architecture
......................................................... 36
5.2.2. Essentials in Building the Target Architecture
............................................................ 36
5.2.3. Review, Validate, and Refine Models
......................................................................... 38
5.3. Develop the Sequencing Plan
...............................................................................................
.... 38
5.3.1. Identify
Gaps.......................................................................................
......................... 39
5.3.2. Define and Differentiate Legacy, Migration, and New
Systems ................................. 39
5.3.3. Planning the Migration
...............................................................................................
. 40
5.4. Approve, Publish, and Disseminate the EA Products
............................................................... 41
6. Use the Enterprise Architecture
...............................................................................................
....... 43
6.1. Integrate the EA with CPIC and SLC
Processes....................................................................... 43
6.1.1. Train Personnel
...............................................................................................
............. 45
6.1.2. Establish Enforcement Processes and Procedures
....................................................... 45
6.2. Execute the Integrated Process

...............................................................................................
.. 47
6.2.1. Initiate New and Follow-on Projects
........................................................................... 47
6.2.2. Execute the Projects
...............................................................................................
...... 51
6.2.3. Complete the
Project....................................................................................
................ 52
6.3. Other Uses of the EA
...............................................................................................
................. 54
7. Maintain the Enterprise Architecture
............................................................................................
55
Maintain the Enterprise Architecture as the Enterprise Evolves
........................................................ 55
7.1.1. Reassess the Enterprise Architecture Periodically
....................................................... 55
7.1.2. Manage Products to Reflect
Reality............................................................................. 56
7.2. Continue to Consider Proposals for EA
Modifications............................................................. 57
8. Continuously Control and Oversee the Enterprise
Architecture Program................................. 59
8.1. Ensure Necessary EA Program Management Controls Are
In Place and Functioning............. 59
8.2. Identify Where EA Program Expectations Are Not Being

Met................................................ 59
8.3. Take Appropriate Actions to Address Deviations
.................................................................... 60
8.4. Ensure Continuous
Improvement...........................................................................
................... 60
9. Summary
...............................................................................................
............................................ 63
Appendix A: EA Roles and
Responsibilities.......................................................................
.................... 65
Appendix B:
Glossary..................................................................................
............................................. 67
Appendix C: Acronyms
...............................................................................................
............................. 71
Appendix D: Example Architecture
Products..................................................................................
...... 73
D.1. Mission and Vision
Statements...............................................................................
.................. 73
A Practical Guide to Federal Enterprise Architecture Contents

ix
February 2001
D.2. Information Dictionary
...............................................................................................
.............. 73
D.3. Concept of Operations (CONOPS) Graphic
............................................................................. 74
D.4. Activity Models and Trees
...............................................................................................
......... 76
D.5. Business Use Case Model
...............................................................................................
.......... 78
D.6. Class Model
...............................................................................................
............................... 81
D.7. State Model
...............................................................................................
................................ 82
D.8. Node Connectivity
Diagrams.................................................................................
................... 83
D.9. Information Exchange Matrix
.......................................................................................... .....
.... 86
D.10. Organization

Chart......................................................................................
.............................. 87
D.11. Systems Interface Description and Connectivity Diagram
....................................................... 88
D.12. Standards Profile
...............................................................................................
........................ 89
D.13. Technical Reference Model
...............................................................................................
....... 90
Appendix E: Sample Architectural Principles
....................................................................................... 93
Appendix F:
Bibliography...........................................................................
............................................. 97
Appendix G: The Zachman Framework
..............................................................................................
101
x
February 2001
List of Figures
Figure 1. Role of Architecture Principles
...............................................................................................
..... 7
Figure 2. The Enterprise Life

Cycle............................................................................ ..........
....................... 8
Figure 3. The Enterprise Architecture Process
.............................................................................................
9
Figure 4. Notional EA Organization
...............................................................................................
............ 13
Figure 5. Depth and Detail of the
Architecture............................................................................
............... 21
Figure 6. Structure of the FEAF Components
............................................................................................
26
Figure 7. FEAF Architecture
Matrix.....................................................................................
..................... 26
Figure 8. DoD C4ISR Framework
...............................................................................................
.............. 27
Figure 9. DoD C4ISR Products
...............................................................................................
.................. 28
Figure 10. The Treasury Enterprise Architecture Framework
................................................................... 29
Figure 11. TEAF Products
.................................................................................... ...........
.......................... 30
Figure 12. Example Approach for EA
Development...........................................................................
...... 33
Figure 13. Systems Migration Chart
...............................................................................................
........... 40
Figure 14. IMP/Architecture Project Assessment Framework
.................................................................. 44

Figure 15. Architecture Management
...............................................................................................
.......... 45
Figure 16. Define New and Follow-on Programs/Projects
........................................................................ 48
Figure 17. Execute Programs/Projects
...............................................................................................
......... 51
Figure 18. Evaluate Programs/Projects
...............................................................................................
........ 53
Figure 19. Enterprise Architecture Transition
............................................................................................
56
Figure 20. Key Success Factors
...............................................................................................
................... 61
Figure 21. DoD Battlespace Concept of Operations Graphic
..................................................................... 74
Figure 22. U.S. Customs Service Trade Compliance Concept of
Operations Graphic............................... 75
Figure 23. Generic IDEF Activity Model
...............................................................................................
.... 77
Figure 24. U.S. Customs, ACS, Activity Tree
............................................................................................
77
Figure 25. U.S. Customs, Trade Compliance, UML Activity
Model ......................................................... 78
Figure 26. U.S. Customs, Trade Compliance�External, UML
Use Case Diagram .................................. 79
Figure 27. U.S. Customs, Trade Compliance�Internal, UML
Use Case Diagram ................................... 79
Figure 28. U.S. Customs, Trade Compliance, Declare Goods,
UML Use Case Specification ................... 80
Figure 29. U.S. Customs, Trade Compliance, Commercial View,

UML Class Diagram........................... 81
Figure 30. U.S. Customs, Trade Compliance, Carrier, UML
State Diagram ............................................. 82
Figure 31. U.S. Customs, ACS, Customs Systems, Node
Connectivity Diagram ...................................... 84
Figure 32. U.S. Customs, ACS, N2
Chart......................................................................................
.............. 85
Figure 33. U.S. Air Force Node Connectivity Diagram
............................................................................. 86
Figure 34. Generic Organization
Chart......................................................................................
................. 88
Figure 35. Generic System Interface Description Connectivity
Diagram .................................................. 89
Figure 36. Standards Profile Table
...............................................................................................
.............. 90
Figure 37. U.S. Customs Technical Reference
Model................................................................................ 90
Figure 38. Generic TRM Domain and Sub-domain Definitions
and Components ..................................... 91
Figure 39. The Zachman Framework
Matrix.....................................................................................
....... 102
xi
February 2001
List of Tables
Table 1. EAPMO Roles and Responsibilities
.............................................................................................
17

Table 2. Framework Selection Criteria
...............................................................................................
....... 25
Table 3. Tool Selection Criteria
...............................................................................................
.................. 31
Table 4. Baseline and Target Architecture Differentiators
........................................................................ 35
Table 5. EA Review
Goals......................................................................................
.................................... 50
Table 6. Example Logical Information Exchange Matrix
......................................................................... 87
1
February 2001
1. Introduction
1.1. Purpose
The purpose of this document is to provide guidance to Federal
Agencies in initiating,
developing, using, and maintaining an enterprise architecture
(EA). This guide offers an end-to-
end process to initiate, implement, and sustain an EA program,
and describes the necessary roles
and associated responsibilities for a successful EA program.
An EA establishes the Agency-wide roadmap to achieve an
Agency�s mission through optimal
performance of its core business processes within an efficient
information technology (IT)
environment. Simply stated, enterprise architectures are

�blueprints� for systematically and
completely defining an organization�s current (baseline) or
desired (target) environment.
Enterprise architectures are essential for evolving information
systems, developing new systems,
and inserting emerging technologies that optimize their mission
value. While some agencies have
enterprise architectures in place, others do not. For agencies
that already have an EA in place,
this guide should be tailored to fit these Agencies� needs. For
smaller agencies, a streamlined
version of the guide should be created to support the needs of
the Agency.
1.2. Scope
This guide focuses on EA processes, products, and roles and
responsibilities. While this guide
addresses the enterprise life cycle, it describes in detail how the
EA processes relate to enterprise
engineering, program management, and capital planning and
investment control (CPIC)
processes.
The breadth and depth of information presented here should be
tailored to your organization.
Some examples are presented in the appendices, and references
to supplementary material are
included in the text or bibliography. Feel free to individualize
these examples as needed.
1.3. Audience
This guide is intended primarily for Federal Agency architects
tasked with the generation and
institutionalization of EAs. This document provides guidance

to Agencies that currently do not
have EAs and those that can benefit from improvements in their
EA methods for development
and maintenance. For Agencies without an EA, this document
provides useful guidance to the
Agency Head and the Chief Information Officer (CIO) for
educating and obtaining key
stakeholder commitment in establishing an effective EA.
This guide is also aimed at CPIC process participants [e.g.,
investment review boards, and the
Office of Management and Budget (OMB)], as well as
enterprise engineering and program
management process participants (e.g., program/project
managers, systems engineers, application
architects, systems developers, configuration managers, risk
managers, and security engineers).
Although the guide specifically addresses the roles and
responsibilities of major players in the
architecture development process, it is also a handbook for
anyone who needs to know more
about the EA process. Regardless of your role or
responsibility�whether you have sole
responsibility for EA development or are a member of an
architecture team�if you are involved
in the enterprise life cycle, this guide is for you.
A Practical Guide to Federal Enterprise Architecture
Introduction
2
February 2001

1.4. Document Organization
The document is organized as follows:
Section 1: Introduction Defines the purpose, scope, audience,
and
organization of the document.
Section 2: Definitions, Drivers,
and Principles
Presents the context for the EA process, i.e.,
principles and legislative drivers, and defines the
architecture development, implementation, and
maintenance process.
Section 3: Initiate Enterprise
Architecture
Program
Defines EA program procedural steps to initiate the
program, typical EA organization, and products of
the EA.
Section 4: Define an
Architecture Process
and Approach
Defines a process for building an enterprise
architecture and describes federally developed
frameworks.
Section 5: Develop the
Enterprise
Architecture

Provides the procedural steps for developing baseline
and target architectures and a sequencing plan.
Section 6: Use the Enterprise
Architecture
Demonstrates how the EA process interacts with
capital planning and investment control and with the
Systems Life Cycle.
Section 7: Maintain the
Enterprise
Architecture
Discusses processes and procedures to maintain EA
products throughout the life-cycle process.
Section 8: Continuously
Control and Oversee
the EA Program
Section 9: Summary
Provides guidelines to ensure EA processes and
practices are being followed and remedies and
corrective actions applied when warranted.
Presents highlights of the EA guide and provides
final recommendations for the initiation and
implementation of a successful EA program.
Appendix A: EA Roles and
Responsibilities
Provides a concise description of key personnel roles
and responsibilities for EA development,

implementation, and maintenance.
Appendix B: Glossary Provides a definition of terms used
within this
document.
Appendix C: Acronyms Provides a list of all acronyms used
within this
document.
Appendix D: Example
Architecture
Products
Provides sample EA essential and supporting
products.
Introduction
3
February 2001
Appendix E: Sample
Architectural
Principles
Describes samples of the essential architectural
principles that are a starting point in the architecture
process.
Appendix F: Bibliography Provides a list of key documents used
during the
development of this guide and other informative

source documentation.
Appendix G: The Zachman
Framework
Presents a brief background and description of the
Zachman Framework and its application to enterprise
architecture.
1.5. How to Use this Guide
This guide is a �how-to� manual for Federal Agency architects
and stakeholders in the initiation,
development, use, and maintenance of EAs. To find an answer
to your specific need or question,
please consult the following table for frequently asked
questions. These and many other
questions are answered throughout the guide.
Question Section
1. Why develop an EA? 2.0
2. What are the primary benefits of using an EA? 2.0
3. What are the legislative drivers and mandates for using an
EA?
2.0
4. What is the Enterprise Life Cycle? 2.0
5. What is a baseline architecture? 2.0
6. What is a target architecture? 2.0

7. What is a sequencing plan? 2.0
8. How does the EA process relate to the CPIC process? 3.0
9. Who is responsible for architecture policies? 3.0
10. Who is responsible for the EA? 3.0
11. How does one market the selected approach to senior
executives?
3.0
12. What are frameworks and how do I select one? 4.0
13. How do I create a baseline or target architecture? 5.0
14. How do I transition from the baseline to the target? 5.0
15. How is the EA used within the CPIC process to justify
information technology investments?
6.0
16. How do architecture processes relate to other enterprise
engineering activities?
6.0
17. How does a project manager or application architect ensure
alignment to the EA when proposing a new project?
6.0
18. How do I maintain the EA in the midst of evolving systems
and new business requirements?

7.0
19. What are the organizational roles and responsibilities when
Appendix A
Introduction
4
February 2001
Question Section
developing and maintaining an EA?
20. What do architectural products look like? Appendix D
21. What are EA architectural principles? 2.0 and Appendix E
22. Where can I find more EA information? Appendix F and G
1.6. Related Documents
• Federal Enterprise Architecture Framework (FEAF), issued by
the Federal CIO Council,
dated September 1999.
The FEAF provides guidance for developing, maintaining, and
facilitating enterprise architectures
in the Federal government.
• Architecture Alignment and Assessment Guide, produced for
the Federal CIO Council by the
Federal Architecture Working Group (FAWG), dated October

2000.
• Smart Practices in Capital Planning, produced by the FAWG
and the Capital Planning and
IT Management Committee, dated October 2000.
Together with GAO and OMB guidance, these documents
provide guidance on the interaction
and integration of the CPIC and EA processes. Collectively,
these documents describe the CPIC
and EA processes working as a governance mechanism to ensure
successful organizational
change and information technology (IT) investments to support
that change.
See Appendix F for a complete listing of reference
documentation.
5
February 2001
2. Definitions, Drivers, and Principles
2.1. Enterprise Architecture Defined
EA terminology carries many variations within
each organization and in the vast array of
literature. Therefore, the authors have settled on
one consistent set of definitions for key terms
used within this guide. The definition for
Enterprise Architecture is the endorsed
definition from the Federal CIO Council and
appears in the September 1999 version of the
FEAF. Although the term enterprise is defined

in terms of an organization, it must be
understood that in many cases, the enterprise
may transcend established organizational
boundaries (e.g., trade, grant management,
financial management, logistics).
Appendix B contains a listing of additional
terms, their definitions, and the source authority.
2.2. The Uses and Benefits of Enterprise
Architecture
In general, the essential reasons for developing
an EA include:
• Alignment�ensuring the reality of the
implemented enterprise is aligned with
management�s intent
• Integration�realizing that the business
rules are consistent across the
organization, that the data and its use
are immutable, interfaces and
information flow are standardized, and
the connectivity and interoperability are
managed across the enterprise
• Change�facilitating and managing
change to any aspect of the enterprise
• Time-to-market�reducing systems
development, applications generation,
modernization timeframes, and resource
requirements
• Convergence�striving toward a

standard IT product portfolio as
contained in the Technical Reference
Model (TRM).
Key Definitions
interrelationships, and the principles and
guidelines governing their design and evolution
over time.
-
organizational entity) supporting a defined
business scope and mission. An enterprise
includes interdependent resources (people,
organizations, and technology) who must
coordinate their functions and share information
in support of a common mission (or set of related
missions).
portray the existing enterprise, the current
business practices, and technical infrastructure.
Commonly referred to as the �As-Is�
architecture.
portray the future or end-state enterprise,
generally captured in the organization�s strategic
thinking and plans. Commonly referred to as the
�To-Be� architecture.
strategy for changing the enterprise from the
current baseline to the target architecture. It
schedules multiple, concurrent, interdependent

activities, and incremental builds that will evolve
the enterprise.
graphics, models, and/or narrative that depicts
the enterprise environment and design.
information asset base, which defines the
mission, the information necessary to perform the
mission and the technologies necessary to
perform the mission, and the transitional
processes for implementing new technologies in
response to the changing mission needs. An
enterprise architecture includes a baseline
architecture, target architecture, and a sequencing
plan.
Definitions, Drivers, and Principles
6
February 2001
An EA offers tangible benefits to the enterprise and those
responsible for evolving the enterprise.
The EA can:
• Capture facts about the mission, functions, and business
foundation in an understandable
manner to promote better planning and decision making
• Improve communication among the business organizations and
IT organizations within

the enterprise through a standardized vocabulary
• Provide architectural views that help communicate the
complexity of large systems and
facilitate management of extensive, complex environments
• Focus on the strategic use of emerging technologies to better
manage the enterprise�s
information and consistently insert those technologies into the
enterprise
• Improve consistency, accuracy, timeliness, integrity, quality,
availability, access, and
sharing of IT-managed information across the enterprise
• Support the CPIC processes by providing a tool for assessment
of benefits, impacts, and
capital investment measurements and supporting analyses of
alternatives, risks, and
tradeoffs
• Highlight opportunities for building greater quality and
flexibility into applications
without increasing cost
• Achieve economies of scale by providing mechanisms for
sharing services across the
enterprise
• Expedite integration of legacy, migration, and new systems
• Ensure legal and regulatory compliance.
The primary purpose of an EA is to inform, guide, and constrain
the decisions for the enterprise,
especially those related to IT investments. The true challenge

of enterprise engineering is to
maintain the architecture as a primary authoritative resource for
enterprise IT planning. This goal
is not met via enforced policy, but by the value and utility of
the information provided by the EA.
2.3. Legislation and other Guidance
Within the Federal government, numerous rules and regulations
govern the development and
execution of IT policy. These guidelines have been established
to better manage strategic plans,
enhance IT acquisition practices, justify IT expenditures,
measure IT performance, report results
to Congress, integrate new technologies, and manage
information resources.
The Clinger-Cohen Act holds each Agency CIO responsible for
developing, maintaining, and
facilitating the implementation of an information technical
architecture. Executive Order 13011,
Federal Information Technology, established the Federal CIO
Council as the principal
interagency forum for improving practices in the design,
modernization, employment, sharing,
and performance of Agency information resources. Sections 1
through 3 of the Federal CIO
Council�s Architecture Alignment and Assessment Guide
describe IT reform and its evolution.
The guide highlights OMB guidance directed to the Federal
community, which extended IT
reform beyond the Clinger-Cohen Act. The Federal CIO
Council began developing the Federal
Enterprise Architecture Framework in April 1998 in accordance
with the priorities enunciated in
Clinger-Cohen and issued it in 1999.

7
February 2001
Additional sources of mandates and drivers for EA include:
• Government Paperwork Elimination Act (GPEA)
• Freedom of Information Act (FOIA) and Amendments
• Government Performance Results Act of 1993 (GPRA)
• OMB Circulars A�130 and A�11
• GAO Guidance, Findings, and Recommendations
• Federal CIO Council documents.
2.4. Architecture Principles
Principles establish the basis for a set of rules and behaviors for
an organization. There are
principles that govern the EA process and principles that govern
the implementation of the
architecture. Architectural principles for the EA process affect
development, maintenance, and
use of the EA. Architectural principles for EA implementation
establish the first tenets and
related decision-making guidance for designing and developing
information systems.

The Chief Architect, in conjunction with the CIO and select
Agency business managers, defines
the architectural principles that map to the organization�s IT
vision and strategic plans. As shown
in Figure 1, architectural principles should represent
fundamental requirements and practices
believed to be good for the organization. These principles
should be refined to meet Agency
business needs. It should be possible to map specific actions,
such as EA development, systems
acquisitions, and implementation, to the architectural
principles. Deliberate and explicit
standards-oriented policies and guidelines for the EA
development and implementation are
generated in compliance with the principles. Each and every
phase of the Systems Life Cycle is
supported by the actions necessitated by the architecture
principles. CPIC actions are governed
by the implications within the principles.
ActionsActions
Business NeedsBusiness NeedsStrategic PlansStrategic Plans
ImplicationsImplications
EA
Policies and Guidelines
� EA Development
� EA Use
� EA Maintenance
� EA Compliance
Principles

� EA
� Enterprise
IT Vision,
Requirements,
and Practices
IT Vision,
Requirements,
and Practices
Systems Life Cycle
� Systems Migration
� Technology Insertion
� Dual Operations
� Deployment Plans
Capital Planning and
Investment Control
� Project Selection
� Project Control
� Project Evaluation
� Return on Investment
Figure 1. Role of Architecture Principles
8
February 2001

Appendix E provides sample EA principles for consideration as
a starting point, as well as the
rationale for and the impact of implementing each principle.
Each Agency should apply, add to,
or modify these sample principles. Formulating these
supporting statements should be an
essential part of an Agency�s effort to define its principles.
2.5. The Enterprise Life Cycle
The enterprise life cycle is the dynamic, iterative process of
changing the enterprise over time by
incorporating new business processes, new technology, and new
capabilities, as well as
maintenance and disposition of existing elements of the
enterprise.
Although the EA process is the primary topic of this guide, it
cannot be discussed without
consideration of other closely related processes. These include
the enterprise engineering and
program management cycle (more commonly known as the
system development/acquisition life
cycle) that aids in the implementation of an EA, and the CPIC
process that selects, controls, and
evaluates investments. Overlying these processes are human
capital management and
information security management. When these processes work
together effectively, the
enterprise can effectively manage IT as a strategic resource and
business process enabler. When
these processes are properly synchronized, systems migrate
efficiently from legacy technology
environments through evolutionary and incremental
developments, and the Agency is able to
demonstrate its return on investment. Figure 2 illustrates the

interaction of the dynamic and
interactive cycles as they would occur over time.
Enterprise
Engineering
and
Program
Management
CPIC
Process
Modernization
Systems Migration
Operations & Maintenance
EA
Process
Sec
uri
ty
Ma
nag
em
ent
HumanResources

The
Enterprise
Life Cycle
Sy
ste
ms
Lif
e C
ycl
e
Figure 2. The Enterprise Life Cycle
9
February 2001
2.6. The Enterprise Architecture Process
As a prerequisite to the development of every enterprise
architecture, each Agency should
establish the need to develop an EA and formulate a strategy
that includes the definition of a
vision, objectives, and principles. Figure 3 shows a
representation of the EA process. Executive
buy-in and support should be established and an architectural
team created within the
organization. The team defines an approach and process tailored

to Agency needs. The
architecture team implements the process to build both the
baseline and target EAs. The
architecture team also generates a sequencing plan for the
transition of systems, applications, and
associated business practices predicated upon a detailed gap
analysis. The architecture is
employed in the CPIC and the enterprise engineering and
program management processes via
prioritized, incremental projects and the insertion of emerging
new technologies. Lastly, the
architectures are maintained through a continuous modification
to reflect the Agency�s current
baseline and target business practices, organizational goals,
visions, technology, and
infrastructure.
Obtain
Executive
Buy-In and
Support
Establish
Management
Structure
and Control
Define an
Architecture
Process
and Approach
Develop

Baseline
Enterprise
Architecture
Develop
Target
Enterprise
Architecture
Develop the
Sequencing Plan
Use
the
Enterprise
Architecture
Maintain the
Enterprise
Architecture
Section 3.1
Section 3.2
Section 4
Section 5.2
Section 5.2
Section 5.3
Section 6

Section 7
Control
and
Oversight
Control
and
Oversight
Figure 3. The Enterprise Architecture Process
10
February 2001
11
February 2001
3. Initiate Enterprise Architecture Program
The enterprise architecture is a corporate asset that should be
managed as a formal program.
Successful execution of the EA process is an Agency-wide
endeavor requiring management,
allocation of resources, continuity, and coordination. Agency
business line executives should

work closely with the Agency architecture team to produce a
description of the Agency�s
operations, a vision of the future, and an investment and
technology strategy for accomplishing
defined goals.
Experience shows that obtaining the needed cooperation among
Agency executives is not an easy
task. Creating an EA program calls for sustained leadership and
strong commitment. This degree
of sponsorship and commitment needs the buy-in of the Agency
Head, leadership by the CIO, and
early designation of a Chief Architect.
3.1. Obtain Executive Buy-in and Support
Gaining executive commitment to any new initiative requires
the development of a strong
business case and a communications approach to effectively
convey that business case. Since the
concept of an EA is not intuitively understood outside the CIO
organization, the CIO should
create a marketing strategy to communicate the strategic and
tactical value for EA development to
the Agency Head, other senior Agency executives, and business
units.
3.1.1. Ensure Agency Head Buy-in and Support
Without buy-in from the Agency Head, the CIO will find it hard
to maintain the necessary
sponsorship desired to fund and implement improved systems
and processes. The CIO takes the
lead to provide understanding and gain the Agency Head�s
buy-in. This can be accomplished by:

• Leveraging success stories from other Agency and private
sector organizations as well as
the experience and knowledge of EA experts
• Using examples to demonstrate how an EA can provide a
blueprint and roadmap for
desired changes or improvements in mission performance and
accountability
• Emphasizing the legislative requirements for developing,
maintaining, and implementing
an EA within the Federal sector.
Once the CIO is assured the Agency Head understands the need
for an EA, it is important to
secure the Agency Head�s commitment to pursue the
architecture effort. The CIO accomplishes
this by mobilizing the Agency Head�s appreciation into the
expression of clear, Agency-wide
support. This will establish a mandate to business and CIO
executives to support the effort by
allocating the needed time and resources. The CIO should
coordinate with the Agency Head on
the selection of an Agency executive to be designated as the
Chief Architect. Experience
demonstrates that the CIO�s authority alone is insufficient to
make the endeavor a success. A
clear mandate from the Agency Head is a prerequisite to
success.
3.1.2. Issue an Executive Enterprise Architecture Policy
The CIO, in collaboration with the Agency Head, develops a
policy based on the Agency�s
architecture principles that governs the development,
implementation, and maintenance of the

EA. The EA policy should be approved by the Agency Head
and, at a minimum, should include:
A Practical Guide to Federal Enterprise Architecture Initiate
Enterprise Architecture Program
12
February 2001
• Description of the purpose and value of an EA
• Description of the relationship of the EA to the Agency�s
strategic vision and plans
• Description of the relationship of the EA to capital planning,
enterprise engineering, and
program management
• Translation of business strategies into EA goals, objectives,
and strategies
• Commitment to develop, implement, and maintain an EA
• Identification of EA compliance as one criterion for new and
ongoing investments
• Overview of an enforcement policy
• Security practices to include certification and accreditation
• Appointment of the Chief Architect and establishment of an
EA core team
• Establishment of the EA Program Management Office

(EAPMO)
• Establishment of the EA Executive Steering Committee
(EAESC).
3.1.3. Obtain Support from Senior Executives and Business
Units
Commitment and participation of the Agency�s senior
executive and business teams are vitally
important. The CIO should initiate a marketing program to
emphasize the value of the
architecture and the Agency Head�s support and commitment.
The senior executive team and its
organizational units are both stakeholders and users of the
architecture. Therefore, the CIO
invests time and effort in familiarizing the staff with what an
EA is and how it can help achieve
organizational goals and commitments. Even though the target
audience varies among Agencies,
the audience for Departments should include the Deputy and
Under Secretaries and the Assistant
Secretaries and their key staffs. For Agencies, the audience
should include the Deputy and
Assistant Administrators, Commissioners, or Bureau Chiefs.
The primary goal of educating the Department and Agency
senior executives is to obtain their
concurrence and commitment to having their organizations as
active participants. Participation
can involve the executives (or their designees) in attending
planning sessions, committing
resources (people and funding) for specific tasks, or becoming a
champion or spokesperson for
the effort. Maintaining the participation and support of key
executives is crucial to sustaining a

successful effort.
The Chief Architect should create a plan to obtain the support
of the enterprise�s business units.
It is recommended that the business units establish an "inner
circle" of domain owners and
subject matter experts (SMEs). This leadership group should
consist of business unit managers
who �own� specific lines of business. This leadership group
should be able to understand and
communicate enterprise goals and objectives, and to think
creatively, with consideration of
budgets and other constraints. This group of managers is
responsible for ensuring that the
business layers of the architecture are properly documented, and
that the sequencing plan makes
sense from the perspective of the business strategy, considering
both automated and non-
automated processes.
Once the EA policy has been disseminated, the CIO and Chief
Architect should organize and
conduct a program kickoff meeting to explain the EA goals,
objectives, processes, products, and
interrelationships with activities of the systems development
life cycle, capital planning and
investment process, and other related activities. The goal of the
program kickoff meeting is to
13
February 2001

promote buy-in by program participants at middle and lower
levels of the organization. After
several of the first EA products are developed and analyzed, the
products and analysis should be
disseminated throughout the Agency and its communities of
interest to demonstrate the value of
these early results and achieve maximum exposure for the
benefits of the EA development effort.
3.2. Establish Management Structure and Control
Figure 4 illustrates a notional program organization to
manage, control, and monitor EA activity and progress.
The organization shows the desired functional roles,
interrelationships, and lines of communication. The
organization structure should facilitate and advance the
performance of EA roles and responsibilities. The roles of
the EAESC, Technical Review Committee (TRC), and the
EA Program Management Office are unique to the
introduction of the EA process. Other roles, such as
Quality Assurance (QA), Configuration Management
(CM), Risk Management (RM), Security, and Evaluation
are customary IT support roles. These roles are expanded
to explicitly include EA-related responsibilities.
EA roles should be evaluated based on the size of the
organization, the complexity of the business
and architecture, and other factors to effectively determine the
correlation of roles assigned to
personnel. In a large organization with complex business
processes, an individual may be
responsible for one specific role. In smaller Agencies or
organizations, an individual may be
assigned several roles and responsibilities.

Chief Architect
Architecture Core Team
EA Program
Management Office
Technical
Review
Committee
Risk Management
Configuration
Management
Evaluation
Agency Head
Chief
Information
Officer
Subject
Matter
Experts
Domain
Owners
Business Line Organization
Staff

Organization
Quality
Assurance
Capital
Investment
Council
EA Executive
Steering
Committee
Figure 4. Notional EA Organization
Establish Management
Structure and Control
14
February 2001
3.2.1. Establish a Technical Review Committee
The CIO should charter and appoint a Technical Review
Committee to manage the review of
candidate projects and assess project alignment with the EA.
Once the EA has been developed
and approved, the TRC assesses each proposed investment for

compliance with the architecture.
The TRC reports their conclusions and provides
recommendations to a Capital Investment
Council (CIC).
In all cases, the TRC determines and documents the results and
the accompanying rationale for its
actions. The TRC reviews a project and assesses if:
• The project completely aligns with the EA
• The project does not align with the EA and an alternate course
of action is needed
• The project does not align with the EA and a waiver is
approved.
The TRC approves a waiver only if the impacts of the lack of
alignment are understood and
acceptable. By approving a waiver, the TRC conveys to the
CIC that it does not object to the
proposed project.
3.2.2. Establish a Capital Investment Council
The Agency Head establishes a CIC to achieve informed
decision making regarding costs,
benefits, risks of alternative investment options and
architectural alignment. The goal of the CIC
is to ensure enterprise and application architecture projects are
feasible from a cost-benefit
standpoint. The CIC reviews proposed IT investments and
makes the final investment funding
decision. It accepts program and project proposals that have
been assessed by the TRC and
determines whether these programs/projects fit within the
overall budgetary and funding goals for
the enterprise. While a project may be technically aligned with

the EA, the CIC may reject
funding for a project because of other external constraints or
budgetary reasons. CIC decisions
may necessitate updates to the sequencing plan.
3.2.3. Establish an EA Executive Steering Committee
The Agency Head establishes an EA Executive Steering
Committee to direct, oversee, and
approve the EA and EA program. The EAESC is responsible for
approving the initial EA,
approving significant changes to the EA, and approving the EA
Program Plan.
The EAESC should be formally chartered, with a designated
chair or co-chairs, and empowered
to ensure Agency-wide strategic direction, oversight, and
decision-making authority for the EA.
The EAESC charter should authorize the chair or co-chairs to
appoint the membership. By
charter, the EAESC membership should consist of active
participants that represent and include
all major Agency business and technology areas. To perform
effectively as a decision-making
body, it is crucial that the EAESC members are senior leaders,
with the authority to commit
resources and make and enforce decisions within their
respective organizations.
3.2.4. Appoint Chief Architect
The CIO should appoint, with the Agency Head�s approval, an
Agency executive to serve as
Chief Architect and EA Program Manager. The Chief Architect
is responsible for leading the
development of the EA work products and support environment.

The Chief Architect serves as
the technology and business leader for the development
organization, ensuring the integrity of the
15
February 2001
architectural development processes and the content of the EA
products. The Chief Architect
should be friend and liaison to the business line units and
ensure that business unit processes are
emphasized in the EA. Likewise, the Chief Architect is
responsible for ensuring that the EA
provides the best possible information and guidance to IT
projects and stakeholders, and that
systems development efforts are properly aligned with business
unit requirements.
In the role of EA Program Manager, the Chief Architect has
management responsibility for the
EA program, with the authority, responsibility, and
accountability for the overall architectural
effort. The Program Manager is responsible for the planning,
staffing, and ultimate success of the
program, including acquisition of sustaining funding,
negotiating schedules, timely and accurate
delivery of the EA products, and the establishment of an
appropriate support environment that
ensures proper application of these assets.
The core competencies of the Chief Architect include expertise

in strategic and technical
planning, policy development, capital planning and investment
control, change management,
systems engineering and architectural design, business process
reengineering, and large-scale
program management. In addition, the Chief Architect becomes
completely conversant with the
Agency�s business and IT environments. As the primary
technical leader of this effort, the Chief
Architect should be a good communicator who can bridge the
cultural differences that often exist
between the business and systems organizations, and facilitate
interaction and cooperation
between these two cultures.
3.2.5. Establish an Enterprise Architecture Program
Management Office
The EA effort should be treated as a formal program with full
sponsorship through the Agency's
CPIC process. An EA Program Management Office should be
established to manage, monitor,
and control the development and maintenance of the EA. The
EAPMO staff includes
experienced architects. The EAPMO identifies and performs
cost analyses of alternative
approaches for developing the EA, and manages in-house or
outside contractor EA development
work. The EAPMO is also charged with determining needed
resources and securing funding and
resource commitments.
A primary goal of the EAPMO and the EAESC is to ensure
success of the EA program. Each
phase of the program (i.e., EA development, use, and
maintenance) is subject to the CIC policies

and procedures for investment decisions.
3.2.5.1. Appoint Key Personnel
The CIO should make the EA an explicit responsibility for those
individuals designated as the
organization�s Evaluators, Risk Manager, and Configuration
Manager. The Risk Manager
identifies, monitors, controls, and mitigates EA program risks in
light of environmental factors
(e.g., external business constraints, and technical constraints).
The Configuration Manager
assumes responsibility for configuration management of the EA
products in the same way that
configuration management is imposed on any other engineering
baseline.
The CIO should establish an independent QA organization to
perform evaluation of the EA. This
team should report to the EAESC and ensure all established
program and project standards and
processes are met. Potential sources for review include external
reference groups, impartial or
uninvolved external entities, or by hiring a neutral third party
specializing in assessments or
validations. Within the Federal government, Agencies can
request their Inspector Generals to
16
February 2001

conduct an IV&V review or enlist the services of a non-profit
entity such as a Federally Funded
Research and Development Center (FFRDC).
3.2.5.2. Establish Enterprise Architecture Core Team
At the same time the Agency Head and CIO achieve business
line ownership of the effort, a core
team of IT experts, business line experts, and technologists
should be assigned to develop the
desired process and procedures used throughout the
development effort. Participants should have
an understanding of the current business and technical
environment and the strategic business
objectives envisioned in the EA. The team includes the Chief
Architect; senior business, systems,
data, infrastructure and security systems architects. This team
should be well grounded in the
existing environment and prepared to document and develop the
EA that will support evolving
business needs.
The architecture core team should include IT representatives
from the Agency's applications,
data, and infrastructure organizations. The specific core
teamwork groups should include
business analysts, data analysts, systems designers, security
specialists, and systems
programmers. As the program gets underway, more
resources/team members are typically added
to the architecture core team. The architecture core team will
include program managers
proficient in managing Agency-wide programs as well as
interagency initiatives.
The EA core team is responsible for all activities involving the

development, implementation,
maintenance, and management of the architecture. This
includes:
• Developing EA processes, procedures, and standards
• Developing baseline and target architectures
• Developing and maintaining an EA repository
• Performing quality assurance, risk management, and
configuration management
• Guiding systems development and acquisition efforts
• Defining EA performance measures.
Table 1 provides a listing of functional roles and the associated
responsibilities assigned to EA
core team members. In smaller agencies, some of these roles
and responsibilities may be shared,
doubled up, or contracted out.
17
February 2001
Table 1. EAPMO Roles and Responsibilities
Role Responsibilities
Chief Architect
Heads the EAPMO, organizes and manages the EA core team;
directs
development of the baseline and target architecture.
Senior Architecture Consultant

Provides architecture strategy and planning consultation to the
Chief
Architect.
Business Architect
Analyzes and documents business processes, scenarios, and
information
flow.
Applications Architect
Analyzes and documents systems, internal and external
interfaces, control,
and data flow.
Information Architect
Analyzes and documents business information (logical and
physical) and
associated relationships.
Infrastructure Architect
Analyzes and documents system environments, including
network
communications, nodes, operating systems, applications,
application servers,
web and portal servers, and middleware.
Security Systems Architect
Oversees, coordinates, and documents IT security aspects of the
EA,
including design, operations, encryption, vulnerability, access,
and the use of
authentication processes.
Technical Writer
Ensures that policies, guidebooks, and other documentation
within the EA

repository are clear, concise, usable, and conform to
configuration
management standards.
Quality Assurance
Ensures that all established program and project standards,
processes, and
practices are met.
Risk Management
Identifies, monitors, and controls risks in light of environmental
factors and
constraints.
Configuration Control
Assures that all changes are identified, tracked, monitored, and
appropriately
documented.
3.3. Enterprise Architecture Program Activities and Products
3.3.1. Develop an EA Marketing Strategy and Communications
Plan
The purpose of the marketing strategy and communications plan
is (1) to keep senior executives
and business units continually informed, and (2) to disseminate
EA information to management
teams. The CIO�s staff, in cooperation with the Chief
Architect and support staff, defines a
marketing and communications plan consisting of (a)
constituencies, (b) level of detail, (c) means
of communication, (d) participant feedback, (e) schedule for
marketing efforts, and (f) method of
evaluating progress and buy-in. It is the CIO�s role to
interpret the Agency Head�s vision and to

recognize innovative ideas (e.g., the creation of a digital
government) that can become key
drivers within the EA strategy and plan. If resources permit,
the Chief Architect should use one
or all of the following tools to communicate with the
community of interest: seminars and
forums, web pages, electronic surveys, and e-mail listservs.
One of the recommended means for marketing the EA is a
primer to inform Agency business
executives and stakeholders of the EA strategy and plan. The
primer can be used to express the
Agency Head�s vision for the enterprise and the role of EA in
accomplishing that vision�for
example, creating the integrated foundation for online
government or streamlining business
processes and technology.
18
February 2001
The primer should describe the tenets of the EA and its many
benefits as an agent of change in
achieving organizational goals (e.g., integrating business
services and initiatives) or as a critical
resource to evaluate options for change as business and
technology needs evolve. The primer
should clearly describe the roles and responsibilities of the
senior executives and their
organizational units in developing, implementing, and
maintaining the EA. It is important that

the primer include customized sections that relate directly to
specific business line audiences.
The primer should demonstrate the benefits of an EA for the
Agency's stakeholders. This is
particularly important since many of the stakeholders may be
needed to provide skilled resources,
support, and time to the effort. Once completed, the primer
should be widely distributed
throughout the Agency and made available on the Agency's web
site. It should be briefed to all
personnel impacted by the introduction of the EA. Introductory
materials drawn from the primer
should be incorporated into local and Agency-wide training
programs.
3.3.2. Develop an EA Program Management Plan
A formal plan is desired for sound program management. The
EAPMO creates an EA program
management plan (PMP) that includes a roadmap to accomplish
the goals set by the EAESC and
implementation plans to achieve those goals. The plan should
include goals for the Chief
Architect in setting Agency-wide architectural objectives.
These goals should help the
architecture team establish and maintain lower-level
architectures that comply with the EA.
The PMP delineates plans and a set of actions to develop, use,
and maintain the EA, including EA
management, control, and oversight. To facilitate the tracking
of cost, schedule, and performance
data, oversight and control procedures should be developed,
documented, and implemented
within the PMP. The PMP should also include:

• Requirements for the EA Program Manager to identify all
funding requirements,
spending timelines/schedules, and links to performance
measures
• A Work Breakdown Structure (WBS) detailing the tasks and
subtasks necessary to
acquire, develop, and maintain the architecture
• Resource estimates for funding, staffing, training, workspace
requirements, and
equipment needs
• Roadmap for the initiation of project plans
• Requirements for performing quality assurance, risk
management, configuration
management, and security management
• Requirements for the establishment and maintenance of an EA
information repository.
3.3.3. Initiate Development of the Enterprise Architecture
Once the EAPMO is in place and the PMP is produced, the first
of the architecture projects is
launched. There are several peripheral activities associated
with the start of this development.
The EAPMO�s initial project will:
• Institute PMP practices
• Establish EA development processes and management
practices

• Train EA project participants
• Build baseline EA products
• Build target EA products (as possible)
19
February 2001
• Create the sequencing plan
• Populate the EA repository.
Sections 4 and 5 provide discussions on the details of the
development of the EA.
20
February 2001
21
February 2001
Goals:

� Build a baseline architecture that
represents reality
� Build a target architecture that
represents the business vision and IT
strategies
� Develop a sequencing plan that
describes an incremental strategy for
transitioning the baseline to the target
� Publish an approved EA and
sequencing plan that are accessible by
agency employees
Define an Architecture
Process and Approach
4. Define an Architecture Process and Approach
The next step in the EA process is establishing an
EA process and approach. The EA will be used
as a tool to facilitate and manage change within
the Agency organization. The scope and nature
of the Agency and the changes to be made will
dictate the scope and nature of the architecture to
be developed. While the EA is an excellent tool
to manage large and complex environments, the
depth and detail of the EA needs to be tailored to
the individual enterprise. Figure 5 illustrates how
the depth and detail in the EA varies not only
with the size and complexity of the enterprise,
but also the many types of risks associated with change.
Regardless, the scope of the enterprise
architecture for the strategic planner and business owner views
(as defined by the architecture

framework selected) needs to encompass the entire enterprise.
The agency will understand the
relationships and dependencies among its lines-of-business and
thus position itself to make
informed decisions on how to approach defining EA depth and
detail for these lines-of-business.
The first activity in this process is to determine the intended use
of the architecture. It drives the
rest of the EA development process. The subsequent activities
describe how to scope,
characterize, select EA products, build, and use the EA.
Before actually developing the EA, an Agency needs to
evaluate and select an architectural framework as
guidance. This section describes several candidate
frameworks currently used within the Federal community.
The selection of a framework is contingent on the purpose
of the EA and the products to be developed.
Additionally, a toolset or repository for the EA
development and use should be employed. The chosen
tool should be commensurate with the products to be
generated.
Size
Complexity
Risk
Depth & Detail
Figure 5. Depth and Detail of the Architecture

A Practical Guide to Federal Enterprise Architecture Define an
Architecture Process and Approach
22
February 2001
4.1. Define the Intended Use of the Architecture
Architectures should be built with a specific purpose in mind.
It could be business process
reengineering, systems acquisition, system-of-systems migration
or integration, user training,
interoperability evaluation, or any other intent. The purpose of
the architecture is closely tied to
the organization�s Strategic Plan(s), legislation such as GPRA
and Clinger-Cohen, and support of
the capital investment process. Before an architect begins to
describe an architecture, the
organization determines the changes the architecture is intended
to facilitate, the issue(s) the
architecture is intended to explore, the questions the
architecture is expected to help answer, and
the interests and perspectives of the audience and users. One
important practical consideration is
determining the types of analyses that will be performed; i.e.,
knowing that the architecture may
be used as input to specific models or simulations can affect
what to include and how to structure
the products.
The purpose of the EA may, and likely will, evolve over time to
meet new requirements. The
Chief Architect should ensure that any such EA evolution does,
in fact, meet the newly
determined requirements. This will increase the efficiency of
the architecture development and

create greater balance in the resulting architecture.
4.2. Define the Scope of the Architecture
It is critically important that EA development be approached in
a top-down, incremental manner,
consistent with the hierarchical architectural views that are the
building blocks of proven EA
frameworks, including the ones discussed later in this guide. In
doing so, it is equally important
that the scope of the higher level business views of the EA span
the entire enterprise or agency.
By developing this enterprise-wide understanding of business
processes and rules, and
information needs, flows, and locations, the agency will be
positioned to make good decisions
about whether the enterprise, and thus the EA, can be
appropriately compartmentalized. Without
doing so, scoping decisions about the EA run the risk of
promoting �stove-piped� operations and
systems environments, and ultimately sub-optimizing enterprise
performance and accountability.
Other considerations relevant to defining the scope of the EA
include, but are not limited to:
• Relevance of activities, functions, organizations, timeframes,
etc.
• Enterprise scope (intra- and inter-Agency domains)
• Operational scenarios, situations, and geographical areas to be
considered
• Projected economic benefits
• Projected business and technical risk areas

• Projected availability and capabilities of specific technologies
during the target timeframe
(applies to target architecture only).
Defining the scope leads the planners to project management
factors that will contribute to these
determinations, including the resources available for building
the architecture as well as the
resources and level of expertise available for analysis and
design tasks.
4.3. Determine the Depth of the Architecture
Care should be taken to judge the appropriate level of detail to
be captured based on the intended
use and scope of the EA and executive decisions to be made
using the EA. It is important that a
consistent and equal level of depth be completed in each view
and perspective. If pertinent
characteristics are omitted, the architecture may not be useful.
If unnecessary characteristics are
23
February 2001
included, the architecture effort may prove infeasible given the
time and resources available, or
the architecture may be confusing and/or cluttered with details
that are superfluous. EA
characteristics are influenced by the focus: whether primarily

capturing the baseline vs. the target
and vice-versa. It is equally important to predict the future uses
of the architecture so that, within
resource limitations, the architecture can be structured to
accommodate future tailoring,
extension, or reuse. The depth and detail of the EA needs to be
sufficient for its purpose.
4.4. Select Appropriate EA Products
Essential products are those required for all architectures, while
supporting products may be
necessary to fulfill specific informational needs. Only
those supporting products that portray the desired
characteristics should be built. The required products
should help formulate the selection of a framework and
associated toolset.
It is essential that the Chief Architect guide the
construction of the technical content to meet the needs of
the EA, especially in the desired level of detail needed in
the work products. If the content is at too high a level of
abstraction, it may not be sufficiently useful to guide
projects and reviews. If the content is too detailed, it may
be difficult to manage.
4.4.1. Select Products that Represent the Business of the
Enterprise
As the first step in identifying and creating the business
definition, the Chief Architect determines which products
can be used to provide an integrated view of the Agency
core business. These include functional, informational, and
organizational models. Functional or process models may
be represented in several forms, including:

• Use Cases
• Activity Models/Trees
• IDEF [Integrated Computer Aided Manufacturing (ICAM)
Definition]
business process models
• Concept of Operations (CONOPS)
• State Models.
Information models include class models and conceptual data
models. Appropriate combinations
of these models should be used to represent internal and
external organizational participants,
activities, inputs, outputs, flow of information, sequencing,
interrelationships between data, and
external interfaces. The models span the enterprise and
represent the enterprise at the strategic
level. Additional information and examples of these models are
provided in Appendix D.
The business definition should be created in the baseline and
target architectures and the
sequencing plan. In the baseline architecture, it represents the
current state of business operations
and information exchange within and across the organization.
In the sequencing plan, it
Model�representations of reality:
the information, activities,
relationships, and constraints.
Essential products�the graphics,
models, and/or narratives that

every architecture description must
include, to support the scope and
characteristics of the EA.
Supporting products�the
graphics, models, and/or narratives
that may be needed to further
elaborate on essential products or
to address particular domain or
scope extensions (e.g., real-time or
special performance
considerations).
24
February 2001
represents business changes and maps to planned systems and
business improvements. In the
target architecture, it represents planned business operations as
expressed in business strategies
and visions.
4.4.2. Select Products that Represent Agency Technical Assets
The technical content of the EA represents the technical assets
of the Agency. It consists of the
logical and physical designs of the baseline and target
architectures. At a minimum, this content
includes designs of data, applications, and infrastructure
(including hardware, software, and
communications). These products identify information needs,

software applications/programs,
middleware, and underlying physical infrastructure supporting
the current environment and
needed to support the Concept of Operations (CONOPS) for the
enterprise in its target state.
EA products created to support business content are often
extended to represent the solution
space. Thus, many of the models could be reused, extended,
and referenced in order to define the
technical architecture. The purpose of the technical architecture
is to ensure that a conforming
system satisfies a specific set of business needs and
requirements. It provides the technical
systems implementation guidelines for creating engineering
specifications and developing
products.
4.5. Evaluate and Select a Framework
As each Federal Agency embarks on this stage of the
architecture process, it must select an appropriate architectural
framework. A number of well-established frameworks are
successfully used throughout the Federal sector. Alternatively,
an Agency may choose to develop its own framework,
although the costs, benefits, and risks of doing so should be
weighed against the risks of adopting
or tailoring an existing framework. While Federal Agencies
vary widely in their approach to
architecture development and implementation, established
frameworks permit comparisons and
analyses across Agencies. Therefore, it is recommended that
before an Agency develops a new
framework (if an Agency has a mandated framework, it must be
employed), it should investigate
the use of other existing Federally developed frameworks.

Three Federally sponsored (and commonly accepted)
architectural frameworks are used as
candidate frameworks and for descriptive purposes within this
EA guide. These contain essential
and supporting products, and promote development of
architectures that are complete,
understandable, and integratable. The organizations that
developed these frameworks continue to
tailor them to ensure parallel precepts, principles, and
methodologies. The frameworks are:
• Federal Enterprise Architecture Framework (FEAF)
• Department of Defense (DoD) Command, Control,
Communications, Computer,
Intelligence, Surveillance and Reconnaissance (C4ISR)
Architecture Framework
• Treasury Enterprise Architecture Framework (TEAF).
Other EA frameworks exist and have been used in Government
programs (e.g., Department of
Agriculture�s framework and the National Institute of
Standards and Technology [NIST]
framework). This guide does not address these other
frameworks because most organizations
have standardized on the FEAF, C4ISR, and TEAF for EA
development. In addition to EA
frameworks, many processes exist that can be used to support
framework development, such as
Framework�a logical structure
for classifying and organizing
complex information.

25
February 2001
the Department of Energy�s corporate systems information
architecture roadmap for IT systems
implementation. Since a notional process is described in this
guide, other Federal Agency EA
processes are not discussed.
The use of an EA framework ensures uniformity and
standardization when migrating and
integrating information systems. The selected framework will
depend on the intended use, scope,
and characteristics of the architecture to be developed. Table 2
lists major factors to consider.
Table 2. Framework Selection Criteria
Areas Factors
Policy
• Regulatory and legislative direction
• Agency policy
• Compatibility needed with another Agency or joint policy
Enterprise
• Context for the enterprise�e.g., subordinate to a larger

enterprise, closely
related to another enterprise
• Experience with a particular framework
• Mandates and drivers�e.g., emphasis on business versus
infrastructure or
operational versus technical issues
EA products
• Priorities, intended uses and desired level of detail�e.g., large
scale
modernization versus stable IT environment
• Resource and schedule constraints on modeling efforts
• Availability of existing architecture products
Frameworks include concepts that drive the types of
architecture products being created. The
products, both graphical and textual, capture the information
prescribed by the framework.
Equivalent products may be substituted if the new product has
similar or more extensive
attributes than the original product. This is often done when
specific methods (e.g., object-
oriented analysis and design) lend themselves to particular
modeling techniques.
Using the FEAF, C4ISR, or TEAF frameworks should
substantially reduce the development process and will
shorten the time to get an EA in place and put an Agency
on a path for success. The following sections provide a
brief description of the FEAF, C4ISR, and TEAF frameworks.

4.5.1. Federal Enterprise Architecture Framework
In September 1999, the Federal CIO Council published the
Federal Enterprise Architecture
Framework, Version 1.1 for developing an EA within any
Federal Agency or for a system that
transcends multiple inter-agency boundaries. It builds on
common business practices and designs
that cross organizational boundaries. The FEAF provides an
enduring standard for developing
and documenting architecture descriptions of high-priority
areas. It provides guidance in
describing architectures for multi-organizational functional
segments of the Federal Government.
These Federal architectural segments collectively constitute the
Federal EA. Currently, the
FAWG is sponsoring the development of EA products for trade
and grant Federal architecture
segments.
Method�a prescribed way of
approaching a particular problem.
26
February 2001
As shown in Figure 6, the FEAF partitions a given architecture
into business, data, applications,
and technology architectures. The FEAF currently includes the
first three columns of the
Zachman framework and the Spewak EA planning methodology

(see Appendix G).
Figure 6. Structure of the FEAF Components
For the Federal Enterprise, the Federal CIO Council seeks to
develop, maintain, and facilitate the
implementation of a top-level EA predicated upon the FEAF.
This architecture serves as a
reference point to facilitate the efficient and effective
coordination of common business
processes, technology insertion, information flows, systems,
and investments among Federal
Agencies. The FEAF provides a structure to develop, maintain,
and implement top-level
operating environments and support implementation of IT
systems. As shown in Figure 7, the
FEAF is graphically represented as a 3x5 matrix with
architecture types (Data, Application, and
Technology) on one axis of the matrix, and perspectives
(Planner, Owner, Designer, Builder, and
Subcontractor) on the other. The corresponding EA products
are listed within the cells of the
matrix.
Data
Architecture
Application
Architecture
Technology
Architecture
Planner
Perspective

Owner
Perspective
Designer
Perspective
Subcontractor
Perspective
Business Logistics System
Data Dictionary
Systems Design
Network Architecture
Logical Data Model
Physical Data Model
Programs
List of Business Locations
System Geographic
Deployment Architecture
Technology Architecture
List of Business Objects
Semantic Model Business Process Model
Application Architecture

List of Business Processes
Builder
Perspective
Figure 7. FEAF Architecture Matrix
27
February 2001
4.5.2. DoD C4ISR Architecture Framework
In December 1997, the DoD published its C4ISR Architecture
Framework. This framework
applies to all branches of the armed services and includes the
numerous major and subordinate
commands, field organizations, and task forces within each
service.
In the C4ISR Architectural Framework, the operational
view describes the tasks and activities, operational
elements, and information flows needed to accomplish
or to support an operation. It specifies the nature of
each needline�s information exchange in sufficient
detail to determine the desired degree of interoperability. The
systems view identifies which
systems support the requirement. It translates the desired
degree of interoperability into a set of
needed system capabilities, and compares current/postulated
implementations with the needed
capabilities. The technical view defines the criteria that govern

the implementation of each
system capability. To be consistent and integrated, an
architecture description should provide
explicit linkages among its various views. Figure 8 illustrates
these three views and their
relationships.
Sy
st
em
s
A
ss
oc
ia
tio
ns
to
N
od
es
, A
ct
iv
iti
es

, N
ee
dl
in
es
,
a
nd
R
eq
ui
re
m
en
ts
Identifies Warfig hter
Relationships and Information Needs
Operational
View
Prescribes Standards
and Conventions
Technical
View
Relates Capab ilities and

Characteristics to Operatio nal Req uirements
Systems
View
Technical Criteria Governing
Interoperable Implementation/
Procurement of the Selected
System Capabilities
Specific Capabilities Identified
to Satisfy Information-
Exchange Levels and Other
Operational Requirements
B
asic Technology
Supportability and N
ew
C
apabilities
Processing and Levels of
Inform
ation Exchange
R
equirem
ents
Pr
oc

es
si
ng
a
nd
In
te
rn
od
al
Le
ve
ls
o
f I
nf
or
m
at
io
n
Ex
ch

an
ge
R
eq
ui
re
m
en
ts
Figure 8. DoD C4ISR Framework
Figure 9 depicts the C4ISR essential and supporting architecture
products. Appendix D provides
examples of C4ISR essential products.
Needline�a requirement that is
the logical expression of the need
to transfer information among
nodes.
28
February 2001
All
Views

Operational
View
Systems
View
Technical
View
Integrated
Dictionary
Activity Model
Systems
Communications
Description
System
Functionality
Description
Command Relationship
Chart
Systems Information
Exchange Matrix
Logical Data Model
Physical Data Model
System Evolution
Description

Systems
Interface
Description
Operational Rules
Model
State Transition
Description
Technical
Architecture
Profile
Standards
Technology
Forecast
Operational Activity
to System Function
Traceability Matrix
Overview & Summary
Information
Node
Connectivity
Description
High-level
Concept of Operations
Graphic

Information
Exchange
Matrix
Systems Matrix
Event Trace
Diagrams
Systems Event
Trace Diagrams
Systems Rules
Model
System State
Transition
System Technology
Forecast
System Performance
Parameters Matrix
Supporting Work ProductsEssential Work Products
Figure 9. DoD C4ISR Products
4.5.3. Treasury Enterprise Architecture Framework
In July 2000, the Department of the Treasury published the
Treasury Enterprise Architecture
Framework. The TEAF provides (1) guidance to Treasury
bureaus concerning the development

and evolution of information systems architecture; (2) a
unifying concept, common principles,
technologies, and standards for information systems; and (3) a
template for the development of
the EA.
The TEAF describes an architectural framework that supports
Treasury's business processes in
terms of products. This framework guides the development and
redesign of the business
processes for various bureaus in order to meet the requirements
of recent legislation in a rapidly
changing technology environment. The TEAF prescribes
architectural views and delineates a set
of notional products to portray these views. Figure 10
illustrates the TEAF framework.
29
February 2001
Functional
Information
Organizational
Infrastructure
How, Where, and When
What, How Much, and

How Frequently
Who and Why
Enabler
Figure 10. The Treasury Enterprise Architecture Framework
The TEAF�s functional, information and organizational
architecture views collectively model the
organization�s processes, procedures, and business operations.
By grounding the architecture in
the business of the organization, the TEAF defines the core
business procedures and enterprise
processes. Through its explicit models, a TEAF-based
architecture enables the identification and
reasoning of enterprise- and system-level concerns and
investment decisions.
The TEAF provides a unifying concept, common terminology
and principles, common standards
and formats, a normalized context for strategic planning and
budget formulation, and a universal
approach for resolving policy and management issues. It
describes the enterprise information
systems architecture and its components, including the
architecture�s purpose, benefits,
characteristics, and structure. The TEAF introduces various
architectural views and delineates
several modeling techniques. Each view is supported with
graphics, data repositories, matrices,
or reports (i.e., architectural products). Figure 11 shows a
matrix with four views and four
perspectives. Essential products are shown across the top two
rows of the matrix. It is notable
that the TEAF includes an Information Assurance Trust model,

the Technical Reference Model,
and standards profiles as essential work products. These are not
often addressed as critical
framework components.
30
February 2001
Functional
View
Information
View
Organizational
View
Infrastructure
View
Planner
Perspective
Owner
Perspective
Designer
Perspective
Builder
Perspective

Info Assurance
Trust Model
Business Process/
System Function
Matrix
State Charts
System
Functionality
Description
Information
Exchange Matrix
(Logical)
Information
Exchange Matrix
(Physical)
Logical Data Model
Physical Data Model
Data CRUD Matrices
Organization
Charts
Node Connectivity
Description

(Logical)
Node Connectivity
Description
(Physical)
Technical
Reference
Model
Standards Profile
Info Assurance
Risk Assessment
System Interface
Description
(Level 1)
System Interface
Description
(Level 2 & 3)
System Interface
Description
(Level 4)
System Performance
Parameters Matrix
Mission & Vision
Statements

Activity
Model
Information
Dictionary
Information
Exchange Matrix
(Conceptual)
Node Connectivity
Description
(Conceptual)
Event Trace
Diagrams
Supporting Work ProductsEssential Work Products
EA Repository
Listings
High Level
Modeling
Logical
Modeling
Physical
Modeling
Figure 11. TEAF Products

One of these frameworks should provide a means to logically
structure and organize the selected
EA products. Now, in order to effectively create and maintain
the EA products, a toolset should
be selected.
4.6. Select an EA Toolset
To increase the usefulness of any architecture, it is important to
maintain the EA within an
interactive architectural tool. Fortunately, there are many
automated architecture tools available
on the market today. The choice of tool should be predicated
upon the organization�s needs
based on the size and complexity of its architecture. The Chief
Architect and architecture core
team may use the Office suite of tools (e.g., Microsoft�s
PowerPoint and Word) and/or modeling
tools (e.g., Rational Rose by Rational Corporation, Systems
Architect by Popkin, or Framework
by Ptech).
There are toolsets available from leading vendors that can
provide alignment with the chosen
framework and recommended products. Tool criteria should be
determined based on the intended
use of the architecture, scope, levels of integration desired, and
other factors. Table 3 lists
candidate topics to aid in the selection of tools. The list can be
tailored to a specific set of
requirements for tool selection. One tool will probably not
meet all requirements. Therefore, a
tool suite or combination of tools will be needed. The work
products should be maintained in
several different types of media such as hardcopy
documentation (briefings and reports),

electronic files on CD-ROM, HTML documents on the web, and
other EA Computer Aided
Software Engineering (CASE) tools and development tools that
provide a relational database
management system.
31
February 2001
Table 3. Tool Selection Criteria
Functional Area Criteria
Development of EA products
• Available platforms
• Support for chosen framework
• Support for modeling methods and techniques�e.g., object-
oriented analysis and design, IDEF, activity models, class
models, information models
• Import/Export capability
• Cost (initial and maintenance) and licensing
• Vendor support (e.g., time, cost)
• Training schedule, cost, length

• Ease of use
• Integration of products generated�ability to integrate baseline
and target architectures and enterprise engineering products
• Capacity, expected size, and complexity of models
• Integrated and consolidated repository
• Multi-user support
• Meta-model support (e.g., ability to configure and tailor model
elements)
• RM support/issues tracking
• CM support
• QA support
Maintenance of EA products
• Ability to interoperate with other enterprise engineering
products and development tools/repositories
• Traceability to requirements and other enterprise engineering
artifacts
• RM support/issues tracking
• CM support
• QA support
Dissemination of EA products

• Accessibility (e.g., software needed, access requirements)
• Documentation generation�briefings and reports
• Media supported (e.g., CD-ROM, HTML)
• Levels of Access control (e.g., Read-Only, Read-Write)
• Use of hypertext links
Tool standardization is a recommended best practice. It proves
cost-effective when determining
architecture quality and alignment with the EA policy from an
acquisition cost perspective and
for consistent interoperability of models.
32
February 2001
33
February 2001
5. Develop the Enterprise Architecture
The next step is to build the architecture products
based on the purpose of the architecture and the
chosen framework. This consists of the essential
products, supporting products (if needed), and
individually defined products (e.g., briefing

charts, interview notes) driven by architecture-
specific needs and processes. To facilitate
integration with other architectures, it is crucial to
include all depictions of relationships with
applicable external components, that is, entities
outside the Agency.
It may be useful, resources permitting, to conduct some proof-
of-principle analyses at various
stages of architecture development. For example, one could
conduct trial runs of the EA
development process using carefully selected subsets of the
areas to be analyzed. The
architecture core team should ensure that the products are
consistent and properly interrelated. If
the products are not applied and populated uniformly, the Chief
Architect and architecture core
team will be unable to compare or contrast the products or
perform thorough analyses.
Regardless of the scope and complexity of the views to be
developed, the architecture core team
should apply a consistent approach to developing the baseline
and target architectures. The
selected approach should include (1) a data collection phase, (2)
preliminary product generation,
(3) review and revision stages, and (4) publication and delivery
of the architecture products to an
appropriate repository. Figure 12 shows a typical process for
developing the EA products. Each
of these activities is described in more detail in the following
subsections.
Literature
and

Documentation
Review
Familiarization
Training
Preliminary
Meetings
and
Interviews
Hold
Group
Brainstorming
Sessions
Conduct
In-depth
Individual
Interviews
Revise
Products
As Needed
Generate
Preliminary
Products
Generate
Briefing

and
Present
Publish
Architecture
Products
Independent
and SME
Review and
Validation
Populate
Tools and
Repositories
Data Collection
Preliminary
Product
Generation
Review and Revision
Publication
and
Delivery
Figure 12. Example Approach for EA Development
Develop Baseline
Enterprise Architecture

Develop Target
34
February 2001
5.1. Collect Information
The first step in the build approach is to identify and collect
existing products that describe the
enterprise as it exists today and as it is intended to look and
operate in the future. Data collection
is the crucial, initial effort involving review of documentation,
staging of training sessions, and
interviewing SMEs and domain owners.
All appropriate collected information and products
should be placed in a centralized electronic EA
repository. In the case of the baseline architecture,
sample products to be collected include:
• Current business functions and information
flows
• Data models
• External interface descriptions
• Existing application and systems documentation
• Technical designs, specifications, and equipment inventories.
In the case of the target architecture, sample products to be

collected include:
• Proposed business processes and information flow
• Strategic plans
• Modernization plans
• Requirements documents.
Many of these products may not exist or may not accurately
represent the current baseline or
proposed target environments. If documentation is missing, the
architecture core team should
develop a strategy to create the needed documentation or decide
whether to make the investment.
In this case, the interviewers will have to rely on business or
system SMEs concerning the
purpose and scope of the activity and the expectations for their
participation. After collecting a
sufficient amount of this data, work can begin on creating the
EA products and populating the EA
repository.
Ideally, preliminary, draft architectural products can be
generated at this time without in-depth
SME involvement. With the development of strawman
products, the architects can then conduct
a series of stakeholder brainstorming sessions and in-depth SME
interviews to solidify the
products. The Chief Architect should review and validate the
proposed interview list and ensure
SME participation via communications with the domain owners.
The marketing and buy-in
process described in Section 3 should have set the stage for this
participation.
It may be useful to record these interviews for future reference.
Always follow up to ensure that

interview information is interpreted correctly. Once the initial
interviews are completed, the
architecture core team extracts information from the interviews
and then refines the existing
products within the EA repository.
Repository�an information system
used to store and access architectural
information, relationships among the
information elements, and work
products.
35
February 2001
5.2. Generate Products and Populate EA Repository
Some products may be created during the first iteration of the
EA development process while
others may be created during later iterations depending on the
framework, process, and chosen
methods. In addition, depending on whether the baseline or the
target is being created, various
factors will affect the approach taken, the focus of the products,
and the order in which products
are generated. These key differentiators are described in Table
4.
Table 4. Baseline and Target Architecture Differentiators
Baseline Architecture Target Architecture

Process Process applies the chosen framework. Process applies
the same framework as for
Baseline.
Process relies extensively on existing
documentation, e.g., process and procedure
manuals.
Documentation may not exist or is likely to
be inconsistent, e.g., various vision and
planning documents.
Generation of products will begin in IT
organization, and eventually extend to
business SMEs for validation of products.
Generation of products begins with heavy
participation by SMEs from business units.
Reverse engineering is likely. Process needs
verification that requirement and design
documentation reflects reality.
Emphasis is on forward engineering,
building on business process reengineering
efforts and technology forecasts.
Available information is standardized and
normalized as a foundation for change.
Material originally produced for different
time frames, e.g., 1-year plans, 5-year plans,
strategic plans, is integrated to a single
vision.
Products Models are based on reality. Models are based on

assumptions, plans,
and recognized needs, political
environment, future technology.
Products describe the entire current
enterprise at a consistent, high level.
Additional analysis, detail based on priority
areas, e.g., known problems areas.
Products describe a vision for the entire
enterprise. Additional analysis, detail based
on priority areas, e.g., anticipated
modernization.
Describes all significant manual and
automated operations.
Explicitly includes legacy, with upgrades if
they are planned, or there is an implicit
decommission of what exists in the
Baseline. Also includes planned transitional
components.
Consistency, completeness, correctness can
be validated.
Consistency, completeness can be validated.
Products are available and controlled in a
repository.
Products are available, linked to the
Baseline Architecture, and controlled in the
same repository as the Baseline architecture.
The information contained in the EA is usually expressed as a

collection of interdependent
products. The volume of information, as well as the
presentation style of that information is often
too great for a user to quickly comprehend. Also, users often
focus on their particular area of
concern and can easily overlook critical dependencies that their
processes or assets may have on
other processes and organizations in the enterprise. Therefore,
providing electronic links among
the interdependent information can highlight the
interdependencies and greatly improve the
understandability of the information. Change control is also
significantly streamlined�by
establishing the links among information at its origin, impact
analysis is facilitated and change
proposals can be evaluated more readily. Some agencies
document and distribute their EAs in the
form of web sites and CD-ROMs, thus easing readability,
access, and distribution.
36
February 2001
The process of getting the enterprise from where it is today to
where it wants to be in the future
needs formal thought and that focuses on optimizing enterprise-
wide performance and
accountability. This thought process is documented with the
Agency�s strategic plan. This
document defines the mission and long-range objectives of the
Agency and relates to plans for

business reengineering and systems modernization. Together
these products should drive the top-
down sequence of EA product development.
5.2.1. Essentials in Building the Baseline Architecture
In building the EA, a logical first step is describing the current
or "as is" state. This is an
important step because it enables future progress to be measured
against a baseline. It has been
said that if you don't know where you are it's hard to know if
you are on the way to where you are
going. Establishing a set of architectural products that describe
and document the current state of
the enterprise from business functions to technology
infrastructure sets the stage for establishing a
plan for moving towards and measuring progress against a
target architecture.
The scope of the baseline analysis and the resultant
documentation is critical. The larger the
enterprise, the higher the commitment and cost for a
comprehensive, explicit, fully detailed and
extremely accurate baseline analysis. For larger Departments,
there are methods and techniques,
as well as models, that facilitate a sampling approach to yield
baselines that are useful and less
costly. Medium to small enterprises may choose a
comprehensive inventory of business
processes, applications, and the technology infrastructure in
which they operate. In that case, the
baseline architecture is a comprehensive inventory of the
business functions, software
applications and problems, and the technology/hardware
infrastructure of the enterprise.

5.2.2. Essentials in Building the Target Architecture
The target architecture should define a vision of future business
operations and supporting
technology. A long-term blueprint is absolutely necessary. A
key consideration is the
determination of the date of the target, how far into the future is
the projected target. Realization
of an organization�s mission and vision statements needs:
• A focus on business areas or information needs with the
greatest potential payoff for the
enterprise
• Development of conceptual models and tools to enable
decision makers and staff to better
recognize, understand, and discuss information requirements
• An enterprise-wide understanding of the �big picture� and
the need for shared
information
• A recognition of information as a strategic resource that
should be managed using
architectures as tools
• Periodic assessments of the enterprise�s progress towards its
target environment
• Alignment with the enterprise�s strategic plan.
The target architecture describes the desired capability and
structure of the enterprise business
processes, information needs, and IT infrastructure at some
point in the future. Therefore, the
target architecture is often referred to as the "To-Be" or �As-
Planned� architecture. The target

architecture may include alternatives, options, and
unknowns�this is acceptable. The EA
process is iterative�unknowns are filled in over time.
37
February 2001
A target architecture represents enhancements to an existing
baseline architecture that add new
functionality to support business operations and provide
enhanced support for existing business
operations. The target architecture must be fiscally and
technologically achievable while being
grounded in the business needs of the organization. The
realities of rapid technological changes
necessitate flexibility and capacity for change in the target
architectures: they should project no
more than 3 to 5 years into the future.
Just as the baseline architecture captures the existing business
practices, functionality, and
information flows, the target architecture reflects what the
organization needs to evolve its
information resources. The target architecture provides answers
to these basic questions:
• What are the strategic business objectives of the organization?
• What information is needed to support the business?
• What applications are needed to provide information?

• What technology is needed to support the applications?
The answers to these questions are grounded in the
Agency�s information requirements, and in turn, the
information needs are predicated upon the organization�s
business practices, functionality, and operations. As
business roles change, information content and information
flow also change. Technology forecasts and information
standards profiling can identify the necessary IT to support
these changing business processes. These forecasts and
standards profiles are necessary prerequisites to developing
the target architecture. Within the target architecture, these
products can be reflected in the TRM product.
The development of a picture of the organization�s future
business processes and information needs is central to
successful target architecture development. This business
view consists of a set of architectural products derived from
the agency�s strategic plans, business process reengineering
results, capital investment plans, and other planning
documentation.
The target architecture should:
• Reflect the EA team�s judgment about the future uses and
characteristics of information
within the enterprise
• Reflect the organization�s business requirements review for
focusing on the opportunities
to automate aspects of work and/or the access to information
needed to perform work
• Incorporate technology forecasts
• Specify the needed level of interoperability needed between

the data sources and the
users of the data
• Identify the IT needed to support the enterprise�s technical
objective
• Reflect budgetary and territorial concerns.
Technology Forecast�a detailed
description of emerging
technologies and technology
standards relevant to the systems
and business processes covered in
the Agency�s EA.
Standards Profile�a
specification of documents,
technology standards, protocols,
and definitions.
Technical Reference Model
(TRM)�a taxonomy that provides
a consistent set of service areas,
interface categories, and
relationships to address
interoperability and open systems.
The TRM integrates the standards
fil d h l f
38

February 2001
Develop the Sequencing
Plan
5.2.3. Review, Validate, and Refine Models
Architecture products are presented for both internal and SME
review. After an extensive
internal review by the EA core team, the SME and domain
owners assess the EA products for
accuracy and completeness. This occurs at several points in the
process. Prior to SME
interviews, senior members of the architecture core team
perform a "quick look" review. This
review sets the stage for the interviewing process. It helps the
interviewers formulate a template
to focus the interview sessions. The next review occurs after
the team has updated and expanded
on the first set of products. There may be additional
interview/review cycles before moving on to
the SME review.
At the SME review, the review participants (i.e., Chief
Architect, architecture core team, QA,
Risk Manager, SMEs, domain owners) determine EA product
accuracy and completeness. The
Risk Manager can provide an early assessment of business,
technical, cost, or schedule risks. The
products should then be revised as necessary and presented to
the TRC and EAESC for validation
and final approval. Upon approval, the final architecture
(products and models) can be published,
briefings and documentation delivered, and the appropriate
databases or architecture tools

updated.
IV&V reviews should be considered at key milestones within
the EA process depending on major
enterprise engineering milestones, the CPIC milestones, and
other factors. Once the EA model
and resultant products are stabilized and validated, it is
important to respond to recommendations
from the validation team(s). If necessary, the architecture core
team should augment, evolve, or
expand the EA models, both in scope and detail, in
accordance with the recommendations.
5.3. Develop the Sequencing Plan
The changes needed to transition from the current state of
the enterprise to the goals and conditions expressed by the
target architecture cannot be achieved in a single quantum
step. Evolving the enterprise from its baseline to the
target architecture needs multiple concurrent
interdependent activities and incremental builds. The best
way to understand and control this complex evolutionary
process is by developing and maintaining a systems
migration roadmap or sequencing plan. The sequencing plan
should provide a step-by-step
process for moving from the baseline architecture to the target
architecture.
The sequencing plan may be supported by a set of architecture
products, similar to the baseline
and target architecture products, generated for several
intermediate points in time between the
baseline and target environments. The succession from one
point in time to the next, and on to
the target timeframe, establishes a migration sequence.

Because the sequencing plan represents the current
environment, as well as the development
programs that are both planned and under way, it becomes a
primary tool for program
management and investment decisions. To remain current and
to support continued coordinated
improvements across the enterprise, the sequencing plan should
be maintained and updated as
time and circumstances dictate.
39
February 2001
In addition to specific development requirements for the new
components in the target
architecture, development of the sequencing plan should
consider a wide variety of inputs,
including:
• Sustainment of operations during transition
• Existing technical assets and contractual agreements
• Development programs currently underway
• Anticipated management and organizational changes
• Business goals and operational priorities (including legislation
and executive directives)
• Budget priorities and constraints.
5.3.1. Identify Gaps
The first step in transition planning is gap analysis�identifying
the differences between the

baseline and target architectures in all related architecture
products. Critical differences are those
that affect the successful accomplishment of the enterprise�s
mission. Consequently, the gap
analysis also develops the user requirements, determines
political and technical constraints, and
assesses migration risks and feasibility.
Through gap analysis, the architecture core team can determine
the components that need to be
changed to achieve the desired end-state. The gap between
baseline and target architectures is
overcome by a series of incremental builds that lead to the
target environment. The size of the
increments is based upon the overall time between the baseline
and target, dependencies among
developmental programs and components, critical path analysis
for highly dependent activities,
business-driven priorities (e.g., legislative mandates and
executive directives), limitations in
human capital capacity to manage the incremental projects and
builds, expected return-on-
investment from projects and builds, and risks. Overall, the gap
analysis assesses the state of the
legacy systems, technology maturity, acquisition opportunities,
and fiscal reality of the transition.
5.3.2. Define and Differentiate Legacy, Migration, and New
Systems
Legacy, migration, and new systems make up the technical
components for the transition to the
target environment. Legacy systems and their applications are
those in current operation and
usually are phased out during the deployment of the target
architecture. Migration systems and

applications may be in current operation, but certainly will be in
operation when the transition
begins and for some time into the future. Therefore, they may
not be specifically represented in
the target architecture. Migration systems also include systems,
databases, interfaces, or other
components that may be introduced and temporarily used to
sustain operations between the
current systems (and incremental phase) and the establishment
of target architecture components.
New systems and applications are those that are being acquired,
are under development, or are
being deployed. They are expected to be operational as part of
the target environment.
The key to prioritizing projects is the sequencing of the
termination of systems, the phasing out of
functionality, and the timing of systems deployment, technology
insertion, and the addition of
new functionality into the enterprise. The architecture core
team considers dual operation of
legacy systems alongside the initial start-up of new systems and
account for this potential in the
sequencing plan. The uninterrupted flow and management of
data, its use by both the legacy and
new systems, and its creation and distribution should be
outlined in the sequencing plan. The
migration should be managed and pursued incrementally so that
the impact of unforeseen events
40

February 2001
(e.g., technical problems, fiscal delays, etc.) on the efficient
operation of the enterprise will be
minimized.
Decisions about sequenced investments need to be driven by
high-level analyses about respective
costs, benefits, and risks, as well as sequential technical and
functional dependencies.
A major section of the sequencing plan is the system evolution
or migration analysis captured in a
set of systems migration tables, diagrams, or charts. Figure 13
illustrates a notional migration
chart. This type of chart helps illustrate how systems and
applications are expected to evolve
between the baseline and target architectures. Generally, a
system evolves in one of six ways:
1. Current systems continue in operation (System D)
2. Existing system functionality is absorbed by another system
(System A into System B)
3. Legacy system transitions to migration and evolves into a
new system (System B into
System X)
4. Current system is planned for further evolution (System C
into System Y)
5. A new system developed during transition that becomes the
permanent final system
(System E)

6. A merger of legacy functionality and migration systems
(System N into System K and
then absorbed into System D).
Today TargetTransition Period
System A
System B
System C
System D
System N
System X
System Y
System D
System B
System E System E
System K
Figure 13. Systems Migration Chart
A sequenced insertion of functionality and a detailed
deployment plan for IT systems is
developed based upon operational priorities, risk management,
and return on investment.
5.3.3. Planning the Migration

The rate of modernization�that is, migration to the target
architecture�needs to be planned in
convenient, manageable increments to accommodate the
organization�s capacity to handle
change. Understanding the level of effort is necessary to
allocate and manage the work according
to a scheduled migration with milestones. This will depend on
proposed information systems
41
February 2001
development or acquisition, priorities, and the availability of
resources, such as budget, people,
and time constraints.
The implementation of changed business processes might be
expressed as program initiatives
with one or more projects. A review of the collection of gaps
between the baseline and target
architectures determines which enhancements, modifications,
and replacements are needed.
Dependency analysis determines the alternatives available for
sequential and concurrent
activities, and helps determine what should be accomplished in
which increment or iteration of
projects. Projects would then be defined to implement each of
the initiatives (or sets thereof).
Each project represents a logical division of work that is easier
to describe and manage from the

overall effort and would be assigned to an individual project
manager with clear responsibility for
its success.
The next step in the development of the migration path focuses
on dependency analysis and
consideration for the desired level of effort for each of the
projects. The interdependency of
systems within the enterprise and the dependencies among
projects and initiatives is the primary
driving force in determining the sequence for implementing
solutions. Estimating the effort and
duration for each initiative provides additional information to
the dependency analysis that
supports critical path analysis. After considering options
offered by tradeoffs from critical vs.
non-critical changes, prioritizing key enhancements to meet key
management priorities (such as
legislative mandates or executive directives), and providing for
sufficient leeway to reduce
schedule risk, a draft sequence plan for the portfolio of projects
can be created.
Final refinement of the sequencing plan involves review and
refinement to meet the short-term
needs and potentially volatile priorities of the business units
within the financial constraints of the
enterprise. The following are some key issues to consider when
refining the strategy:
• What is the potential for commitment of funds for the initial
phases of the migration?
• What is the potential for the commitment of funds for the
entire transition to the target
architecture?

• How soon will the business units see the initial benefits (i.e.,
operational enhancements or
return on investment) from the plan?
• Does the sequencing plan provide incremental improvements
to system users to help
sustain commitment and support to the program?
• What risks are inherent in the current sequencing plan? How
will they be mitigated?
• What alternatives are currently available if funding or
resources are delayed?
The modification, enhancement, or development of information
may include applications, data
integration, and interfaces, as well as systems platform
acquisition, staffing, training (or
retraining), and systems deployment. Because almost all
systems development implies the
control and transfer of funds, systems development should be
coordinated and integrated with
financial management. In addition, interrelationships and
interdependencies�whether
architectural, organizational, and external�need to be
accounted for in the sequencing plan.
5.4. Approve, Publish, and Disseminate the EA Products
Upon verification and validation of the architectural products,
the Agency�s management should
approve the overall architecture. This step includes approval by
the EAESC, the CIO, Chief
Architect, and Agency executives up to and including the
Agency Head (e.g., Secretary,

42
February 2001
Commissioner, or Directors). Each Agency incorporates its own
approval processes for this
cycle.
The Agency executives, managers, and architects should have
ready access to the information in
the EA. By distributing the information in electronic Read-
Only format, executives and
managers can use the information directly while the controlled
baseline is maintained.
Executives and managers should use the information for more
than just reference purposes�
incorporating it into communications, briefings, and directives.
Application architects use the
information to analyze artifacts against their own reality and
identifying opportunities for
improvements. Enterprise architects use the information to
apply �what-if� analysis against the
baseline. In addition, Read-Only format versions of the EA
limit the number of staff able to
make changes and modifications to the products, easing the
burden of change management on the
enterprise as a whole.
The EA documents extensive information about the Agency.
Careful consideration must be made
to the distribution of that information. Although it is possible
that an EA may not have any

confidential information, the aggregation of the information
may comprise a security risk. In the
wrong hands, the compilation of enterprise information in the
EA could create a vulnerability to
the Agency by providing sufficient information for infiltration
and disruption. Some of the
information (or combinations thereof) may need to be controlled
and accessed on a �need-to-
know� basis (e.g., network models, critical performance
factors, system interfaces, etc.). The
architecture core team considers what classes of EA users will
need what information:
contractors, management, and Agency staff typically focus on
particular areas of the enterprise,
and thus may only need particular subsets of the EA. An EA
that includes a comprehensive view
of the details of the Agency systems and infrastructure could be
organized in levels of detail and
distributed in a tiered format corresponding to security
clearances and the need to know.
Architecting is an ongoing, iterative process requiring regular
modification and maintenance.
Whenever the EA changes, it is imperative to update the
architecture models. A detailed
discussion of architecture maintenance is presented in Section
7.
43
March 15, 2002
6. Use the Enterprise Architecture
Using the EA to implement new projects provides a positive

impact on the enterprise. If the EA
is not successfully used, the entire development effort to this
point is for naught. In this section,
the emphasis shifts to integrating use of the EA across multiple
activities and organizational
groups. Success depends on active management, proactive
architects, and receptive project
personnel. It also depends on integrating the EA process with
other enterprise life cycle
processes, particularly the CPIC process.
Establishing the EA captures the state of the enterprise and the
plan for its future�literally a
snapshot of the enterprise and its plans for improvement. For
the EA to provide the strategic
information asset base as intended, it should become a crucial
tool for decision support and
communication in the mainstream of daily business operations.
Accepting and applying this asset
in the Agency�s operational paradigm is a technical and
cultural challenge.
The EA is managed as a program that facilitates systematic
agency change by continuously
aligning technology investments and projects with agency
mission needs. The EA is updated
continuously to reflect changes in operational and investment
priorities that may arise due to
legislation, budget constraints, or other business drivers. It is a
primary tool for baseline control
of complex, interdependent enterprise decisions and
communication of those decisions to agency
stakeholders. The sequencing plan provides a strong guide for
agency decision-makers to use as
they consider proposed projects. If a project is not represented
in the sequencing plan, it should

either be denied funding, since it is not aligned with the agency
strategy as embodied in the EA,
or it should be granted a waiver if it is a legitimate deviation
driven by valid changes in the
agency�s environment which have not yet been reflected in the
EA. It should be noted that it is
crucial that the EA represent the current agency strategies and
imperatives as closely as possible,
since any lag in the EA may constrain the agency�s ability to
effectively execute its mission until
a waiver is issued or the EA is adapted. In cases where a
waiver is granted, the cause of the
waiver should be examined and appropriate changes to the EA
considered if the cause represents
a valid and ongoing gap in the EA.
6.1. Integrate the EA with CPIC and SLC Processes
Investment management and systems development/acquisition
are closely linked with the EA
processes.6 The agency should only make investments that
move the agency toward the target
architecture and these investment decisions should comply with
the sequencing plan. The EA,
CPIC, and SLC (systems life cycle) processes are integrated to
best suit the agency�s particular
organization, culture, and internal management practices.
Certain basic relationships exist
between these functions and they have a common focus: the
effective and efficient management
of IT investments. The dialogue across CPIC, SLC, and EA
processes is continuous, cooperative,
and facilitated by agency commitment to an integrated process.
Details of this relationship
between management processes and the capital planning and
investment control process are

discussed in the Architecture Alignment and Assessment Guide
and the Smart Practices in
Capital Planning document. GAO�s Information Technology
Investment Management
6 As discussed as the beginning of this guide, these processes
are also linked with information security management
processes and human capital management processes. Linkages
with these latter two processes, however, are not
explicitly addressed in this guide.
A Practical Guide to Federal Enterprise Architecture Use the
44
February 2001
Framework provides a structured approach to IT investment
management that is consistent and
integrated with the principles of good EA and system life cycle
practices.
Each agency designs its own CPIC process for structuring
budget formulation and execution to
ensure that investments consistently support strategic goals.
All IT projects should align with the
agency mission and support agency business needs while
minimizing risks and maximizing
returns throughout the investment�s life cycle. The target
architecture and the sequencing plan
provide information for the three phases of the CPIC process.
In the Select Phase, the agency
determines if the proposed investment meets business decision

criteria. To assess the business
alignment of the proposed investment, decision makers use, for
example, the business case,
acquisition plan, and the project plan to determine whether the
proposed investment aligns with
the sequencing plan and target architecture. In the Control
Phase, decision makers monitor
business and technical compliance as demonstrated in, for
example, the updated business case,
system architecture, systems design, and test program. In
addition, the investment should be
monitored to ensure continuing alignment with the agency�s
strategic and business goals, which
may shift over time. In the Evaluate Phase, the decision makers
perform a final assessment to
determine technical and strategic compliance with the EA. The
results, including findings of
noncompliance, should influence strategic planning for new
business and IT projects, which
could then lead to changes in the EA.
Figures 14 and 15 illustrate one example of a CPIC and
architecture management process
developed by the U.S. Customs Service (Customs)�the
Investment Management Process (IMP).
There is a detailed discussion of their IMP in the U.S. Customs
Service Enterprise Architecture
Blueprint (August 1999). This framework enables compliance
with the EA and the necessary
governance for application to the Enterprise Life Cycle
Management activities.
Projects are managed and executed through the agency�s
systems development/acquisition life
cycle. Each agency may have its own unique approach to the
systems development/acquisition

cycle, but certain fundamental elements such as requirements,
systems and software architecture,
design, and test are common.
Architecture Roles
Respond to
Business
Change
Investment Process /Architecture Project
Assessment Framework
1
Assess
Business
Alignment
2
Assess
Business Case
Proposal
Assess
Technology
Compliance
Target IT
App.Port /
Infra.

Initiatives
Aligned per IT Strategy
Alignment
Scorecard
(SELECT)
Develop
Business
Case
Compliance
Assessment
5
(SELECT)
Project
Initialization
Assess Waiver/
Exception Request
Enterprise
Design
Patterns
Acceptable Alignment
Acceptable
Compliance

Unacceptable
Conformance
Unacceptable Alignment
Unacceptable
Compliance
Proposed Concept
Report
TRM
Standards
4
Evaluate
Architecture
Compliance
IRB
Report
Audit Reports
(EVALUATE)
Evaluation
Disapproved
3
(CONTROL)
� Define

� Build
� Implement
� Operate
Figure 14. IMP/Architecture Project Assessment Framework
45
February 2001
� Respond to user request
(EAPMO)
� Respond to market direction
(EAPMO)
� Respond to vendor direction
(Domain Owner)
� Annual strategic planning
event (EAPMO)
� Track emerging technologies
(EAPMO/DO/SME)
Architecture Roles
Technology Architecture Management
5

Issue Waiver /
Exception
6
TRM Waiver
Containment
BlockApproved One-Time Exception
Perform
Technology
Insertion and
Renewal
Unacceptable Conformance
Triggers 7
Conduct
Standards
Review
TRM
Standards
&
Strategies
Standards
Review
Required
TRM

Structure
Disapproved
Enterprise
Filter
Initiate waiver/exception
request per TRC
Report
Assess
Technology
Compliance
TRM
Standards
Events
Figure 15. Architecture Management
In order for an agency to successfully deploy an integrated
process as described in this document
it needs to train its personnel, define and implement compliance
criteria, and conduct integrated
reviews. Each of these critical aspects is discussed in the
subsections that follow.
6.1.1. Train Personnel
It is the responsibility of agency executive management to
institutionalize the control structures
for the EA process as well as for the agency CPIC and SLC
processes. For each decision-making

body, all members should be trained, as appropriate, in the EA,
the EA process, and the
relationship of the EA to the CPIC and SLC. Specific training,
at various levels of detail, should
be tailored to the architecture role of the personnel.
Anyone who might bring forward a proposal to the Capital
Investment Council (CIC)�such as
domain managers and project managers�should understand the
requirement for EA assessments.
To adequately evaluate an investment proposal, the CIC needs
specific information. Individuals
creating the investment proposals should be trained, as
appropriate, in the criteria and submission
requirements. Appropriate training will prepare the staff to
assess the compliance and correct any
deficiencies that exist prior to submission.
6.1.2. Establish Enforcement Processes and Procedures
The processes and procedures that enforce the application of EA
guidance and those that ensure
its consistency with the �reality� of the enterprise are critical
components in EA
institutionalization. The EA processes and procedures
implement the Executive EA Policy (see
Section 3.1.2). The Enforcement Policy defines the standards
and process for determining the
compliance of systems or projects with the EA and procedures
for resolving the issues of non-
compliance. A project�s technical and schedule compliance is
typically assessed in terms of how
it conforms to the content, intent, and direction set by the EA.

46
February 2001
The processes and procedures should answer the following
questions:
• How and when will projects submit project plans to be
reviewed for EA compliance?
• Who will be responsible for compliance assessment and/or
justification of waivers?
• How will compliance and non-compliance be documented and
reported?
• How will outstanding issues of non-compliance be resolved
and/or waivers be processed
and approved?
• Who will be responsible for processing, authorizing, and
reassessing waivers?
• What will be the content and format of waiver submissions?
• If a waiver is granted, how will projects achieve compliance in
the future?
• What are the ramifications if a non-compliant project is not
granted a waiver (e.g.,
funding and/or deployment restrictions)?
The processes and procedures should, of necessity, allow
exceptions. In many cases, existing

systems in the operations and maintenance phase should be
granted exceptions or waivers from
the technical standards and constraints of the EA. Alignment of
some legacy systems with new
standards could be unreasonably costly and introduce additional
risk to the business users. Also,
it is likely that certain initiatives and innovations, such as
investigative efforts and proofs-of-
concept, will not comply with the EA.7
6.1.2.1. Define Compliance Criteria and Consequences
Requirements for EA assessments include criteria for
compliance, waivers, and corresponding
submission requirements. In the event of a non-compliant
proposal a request for waiver should
be prepared and formally submitted to the Technology Review
Committee (TRC). The waiver
provides analytical and defendable justification of design
changes, budget deviations, and
impacts. The waiver request includes identification of the
operational, economic, and
productivity impacts of any waiver. The corresponding impacts
of the waiver not being approved
should also be provided to the TRC. The TRC recommends to
the CIC approval or denial of
requests for waivers. The CIC approves or denies requests for
waivers based on this information.
The TRC approves waivers according to the agency�s
enforcement process. Each waiver that is
approved presents an opportunity for feedback on the EA and
the EA process. For example, the
need for a waiver may indicate that the target architecture, the
transition analysis, and/or the
sequencing plan are too constraining or too rigidly defined. In

addition, rapidly evolving
requirements may necessitate revisiting existing plans outside
the normal EA process, since
waivers may indicate that the defined target environment does
not reflect agency needs. Also the
need for reworking proposals may indicate problems in training
for compliance.
The CPIC process should respect the integrity of the sequencing
plan while considering the
strategic and tactical value of all proposals that pass through
CPIC checkpoints. Project critical
success factors continue to be met. This double check on
project proposals ensures that all
funded projects meet the conditions necessary for success.
These conditions include, but are not
limited to:
• Consistency with the EA
7 After a non-compliant investigative or innovative effort is
commenced and appropriately controlled during its
execution, it may become a candidate project for consideration
by the EAESC and TRC. Such a project might well
offer proposed changes to the EA.
47
February 2001
• Satisfaction of project baseline cost, schedule, capability, and

business value
commitments
• Compliance with agency-published investment management
policies and guidance
• Explicit support by executive management.
6.1.2.2. Set Up Integrated Reviews
The CPIC Select, Control, and Evaluate Phases require reviews
of proposals and project
performance whenever significant change is contemplated or at
logical milestones or key decision
points (KDPs) in the systems life cycle. KDPs are points where
management should take action
regarding project scope, approach, funding, etc. EA
enforcement should be applied at KDPs,
when possible, since it is at those points that senior
management will convene to consider
investment decisions. Reviews may also occur periodically, for
example as part of an integrated
capital planning/budget cycle. Since the EA is a major
management tool for monitoring and
guiding change within the agency, the important outcome is to
schedule reviews to ensure that
planned investments stay on schedule, within budget, and
achieve defined goals. In addition,
these reviews provide the opportunity for the EA team to
communicate changes in the target
architecture and sequencing plan to the agency as a whole, as
well as to the specific projects that
will be affected. Deviations from compliance may be addressed
by implementing changes to the
project or by a waiver request.
6.2. Execute the Integrated Process

Progress toward the target architecture is accomplished through
programs and projects. New and
follow-on projects are (1) initiated and selected, (2) executed
and controlled, and (3) completed
and evaluated. The following sections show the information
flow for each of these three CPIC
phases with emphasis on how the EA supports the whole
process.
6.2.1. Initiate New and Follow-on Projects
Sponsors propose projects under different circumstances:
• New projects are identified and sponsored based on the
domain owner�s interpretation of
the sequencing plan. A project to fill the gap may result in
business process
reengineering, IT development, and/or change to the
infrastructure.
• Planned follow-on projects are anticipated, but still need
review by the CPIC and an
assessment of the completion of dependencies on previous
projects.
• A need for an architectural improvement is identified, e.g., to
incorporate a new standard
or technology identified by the target architecture, gap and
transition analysis, and the
sequencing plan.
• A sponsor may initiate a project based on a business or
technical need that is not
identified in the sequencing plan. In this case, a waiver needs
to be approved and the EA

team should respond by considering modifications to the EA.
This is only possible based
upon a formal waiver and approval process including the
EAESC, CIC, and other
executive-level panels.
Figure 16 depicts the information flow when a project is
initiated. It serves as a guide through the
cycle of proposal preparation, aligning the proposed project
with the EA, and making the decision
to fund the effort. The information flow ensures that
requirements are being addressed and that a
proposed implementation meets expectations and requirements.
48
February 2001
CPIC
Process
Investment
Council
(CIC)
Propose
Programs
and
Projects Business Requirements
IT Needs

Technology Updates
Program/Project Proposal
with EA impact assessment &
proposed EA changes
EA Products
Program/Project Proposal
EA Assessment
Approved Waivers
Recommendations
Decision to Launch, Conditions
EA Updates
EAESC
TRC
Architects
Program Managers
Domain Owners
Architects
EA
Repository/Tool
Manage EA
Assess/Align
Sel
ect
Figure 16. Define New and Follow-on Programs/Projects

6.2.1.1. Prepare Proposal
The sponsor of a project prepares a proposal in accordance with
predefined agency requirements.
The proposal presents the business case for the project and
defines a business solution using
information from the EA as well as other sources. Business
requirements, IT needs, and
technology updates all feed the definition of the effort being
planned. Domain owners and
program or project leaders prepare the proposal by:
• Mapping objectives to requirements and relationships between
high-level requirements to
the business objectives
• Documenting a high-level business case
• Providing a cost study
• Defining a business case solution and determining the level of
impact introduced into the
IT environment
• Ensuring reasonableness of risk, time, and cost
• Ensuring that technical and business implications to the
organization are addressed.
The domain owners and program or project leaders should
comply with the architecture project
reporting requirements and will provide answers to compliance
criteria in the proposal
documentation. For selection, they will show that the
investment supports the agency mission,
that the investment meets the business criteria, and that it is
consistent with the target architecture
and sequencing plan. If an investment deviates from the

sequencing plan, the reasoning for the
deviation should be documented.
49
February 2001
The Chief Architect and the architecture team can advise
program/project leaders on business
case/solution development. They contribute to the development
of investment proposals and
work to facilitate progress through the CPIC. They have a
specific interest in ensuring that
projects identified in the sequencing plan are funded, and may
actually introduce such projects.
For other projects, they will support project leaders in initiating
and developing proposals.
6.2.1.2. Align the Project to the EA
The Chief Architect and the architecture group perform proposal
assessments. Table 5 describes
the types of assessments that occur as projects are subjected to
periodic, iterative EA reviews. In
the initial phase of defining and selecting a project, the
emphasis is on the business alignment,
business case solution, sequencing plan, and to a limited degree,
technical compliance. As the
system concept matures, business and technical compliance are
equally addressed. Details of this
alignment with business and the CPIC processes are discussed
in the Architecture Alignment and

Assessment Guide (see Appendix F for a complete reference
listing).
50
February 2001
Table 5. EA Review Goals
Type of EA Reviews Review Purpose/Goal
Business alignment
Determine if the proposed project aligns with Agency strategic
plans, goals,
and objectives. The goal of the review is to ensure that the
expected
business outcomes of the project are aligned to concept and
high-level
project requirements.
Business case solution
Examine the proposed solution, at a high level, to determine the
impact
introduced into the organization�s IT environment. The goal of
the review is
to ensure that the proposed solution supports both the business
and technical
architecture.
Sequencing plan

Determine whether the proposed investment is consistent with
the sequence
and priorities in the plan. The goal of the review is to ensure
progress
toward the target architecture.
Technical compliance
Determine whether the architecture of the proposed solution
complies with
the enterprise standards, the various architecture levels, and
methodologies.
The goal of this review is to ensure technical compliance of IT
projects.
Upon assessing the project�s alignment to the EA, the
architects may make recommendations and
provide support to bring non-compliant proposals into
compliance. In cases where a waiver had
been requested, the architects may respond with an independent
assessment of operational,
economic, and productivity impacts of the waiver.
6.2.1.3. Make Investment Decision (CPIC Select Phase)
The CIC is responsible for the evaluation of new proposals and
for oversight of ongoing
investments. Among other criteria, CIC decisions are based on
determinations that the proposed
projects submitted by the business managers are aligned with
agency strategic plans, goals, and
objectives. The business proposal and the results of the
architecture assessments, including
waivers, are reviewed by the investment decision makers. The
same conditions and
consequences pertain to follow-on projects and incremental
funding.

In certain circumstances, it may be necessary to approve a
proposal that does not conform to the
target architecture and/or the sequencing plan. The conditions
under which a waiver is granted
and the operational, economic, and productivity impacts of the
waiver are considered in the
investment decision. Under most circumstances, any proposal
that is not compliant or otherwise
does not qualify should be denied a waiver. Non-compliant
initiatives may be approved for
research, concept development, prototyping, and other purposes.
These efforts may challenge
assumptions currently accepted in the EA and may lead to
breakthroughs that could significantly
improve the EA. Nevertheless, the conditions under which a
project may proceed should be
unambiguous and clearly stated in the EA policy and should be
documented in the CIC�s
investment decision. Once the project has been acted on, there
may be recommended changes to
the EA or the requirement for additional detail to enhance the
EA. The funding decision will
have an impact on the sequencing plan and potentially the target
architecture and transition
analysis.
51
February 2001
6.2.2. Execute the Projects

Once funding is received, the project can be initiated. Figure
17 depicts the information flow as
the project cycles through the integrated EA, SLC, and CPIC
processes. A project will pass
through this cycle multiple times. There are continuous
interactions between the project
implementers and the architecture, with more formal reviews at
prescribed milestones.
Manage
Programs
and
Projects
CPIC
Process
Co
ntr
ol
Manage EA
Assess/Align
Business & IT Priorities
Dependencies
Architecture
Design & Constraints
Proposed EA Updates
Systems Architecture
Requirements and Design

Program/Project Progress
EA Products Program/Project Progress
Requirements and Design
Architecture Assessment
Recommendations
Funding decision to continue,
conditions, waivers, redirection
EA Updates
Program Managers
Domain Owners
Architects
EA
Repository/Tool
EAESC
TRC
Architects
Investment
Council
(CIC)
Figure 17. Execute Programs/Projects
6.2.2.1. Manage and Perform Project Development
Program/Project Leaders use the EA as guidance and constraints
on systems architecture and
systems design. The project management goal is to ensure that

the proposed solution supports the
EA. The project�s requirements, systems and/or software
architecture, design, and test program
are developed using concepts, constraints, and recommendations
from the EA. Systems
migration strategies may be found in the sequencing plan.
The Chief Architect and the architecture group contribute to
projects as consulting architects.
Their role in the requirements and design phases is to provide
guidance to the business unit and
its project teams on technical architecture-related issues and
emerging trends in the industry.
They make recommendations for relevant parts of the EA (e.g.,
business, information, data,
application, infrastructure, security, and standards).
Initial requirements, systems and/or software architecture, and
design rely heavily on existing
artifacts from the EA. As the project progresses, products are
produced that enhance and expand
the level of detail in the EA. These products, generated
according to the SLC requirements, are
contributed and incorporated into the EA repository.
6.2.2.2. Evolve EA with Program/Project
It is the responsibility of the Chief Architect and the
architecture core team, with direction from
the EAESC, to maintain EA alignment with the organization as
it evolves. Throughout a
project�s development/acquisition phase, the requirement is to
maintain the alignment of the

52
February 2001
evolving solution with the target architecture and sequencing
plan. The architecture team reviews
the business and technical solution throughout the life cycle and
assures compliance with the EA.
In incremental reviews, assessments are performed to determine
whether the project�s products
and documentation (the functional analysis, general design, and
detailed design) comply with the
EA products that have been approved through previous review
processes. The projects provide
additional information as progress is realized. The goal is to
maintain alignment of the project
with the EA throughout development to avoid construction of
systems that do not meet the
organization�s needs.
In addition to systems architecture and design specifics that
flesh out the EA at the lower levels of
detail, the projects provide new ideas to the EA for changes to
the target architecture and
transition increments. The EA should be reviewed regularly and
synchronized with the enterprise
life cycle and investment decisions. The Chief Architect and
the architecture team incorporate
this feedback into the EA maintenance process. See Chapter 7
for more detailed discussion on
EA maintenance.
6.2.2.3. Assess Progress (CPIC Control Phase)

The CPIC Control Phase ensures that the investment is being
managed within the planned cost,
schedule, and design and that the investment will operate
effectively within the technical
infrastructure. Systems development and acquisition is
inherently risky. Managers and architects
provide information according to the reporting requirements for
architecture assessments, and this
information is used as the basis for decisions about continued
funding, imposition of development
constraints, and possible redirection of technical efforts. This
control is imposed to manage and
mitigate risk. Investment decisions rely on analysis of progress
reports, compliance assessments,
and deviations and waivers to arrive at implications on cost,
schedule, and performance.
6.2.3. Complete the Project
Most projects are interdependent on other development projects
and legacy systems. Many are
followed by additional increments of capability or by additional
operations and maintenance
(O&M) efforts. Almost all are integrated with other systems
when they become operational.
When the project is complete, there is a final assessment of
impacts on the agency, the EA,
enterprise operations, future systems, and consequently, future
investment and funding decisions.
Figure 18 depicts the information flow upon completion of a
program or project.

53
February 2001
Complete
Programs
and
Projects
CPIC
Process
Evaluate
Business & IT Priorities
Dependencies
Architecture
Design & Constraints
Proposed EA Updates
System Architecture
Requirements
Design
Test Results
Sequencing Plan
EA Products
Requirements & Design
Architecture Assessment
Approved Waivers
Design & Recommendations
Process Improvements

Evaluation
EA Updates
Program Managers
Domain Owners
Architects
Manage EA
Assess/Align
EAESC
TRC
Architects
EA
Repository/Tool
Investment
Council
(CIC)
Figure 18. Evaluate Programs/Projects
6.2.3.1. Deliver Product
At the end of a program or project, system and updated business
processes have been integrated
into the environment. An O&M support is defined, training is
provided, and a complete set of
documentation is communicated to the operations and
maintenance staff. Material is provided for
the EA repository with the delivered product, to the level of
detail appropriate to depict the new

baseline architecture. A support and deployment strategy is
activated for parallel or turnkey
operations. There is a transition from the
development/acquisition environment and management
to O&M environment and management. At this time
opportunities for the reuse of work products
from this project to other projects should be considered.
6.2.3.2. Assess Architecture
The EAESC performs an ongoing assessment of the EA. There
is much to be learned by
evaluating the extent to which a project has complied with the
sequencing plan, based upon the
target architecture. The experience and lessons learned
contribute to the ongoing robustness of
the EA processes.
The final assessment of the project with respect to the
enterprise architecture involves review of
the original business case, the implementation of the business
and technical solutions, the
sequencing plan, and final disposition of waivers. The result of
the final assessment is the
updating of the baseline architecture with changes implemented
in business processes, IT
products, deployment, technology, and operations. The
sequencing plan, target architecture, and
gap/transition analyses are also updated to show completion of
the program/project. Waivers will
either be permanent or may be accompanied by plans for future
work. Other results can influence
future priorities and dependencies in the sequencing plan.
These results provide lessons learned
for process improvement and form the basis of business cases
for other new programs or projects.

54
February 2001
6.2.3.3. Evaluate Results
The EAESC and CIC assess program/project results for impact
to the EA and the organization�s
business processes. The CPIC Evaluate Phase shows that the
investment meets the planned
performance goals and identifies any reasons for updating the
EA. After considering the results
of impact to the EA, the conditions that may have necessitated a
waiver may prove sufficiently
pervasive to justify altering the EA to accommodate future
investment proposals with similar
requirements.
6.3. Other Uses of the EA
The EA provides guidance and source information for
requirements analysts, designers,
engineers, and test planners to reference and build upon
material executing their responsibilities.
The following are examples of uses of the EA outside the
normal project cycle:
• Even if an agency is not involved in a major IT upgrade, the
EA is a resource for
managing inventory, routine maintenance, and queries.
Analysis of the baseline

architecture can identify opportunities for consolidating
network services, floating or site
software licenses, and economies of scale for equipment and
services.
• The agency can use the EA as a training aid, drawing on its
graphics and descriptive
material for instruction in the business of the agency or in the
technology that is in use or
planned.
• Investigative initiatives and proofs-of-concepts should be
performed using the EA as a
reference. The criteria for EA compliance should be
considered, but not mandated, in
such efforts. Non-enforcement allows pursuit of innovations
that could change the EA,
but alignment and impacts of architecture deviations should be
included with the results
of the experiments.
• Agencies may fund small, low risk projects outside of the
CPIC. Program/project
managers should still rely on the EA for guidance for the
business solution, architectures,
requirements, and design of their effort. Compliance with the
EA will facilitate
integration into the enterprise, and the baseline architecture
should be kept current with
their products.
• O&M projects rely on the baseline architecture for context.
The O&M priorities and
decisions may be influenced by the sequencing plan and target
architectures. For
example, a planner may conclude that soon-to-be-retired IT

systems are more economical
with minimal O&M support.
55
February 2001
7. Maintain the Enterprise Architecture
The EA is, by definition, a set of models that collectively
describe the enterprise and its future.
Its value to the business operations is more than just IT
investment decision management. The
EA is the primary tool to reduce the response time for impact
assessment, tradeoff analysis,
strategic plan redirection, and tactical reaction. Consequently,
the EA must remain current and
reflect the reality of the organization�s enterprise. In turn, the
EA needs regular upkeep and
maintenance�a process as important as its original
development.
Maintaining the EA should be accomplished within the
enforcement structure and configuration
control mechanisms of the organization. EA maintenance is the
responsibility of the CIO, Chief
Architect, and the EAPMO. Using a system of oversight
processes and independent verification,
the architecture core team periodically assesses and aligns the
EA to the ever-changing business
practices, funding profiles, and technology insertion. The EA
should remain aligned to the
organization�s modernization projects and vice versa. The
management controls to accomplish
EA maintenance are the same ones established to initiate the

program and to develop the EA.
7.1. Maintain the Enterprise Architecture as the Enterprise
Evolves
If the EA is not kept current, it will quickly
become �shelfware��yet another well-
intentioned plan for improving the enterprise.
Perhaps even more damaging, if the EA fails to
embody the agency�s most current strategy it
may limit the organization�s ability to meet its
goals and achieve its mission. The EA
necessitates a specific organizational and
process structure that will ensure the currency
of EA content over time. The EA should
reflect the impact of ongoing changes in
business function and technology on the
enterprise, and in turn, support capital planning
and investment management in keeping up with those changes.
Consequently, each component
of the EA�baseline architecture, target architecture, sequencing
plan, and all the products that
constitute them�need to be maintained and kept accurate and
current.
7.1.1. Reassess the Enterprise Architecture Periodically
Periodically, it is necessary to revisit the vision that carried the
organization to this point and to
re-energize that vision within the Agency. Continually,
typically in conjunction with the CPIC,
the EA should be reviewed to ensure that:
• The current or baseline architecture accurately reflects the
current status of the IT
infrastructure

• The target architecture accurately reflects the business vision
of the enterprise and
appropriate technology advances that have occurred since the
last release
• The sequencing plan reflects the prevailing priorities of the
enterprise and resources that
will realistically be available.
A Practical Guide to Federal Enterprise Architecture Maintain
the Enterprise Architecture
56
February 2001
The assessment should generate an update to the EA and
corresponding changes in dependent
projects. The baseline should continue to reflect actions taken
to implement the sequencing plan
and actions otherwise taken to upgrade the legacy environment
as the organization modernizes.
The EA assessment and update should be managed and
scheduled to in turn update the Agency
strategic plan and process for selecting system investments.
7.1.2. Manage Products to Reflect Reality
An Agency is a business entity that remains responsive to
business drivers (including new
legislation and executive directives), emerging technologies,
and opportunities for improvement.
The EA reflects the evolution of the Agency, and should
continuously reflect the current state

(baseline architecture), the desired state (target architecture),
and the long- and short-term
strategies for managing the change (the sequencing plan).
Figure 19 illustrates the type of
continuous changes that should be illustrated by the EA. At no
time will a specific target
architecture ever be achieved�with each iterative update of the
EA, all three components shown
in the figure and the timeline are recast. The target architecture
is a vision of the future that
evolves in advance of it being achieved.
Baseline Transition Target
Im
p
le
m
en
ta
ti
o
n
S
ta
tu
s
Sequencing Plan

Target Architecture
Baseline Architecture
Figure 19. Enterprise Architecture Transition
7.1.2.1. Ensure Business Direction and Processes Reflect
Operations
A critical responsibility for the EA program is to monitor the
changes in the business operations
that affect the organization, the business processes, and the
strategic direction of the business.
Changes in business processes that were initiated by process
improvement, organizational
change, or mandate, may be reflected in the business artifacts of
the baseline architecture.
Business unit management and their SMEs should report
changes in their organizations and
initiatives to the Chief Architect and architecture core team.
Correspondingly, the Chief
Architect ensures that the architecture core team is gaining
sufficient insight into the evolution of
the operations. Plans and expectations may change as priorities
shift over time�these may need
to be reflected in modifications to the target architecture.
Priority shifts and the realities of
57
February 2001

budget constraints may need to be reflected in the sequencing
plan. Thus, EA maintenance will
be both reactive and proactive.
7.1.2.2. Ensure Current Architecture Reflects System Evolution
Despite the best operational management and systems
maintenance planning, the current
architecture and infrastructure may need unanticipated changes.
As each new system is deployed
and each legacy system reaches a maintenance milestone (e.g.,
renewal of maintenance
contracts), the baseline for the current architecture changes. In
addition, system patches should
be introduced frequently or system design changes implemented
to respond to high-priority
requests. These changes should be reflected in the current
architecture artifacts.
7.1.2.3. Evaluate Legacy System Maintenance Requirements
Against the Sequencing Plan
As the current architecture evolves to reflect the reality of the
legacy systems, new information
may emerge that will change the maintenance plans and
subsequent organizational and systems
transition. For example, system vendors may unexpectedly
cease supporting critical components
of the Agency�s infrastructure. Alternative actions should be
weighed and decisions made
regarding replacing the components, paying for additional
specialized contractor support, or
changing the strategy for phasing in other components in the
target architecture. The total cost of
ownership of the system versus alternative systems, as well as
outsourcing, may need to be

considered. All of these considerations, alternatives, and
decisions may dramatically alter the
sequencing plan.
7.1.2.4. Maintain the Sequencing Plan as an Integrated Program
Plan
The development of the sequencing plan is linked to the
acquisition and enterprise engineering
processes. The architect works in partnership with managers
who understand the evolving
business objectives, as well as the individual program
management offices that oversee the
acquisition and development of new IT systems. The
sequencing plan should be maintained,
reviewed and validated, and approved to continually reflect the
organization�s mission and vision
just as any product in the architecture package and plan. The
sequencing plan delineates the IT
management scheme for systems insertion in support of the
organization�s long-term business
strategies.
7.2. Continue to Consider Proposals for EA Modifications
While the enforcement process helps to ensure that the EA
guidance is followed, it is
unreasonable to assume that new business priorities and
technologies, funding issues, or project
challenges will not require modification to the plans, baselines,
and products incorporated in the
EA. Emerging technologies continue to necessitate changes to
the enterprise. Many of the
considerations for changes to the EA are the same
considerations that needed to be addressed
during its development. Also, the architectural principles need

to be continuously addressed.
Proposals for modifying the architecture should address the
following questions among others:
• How does the proposed modification support the organization
in exploiting IT to increase
the effectiveness of its organizational components?
• How does it impact information sharing and interoperability
among organizational
components?
• What are the security implications? For example, will the
modifications need
certification of enhanced systems?
58
February 2001
• Does the proposed modification use proven technologies and
conforming COTS products
to satisfy requirements and deliver IT services? Are these
technologies and related
standards in the industry mainstream, thereby reducing the risk
of premature
obsolescence?
• Does the acceptance of this proposal position other standards
or products for
obsolescence? If so, identify them.

• What is the impact on the organization and sub-organizations
if the proposal is not
accepted? What is the result of the cost-benefit analysis?
• What external organizations or systems will be affected?
What action will they have to
take?
• What is the estimated overall programmatic cost of the
proposed changes including
changes to the EA and/or redirection of dependent projects?
• What alternatives have been considered and why were they not
recommended?
• What testing, and by whom, should be completed for
implementations that will result
from acceptance of the proposal?
• What is the recommendation of the enterprise change control
board?
Proposals requesting modifications to the EA need to explicitly
address these issues. The
proposal should be presented to and reviewed by the TRC (for
review by architectural team and
SMEs) and passed to the EAESC with a recommendation. In
cases where the EAESC cannot
reach a consensus, a working group may be tasked to investigate
and propose recommended
actions.
59

February 2001
8. Continuously Control and Oversee the Enterprise
Architecture
Program
The purpose of EA control and oversight is to ensure that the
EA development, implementation,
and maintenance practices defined in this practical guide and
the related EA guidance referenced
in this guide (e.g., EA frameworks) are being followed, and to
remedy any situations or
circumstances where they are not and action is warranted.
Control and oversight is a continuous,
ongoing function performed throughout the EA life cycle
process.
Effective control and oversight is a key to ensuring EA program
success. Through it, information
is gathered for accountable decision makers to permit awareness
of whether effective EA
development, implementation, and maintenance activities are
being performed and EA program
goals are being met on schedule and within budgets. To do so,
the EAESC, the CIO, and the
Chief Architect should be vigilant in measuring and validating
that the EA process and product
standards defined and referenced in this guide are being
performed. To do less, diminishes the
probability of program success.
8.1. Ensure Necessary EA Program Management Controls Are
In Place and Functioning
In Section 3 of this guide, accountability for the EA program
was assigned to the EAESC, the

CIO, and the Chief Architect. Also, throughout this guide, EA
process and product standards or
controls that should be used to produce a complete, well-
defined, and useful EA have either been
defined or referenced. (For example, the guide specified the
need for a program management
plan to detail what will be done, when, and at what cost, as well
as the need to establish
management support functions, such as configuration
management, risk management, quality
assurance, change control, etc. Also, the guide references EA
frameworks and tools that help
define the content of the EA.)
Knowing the extent to which these controls are being
implemented on a continuous basis is
crucial to keeping the program on track. To do this, EAESC,
the CIO, and the Chief Architect
will respectively seek reports (oral and written, routine and ad
hoc, formal and informal) and
conduct first hand reviews to obtain the appropriate level of
visibility into what is occurring on
the program vis-à-vis what is expected. It is the responsibility
of these accountable entities to
define what information they need, when and how often they
need it, what the form and content
of the information should be, whether it should independently
validated or not, etc. Through such
information, the EAESC, the CIO, and the Chief Architect can
position themselves to know
whether established program management controls are in place
and functioning.
8.2. Identify Where EA Program Expectations Are Not Being
Met

Through their respective reports and review activities, the
EAESC, the CIO, and the Chief
Architect will be able to identify what, if any, EA program
expectations are not being met. For
example, if risk management has been effectively implemented,
program risk lists should be
regularly generated that assign a risk level based on impact and
probability, define risk mitigation
strategies, report on progress in implementing these strategies,
and whether the progress being
made is successfully addressing the risk item. Also, periodic
configuration audits should be
conducted to ensure that EA configuration items are being
defined, controlled, and reported. The
EAESC, CIO, and Chief Architect can also rely on independent
reviews by the quality assurance
function or a verification and validation agent to advise them of
deviations from expectations.
60
February 2001
These deviations may be program management plan-related,
such as omission of work tasks,
delays in the completion of work tasks, or additional costs to
complete work tasks; or they may be
management function-related, such as not following change
control procedures, not adhering to
the selected EA framework, or not engaging SMEs and domain
owners within business and
technical areas.

8.3. Take Appropriate Actions to Address Deviations
Management should take quick and decisive actions to correct
problems in light of established
priorities. Examples of actions include infusion of additional
resources (people, tools, or money),
establishment of contingency plans, and redefinition of EA
purpose and scope, introduction of
missing or strengthening of existing control mechanisms, and
increased oversight.
Any changes to the plans, projects, and/or architecture content
to address deviations should be
captured in an appropriate documentation trail, and should be
justified on the basis of costs,
benefits, and risks. Changes should be processed through
established change control processes
and board authority. The change documentation should
characterize the problem, solution, and
alternatives chosen and rejected in light of established
priorities.
8.4. Ensure Continuous Improvement
Figure 20 is adapted from a traditional representation of the key
success factors of Total Quality
Management (TQM). This figure represents the same key
success factors for enterprise
architecting:
• The EA process should be a key support element of the
operations of the Agency, and
should assist the operations function in performance of its
customer-focused mission.

• Successful enterprise architecting is not simply a function of
the IT organization, but
needs the total enterprise participation.
• Effective enterprise architecting needs �societal
networking,� that is, internal and external
communication and sharing of lessons learned.
The optimum EA process is not a single, one-time event, but is
continuous and thus offers the
opportunity for continuous improvement. This necessitates
ongoing control with monitoring,
reassessment, and refinement. As the discipline of enterprise
architecting enters the mainstream
of Agency operations, lessons can be learned from processes
that worked and those that did not
work, and from external organizations.
61
February 2001
Enterprise
Architecting
Operations
& Customer
Focus
Continuous
Improvement

Total
Participation
Societal Networking
Figure 20. Key Success Factors
Total participation makes continuous improvement everyone�s
responsibility. The EA�s central
role in enterprise evolution provides an excellent opportunity to
solicit feedback. Lessons learned
should be collected from the operational business owners, EA
teams, project development teams,
and investment management teams. Once the baseline EA has
been developed, the architecture
team should take stock of the lessons learned and communicate
them to their colleagues and
participating senior management in order to utilize them in
improving the process or the EA
itself. In addition, feedback and lessons learned should be
sought from other Agencies,
professional organizations, commercial corporations, and
consultants.
62
February 2001
63

February 2001
9. Summary
This Federal Guide to Enterprise Architecture development,
maintenance, and use offers a
practical �how-to� manual that will assist any Federal Agency
in initiating, developing, and
maintaining an EA in conjunction with other management
processes. Through an illustrative set
of �how-to� guidelines and directions, the EA process appears
in the context of the Enterprise
Life Cycle Management process, which consists of such
integrated processes as strategic
planning, system development/acquisition, Capital Planning and
Investment Control, human
capital management, and information security management.
While intended primarily for Federal
Agency architects, the guide is structured to meet the needs of
all Agency staff, from the Agency
Head to the CIO and line organization personnel.
The EA is, by definition, a model of the Agency�s enterprise
and its future direction. Its value to
the business operations should be more than simply IT
investment decision management. The
dynamic changes in technology and business practices impose
greater pressure on an Agency to
respond more rapidly to these stimuli than ever before. The EA
is the main tool to reduce the
response time for impact assessment, tradeoff analysis, strategic
plan redirection, and tactical
reaction.
Although EAs are required by legislative and regulatory
direction, they should be developed and

used for other reasons, too. Along with their importance in the
capital planning and investment
management arena, EAs provide a snapshot in time of the
Agency�s business and technology
assets. They are the blueprint to build upon�the roadmap to
systems and business migration.
They help mitigate risk factors in enterprise modernization,
identify opportunities for innovative
technology insertion, and aid executives and managers in key
decision making at all levels of the
organization. And these are but a few of the benefits of
maintaining a thorough EA.
The EA process is a long-term, continuous effort. Once
developed, the EA is a �living� entity
with many parts, whether in the form of a document, database or
repository, or web page. To
remain current and of optimal value, this �living architecture�
needs continual care and
maintenance. This, in turn, demands an organizational
commitment from top to bottom, since
Agency resources in time, money, and people should be
dedicated to the architecture�s
maintenance for the long term.
As an Agency begins its EA efforts, its architecture proponents
should secure corporate
commitment and buy-in from senior executives and all levels of
the organization. Without
engaging the entire Agency from the top down, the architecture
effort will face an uphill struggle
during much of its existence. Thus, the initial stages of the
architecture effort will need extensive
work�obtaining commitment and backing, grounding the EA in
an approved framework, and
establishing a functioning architecture structure within the

Agency organization.
As one of the first steps, the Agency�s Chief Architect should
ground the architecture effort in an
established framework, if at all possible, as discussed in Section
4 of this guide. The leading
frameworks offer suitable examples, like the FEAF, TEAF, and
DoD C4ISR Architecture
Framework discussed in this guide, for frameworks and
methodologies. As noted, a number of
agencies use variations on these frameworks. If these existing
frameworks do not meet your
Agency�s requirements, develop your own framework;
however, consider well the resources and
time needed to do so.
A Practical Guide to Federal Enterprise Architecture Summary
64
February 2001
It must be emphasized again that you should tailor the contents
of this guide to your own
organization�s needs: �one-size does not fit all� is the rule
for EA development and maintenance.
The guidance of this document can be used by all Federal
Agencies regardless of size and
resources, but this guidance should be tailored appropriately.
This guide is not intended as the
�one and only way� all organizations should accomplish EA
development, but rather as a
synopsis of the �best practices� currently employed in several
Federal Agencies and private
corporations. For example, in smaller organizations, multiple

roles and responsibilities may have
to be assumed by one individual, some of the committees and
groups will have smaller
memberships, and in general, participation will be on a more
modest scale. The EA itself, the
architecture products, and the associated data repository should
be developed as appropriate for
that individual organization. Not all Agencies will need the
same level of detail, nor the same
graphical representations. However, all Agencies will need to
ensure that they follow a top-down
approach to defining their respective architectures, and that at a
minimum the business views of
their architectures provide an enterprise-wide understanding of
operations.
Lastly, do not suffer alone! Take advantage of the architecture
community�s available resources.
A vast array of resources is at your disposal. This guide and
several of the other references
discussed in the document can be found on the Federal CIO
Council�s web site at
http://www.cio.gov. Many architecture frameworks are
documented in an extensive body of
literature and web sites. Standing working groups meet on a
regular basis, and there are
numerous annual conferences and seminars on the topic. See
Appendix F for a reference list of
related documents and web sites.
http://www.cio.gov/
65
February 2001

Appendix A: EA Roles and Responsibilities
The following matrix summarizes the functional roles and
responsibilities needed to support EA development, use,
and maintenance.
Role
Members
(If composite)
Responsibilities
Agency Head N/A Establishes EA as an Agency-wide priority;
charters an EA Executive Steering Committee
(EAESC); issues policy governing the
development, implementation, and maintenance
of the EA.
Capital Investment Council
(CIC)
• Agency/Department
Heads and their
Deputies
• Division/Business Unit
Heads
• Senior Budget Official
• Senior Procurement
Official
• Legal Counsel
• CIO
• CFO

Reviews the final proposed major information
technology investments and makes the final
funding decision, selects projects, monitors
progress, and evaluates results for investment
decision making.
Chief Architect N/A Selects the EA project team; works with
CIO to
develop EA Primer and architecture policy.
Oversees EA product development, use, and
refinement. Serves as owner of EA repository
and is responsible for architecture sequencing
plan. Reports directly to the CIO.
Chief Information Officer
(CIO)
N/A Engages and provides strategic direction to EA
Executive Steering Committee (EAESC);
enhances the Agency Head�s understanding and
appreciation for EA; appoints a Chief Architect;
markets the benefits of an Agency-wide EA to
other Agency executives and stakeholders via
collaborative forums; obtains participatory
commitment from senior executives; and
introduces enforcement measures.
Configuration Control Board
(CCB)
• Chief Architect
• Domain Owners
Responsible for monitoring and controlling
changes to the EA after initial development.

Configuration Manager N/A Responsible for maintenance and
configuration
control of all EA products.
Domain Owners • Business Unit Managers Provides senior-level
stakeholder and sponsor
participation; works with architecture team on
standards insertion and renewal, assigns
business line resources (subject matter experts
[SMEs]) and oversees review of business
architecture products.
Executive Steering Committee
Senior representatives from
all organizations and
Decides strategy, planning, and resource
allocation related to the development and
A Practical Guide to Federal Enterprise Architecture Appendix
A: EA Roles and Responsibilities
66
February 2001
Role
Members
(If composite)
Responsibilities
(EAESC) operational missions within

the agency; may include
senior executives (e.g.,
CIOs) within the business
community
maintenance of the EA products; approves the
initial EA; provides strategic direction and
ensures corporate support; sponsors, reviews,
and approves an overarching architecture
management strategy; approves significant
changes to the EA.
Program Management Office
(EAPMO)
• Chief Architect
• Architecture Core Team
Provides for management and control of EA
activities as a formal program; creates and
maintains the EA program plan and associated
EA project plans; defines tasks, resources, and
schedules; provides for program management,
monitoring, and control of EA product
development and maintenance.
Core Team
• Chief Architect
• Business Architect
• Systems Architect
• Data Architect
• Infrastructure Architect
• Security Architect

• Senior architecture
consultants
• Technical writer
Responsible for development and refinement of
enterprise and application architectures and for
populating the EA repository.
Develops formal standards requirements and
manages the architecture processes; provides
guidance to other teams.
Provides for administration of the EA processes;
influences agency officials so that project
resources are obtained/retained, objections are
properly handled, progress is maintained, and a
high-quality, usable architecture framework is
established.
Monitors and measures the architecture�s effect
on projects via process and product
measurements.
Independent Validation and
Verification (IV&V) Team
Neutral third party from the
Agency, external Agency,
or a contractor
Conducts architecture compliance evaluations;
provides quality assurance checking on program
information (cost, schedule, and performance
data), as well as the proper implementation of
the architecture methodology.
Quality Assurance Manager N/A Ensures quality of all
architecture products;

participates in architecture product working
sessions and reviews. Reports directly to CIO.
Risk Manager N/A Identifies, monitors, controls, and takes
action to
mitigate EA program risks. Reports directly to
CIO.
Subject Matter Expert (SME) Domain experts from within
the organization (one from
each business unit); may be
supplemented with outside
consultants
Supports Chief Architect and staff in
documenting the defined mission or business
requirements and related objectives; supports
definition of policies that impact business goals;
reviews EA repository products.
Technical Review Committee
(TRC)
• Domain Owners
• Senior Architectural
consultants
• Chief Architect
• Agency/Department
Business and Technical
representatives
Assesses business alignment, solution proposals,
and technical compliance; evaluates architecture
compliance; assesses waiver/exception requests;

and conducts standards review.
67
February 2001
Appendix B: Glossary
Term Source Definition
�As-Is� Architecture TEAF The current state of an
enterprise�s architecture (see
baseline architecture).
�To-Be� Architecture TEAF The target state of an
enterprise�s architecture (see
target architecture).
Architectural Artifacts FEAF The relevant documentation,
models, diagrams,
depictions, and analyses, including a baseline
repository and standards and security profiles.
Architecture Product IEEE STD 610.12 The structure of
components, their interrelationships,
and the principles and guidelines governing their
design and evolution over time.
Architecture DoD Joint Pub 1-02 A framework or structure that
portrays relationships
among all the elements of the subject force, system, or
activity.
Architecture John Zachman A set of design artifacts, or
descriptive representations,

that are relevant for describing an object such that it
can be produced to requirements (quality) as well as
maintained over the period of its useful life (change).
Architecture Repository TEAF An information system used to
store and access
architectural information, relationships among the
information elements, and work products.
Artifact TEAF An abstract representation of some aspect of an
existing or to-be-built system, component, or view.
Examples of individual artifacts are a graphical model,
structured model, tabular data, and structured or
unstructured narrative. Individual artifacts may be
aggregated.
Baseline Architecture The set of products that portray the
existing enterprise,
the current business practices, and technical
infrastructure. Commonly referred to as the �As-Is�
architecture.
Baseline Architecture FEAF Representation of the cumulative
�as- built� or baseline
of the existing architecture. The current architecture
has two parts:
• The current business architecture, which defines
the current business needs being met by the current
technology
• The current design architecture, which defines the
implemented data, applications, and technology
used to support the current business needs.
Business Architecture FEAF A component of the current and

target architectures
and relates to the Federal mission and goals. It
contains the content of the business models and focuses
on the Federal business areas and processes responding
to business drivers. The business architecture defines
Federal business processes, Federal information flows,
and information needed to perform business functions.
Capital Planning and
Investment Control
(CPIC) Process
OMB A process to structure budget formulation and
execution and to ensure that investments consistently
support the strategic goals of the Agency.
B: Glossary
68
February 2001
Enterprise TEAF An organization supporting a defined business
scope
and mission. An enterprise is comprised of
interdependent resources (people, organizations, and
technology) that should coordinate their functions and
share information in support of a common mission (or
set of related missions).
(EA)

FEAF/TEAF A strategic information asset base, which defines
the
business, the information necessary to operate the
business, the technologies necessary to support the
business operations, and the transitional processes
necessary for implementing new technologies in
response to the changing business needs. It is a
representation or blueprint.
Enterprise Architecture John Zachman The set of primitive,
descriptive artifacts that constitute
the knowledge infrastructure of the enterprise.
Policy
A statement governing the development,
implementation, and maintenance of the enterprise
architecture.
Products
The graphics, models, and/or narrative that depict the
enterprise environment and design.
Enterprise Engineering A multidisciplinary approach to defining
and
developing a system design and architecture for the
organization.
Enterprise Life Cycle TEAF The integration of management,
business, and
engineering life cycle processes that span the enterprise
to align IT with the business.

Federal Enterprise
Architecture Framework
(FEAF)
FEAF An organizing mechanism for managing development,
maintenance, and facilitated decision making of a
Federal EA. The Framework provides a structure for
organizing Federal resources and for describing and
managing Federal EA activities.
Framework FEAF A logical structure for classifying and
organizing
complex information.
Legacy Systems TEAF Those systems in existence and either
deployed or
under development at the start of a modernization
program. All legacy systems will be affected by
modernization to a greater or lesser extent. Some
systems will become transition systems before they are
retired. Other systems will simply be retired as their
functions are assumed by modernization systems. Still
others will be abandoned when they become obsolete.
Methodology TEAF A documented approach for performing
activities in a
coherent, consistent, accountable, and repeatable
manner.
Model TEAF Representations of information, activities,
relationships, and constraints.
Principle TEAF A statement of preferred direction or practice.
Principles constitute the rules, constraints, and
behaviors that a bureau will abide by in its daily

activities over a long period of time.
Principles FEAF A component of the strategic direction. In
terms of the
Federal Enterprise Architecture, the principles are
statements that provide strategic direction to support
the Federal vision, guide design decisions, serve as a
B: Glossary
69
February 2001
tie breaker in settling disputes, and provide a basis for
dispersed, but integrated, decision making.
Repository TEAF An information system used to store and
access
architectural information, relationships among the
information elements, and work products.
Sequencing Plan A document that defines the strategy for
changing the
enterprise from the current baseline to the target
architecture. It schedules multiple, concurrent, and
interdependent activities and incremental builds that
will evolve the enterprise.
Spewak EA Planning
Methodology

Planning, S.H. Spewak
Formal methodology for defining architectures for the
use of information in support of the business and the
plan for implementing those architectures developed
and published by Steven H. Spewak.
Standards FEAF A component of the FEAF. Standards are a set
of
criteria (some of which may be mandatory), voluntary
guidelines, and best practices. Examples include:
• Application development
• Project management
• Vendor management
• Production operation
• User support
• Asset management
• Technology evaluation
• Architecture governance
• Configuration management
• Problem resolution.
System IEEE STD 610.12 A collection of components organized
to accomplish a
specific function or set of functions.
Systems Development Life
Cycle (SDLC)
TEAF Guidance, policies, and procedures for developing
systems throughout their life cycle, including
requirements, design, implementation, testing,
deployment, operations, and maintenance.
Target Architecture FEAF Representation of a desired future
state or �to be built�

for the enterprise within the context of the strategic
direction. The target architecture is in two parts:
• Target Business Architecture�defines the
enterprise future business needs addressed through
new or emerging technologies
• Target Design Architecture�defines the future
designs used to support future business needs.
Transitional EA
Components
Representation of a desired state for all or part of the
enterprise for an interim milestone between the
baseline architecture and the target architecture. A
time-sliced set of models that represent the increments
in the sequence plan.
Zachman Framework
John Zachman, 1987
IBM Journal Article
Classic work on the concepts of information systems
architecture that defined the concept of a framework
and provided a 6x6 matrix of architecture views and
perspectives with products.
B: Glossary
70
February 2001

71
February 2001
Appendix C: Acronyms
BPR Business Process Reengineering
C4ISR Command, Control, Communications, Computer,
Intelligence, Surveillance
and Reconnaissance Architecture Framework
CASE Computer Aided Software Engineering
CBA Cost-Benefit Analysis
CCB Change Control Board and Configuration Control Board
CD-ROM Compact Disk-Read Only Memory
CIC Capital Investment Council
CIO Chief Information Officer
CM Configuration Management
CMM® Capability Maturity Model®
COE Common Operating Environment
CONOPS Concept of Operations
COTS Commercial-off-the-shelf
CPIC Capital Planning and Investment Control

CRUD Create, Read, Update, Delete
DoD Department of Defense
DOT Department of Transportation
EA Enterprise Architecture
EAESC Enterprise Architecture Executive Steering Committee
EAPMO Enterprise Architecture Program Management Office
EIEITC Enterprise Interoperability and Emerging Information
Technology Committee
FAWG Federal Architecture Working Group
FEAF Federal Enterprise Architecture Framework
FFRDC Federally Funded Research and Development Center
FOIA Freedom of Information Act
GAO Government Accounting Office
GPEA Government Paperwork Elimination Act
GPRA Government Performance Results Act of 1993
HTML Hypertext Markup Language
ICAM Integrated Computer Aided Manufacturing
ICOM Inputs, Controls, Outputs, and Mechanisms

D: Example Architecture Products
72
February 2001
IDEF Integrated Computer Aided Manufacturing Definition
Language
IEM Information Exchange Matrix
IER Information Exchange Requirement
IT Information Technology
IV&V Independent Verification and Validation
KDP Key Decision Point(s)
NIST National Institute of Standards and Technology
O&M Operations and Maintenance
OMB Office of Management and Budget
PMP Program Management Plan
PRA Paperwork Reduction Act
QA Quality Assurance
RM Risk Management
SDLC System Development Life Cycle

SID System Interface Description
SME Subject Matter Expert(s)
TEAF Treasury Enterprise Architecture Framework
TISAF Treasury Information Systems Architecture Framework
TQM Total Quality Management
TRC Technical Review Committee
TRM Technical Reference Model
UML Unified Modeling Language
USAF United States Air Force
WBS Work Breakdown Structure
73
February 2001
Appendix D: Example Architecture Products
D.1. Mission and Vision Statements
The Mission Statement describes the charter of the enterprise
and the scope of work the
enterprise needs to perform. The Vision Statement describes
critical success factors for
achieving the enterprise�s mission, including the resolution of
key issues involving

current performance of the mission. Vision Statements cover
both business process
aspects of the enterprise and IT aspects.
A sample outline for this work product includes:
• Organizational Mission Statement
• Customer Needs
• Business Goals and Objectives
• Business Vision
• Critical Business Issues
• Critical Success Factors.
D.2. Information Dictionary
Many of the architectural products have a graphical
representation. However, there is
textual information in the form of definitions and metadata (i.e.,
data about an item)
associated with these graphical representations. The
Information Dictionary provides a
central source for all definitions and metadata, including those
that may be provided for
convenience within another product as well.
At a minimum, the Information Dictionary is a glossary with
definitions of terms used in
the given architecture description. The Information Dictionary
consists of the attribute
table information for all the other work products. The
Information Dictionary makes the
set of architecture products stand-alone so that it may be read
and understood as a
standalone document without reference to other documents.
Each labeled graphical item (e.g., icon, box, or connecting line)

in the graphical
representation of an architectural product should have a
corresponding entry in the
Information Dictionary. The type of metadata included in the
Information Dictionary
for each type of item will depend on the type of architectural
product from which
the item is taken.
74
February 2001
D.3. Concept of Operations (CONOPS) Graphic
The high-level Concept of Operations (CONOPS) Graphic is the
most general of the
architecture products and the most flexible in format. It is
intended to portray the
operational activities of the agency (the enterprise) in a single
graphic. This work
product graphic provides a concise illustration of the business
of the enterprise.
The CONOPS Graphic employs generic icons that can be
tailored, as needed, and used to
represent various classes of players in the architecture. The
icons are used to represent
nodes (players), missions, activity or tasks, facilities,
equipment, etc. The CONOPS
Graphic shows the sequencing of activities and illustrates the
flow of information. The

graphic can also portray the geographic distribution of
architectural elements.
Figure 21 illustrates the three-dimensional nature of the military
battlespace and the
various players in the ground, sea, air, and space components of
the environment.
Components include naval ships, ground troops and equipment,
airbases, missile
batteries, aircraft, satellites; and their respective lines of
communications can
also be portrayed.
S T A T E
V E C T O R
Figure 21. DoD Battlespace Concept of Operations Graphic
75
February 2001
Figure 22 captures the operational environment of the U.S.
Customs Service for
performance of its Trade Compliance mission. The figure
shows the import of goods and
merchandise into the U.S. via sea, air, and ground modes of
transportation. It also shows
the inspection of those goods and the rejection of invalid or
illegal shipments. The
graphic portrays the movement of those goods to the eventual
consumers. The graphic

depicts the collection of duties, fees, and taxes and the flow of
those monies into the U.S.
Treasury. Customs also captures and collects a large volume of
statistical information at
its 300-plus ports of entry. The Trade Compliance CONOPS
Graphic shows the flow of
that information to the Customs Data Center and to over 100
other government agencies.
Rules and Regulations
Goods at the Port
Targeting and
Selectivity
Exam and Inspection
Warehoused
Destroyed
Forfeited
Returned Rejected Goods
Cleared Goods
Consumers
Consignees
USCS
NDC
Other Government
Agencies
Federal Reserve Bank
Statistical

Data
Importer/Broker
Figure 22. U.S. Customs Service Trade Compliance Concept of
Operations Graphic
76
February 2001
D.4. Activity Models and Trees
The Activity Model (also called a Business Process Model)
describes the applicable
functions associated with the enterprise�s business activities,
the data and/or information
exchanged between activities (internal exchanges), and the data
and/or information
exchanged with other activities that are outside the scope of the
model (external
exchanges). Activity Models are hierarchical in nature. They
begin with a single box
that represents the overall activity and proceed successively to
decompose the activity to
the level required for the architecture.
The Activity Model captures the activities performed in a
business process or mission
and the inputs, controls, outputs, and mechanisms (ICOMs) of
those activities.
Mechanisms are the resources that are involved in the

performance of an activity.
Controls, such as legislation or a business rule, represent
constraints on an activity. The
ICOMS are called activity constraints because each in some way
constrains the business
processes being modeled. The Activity Model can be annotated
with explicit statements
of business rules, which represent relationships among the
ICOMs. For example, a
business rule can specify who can do what under specified
conditions, the combination of
inputs and controls needed, and the resulting outputs.
The Activity Model identifies the mission domain of the model
and the viewpoint
reflected by the model. Textual descriptions of activity
definitions and business flows
should be provided, as needed. Annotations to the model may
identify the nodes
(business locations) where the activities take place or the costs
(actual or estimated)
associated with performing each activity.
Certain Activity Models are created using the IDEF (Integrated
Computer-Aided
Manufacturing (ICAM) Definition) modeling technique. In this
technique, activities are
chronologically related as information flows through the
process. Inputs are shown
entering the activity from the left, while outputs or results of
the activity are shown
exiting on the right. Figure 23 provides an example of an IDEF
Activity Model. The
mechanisms (who or what performs the activity) are shown as
arrows into the bottom of
the activity. These can be people, roles, systems, computer

programs, etc. The arrows
entering from the top of the activity boxes are controls.
Controls are the parameters that
direct the activity, such as guidance or regulations from
superior organizations, and
physical, time, or other resource limitations.
77
February 2001
Collect
Data
Process
Data
Disseminate
Data
Use
Data
External
Inputs
Decision
or Action
Mechanisms
(Who or What

performs the activity)
Mechanisms
(Who or What
performs the activity)
Constraints
on the Activity
Input(s)
Output(s)
Figure 23. Generic IDEF Activity Model
An Activity Model may also be represented in a tree format. As
shown in Figure 24, the
highest level activity is represented as the first node in the tree.
The lowest level
activities called leaves are activities that are not further
decomposed.
1.0 ACS
1.2.3 Liquidation
Processing
1.2.2 File
Entry Summary
1.4 Protest Processing
1.7 IPR Processing
1.5 Drawback Processing
1.9 Perform
Special Projects

1.2 Importation
1.2.4 Statement
Processing
1.2.1 Making
Entry
1.2.6 Reconciliation
Processing
1.8 MEWS
Processing
1.2.5 Collections
1.2.5.1 Manual
Payment Processing
1.2.5.2 Electronic
Payment Processing
1.1.1 Define User Profiles
1.1.1.1 Manage non-Customs
Participation 1.1.1.2 Manage Customs
Participation
1.1.3 Initiate a
Bond
1.1 Maintain System Information
1.1.2 Service ACS

Reference Information
1.2.1.1 Entry
Data Processing
1.2.1.3 Cargo
Release Processing
1.2.1.4 In-Bond
Processing
1.6 Surety
Processing1.3.1 Ocean Manifest
Processing
1.3 Manifest Processing
1.3.2 Air Manifest
Processing
1.3.3 Rail Manifest
Processing
1.3.4 Passenger
Manifest Processing
1.2.2.1 Entry
Summary Processing
1.2.2.2 Quota
Processing
1.2.2.3 Visa
Processing

1.2.2.4 AD/CVD
Processing
1.2.1.2 Border
Release Processing
1.10 Query
Figure 24. U.S. Customs, ACS, Activity Tree
The Activity Model can be annotated with explicit statements of
business rules, which
represent relationships among the ICOMs. For example, a
business rule can specify who
can do what under specified conditions, the combination of
inputs and controls needed,
and the resulting outputs.
78
February 2001
Activity Models can be represented in Unified Modeling
Language (UML), a standard
modeling language adopted by the Object Management Group to
support object-oriented
analysis, design, and development. Figure 25 depicts an
activity diagram represented
in UML.
Review and Validate Entry/Manifest

entry/ Review Entry
event Carrier files Manifest/ Review Manifest
Apply Selectivity Criteria
2nd Review and Validate
Entry/Manifest
Importer Declares Entry
entry or manifest rejected
accepted
action required
Inspector stamps
paper release
no problems[ entry and manifest OK ]
Notice to Importer and Carrier
Inspects
Goods
random or selectivity criteria met
Port Inspector
stamps release
Notice to Importer and Carrier
release[ goods OK ]
seize

reject
release[ on arrival ]
inspect[ on arrival ]
hold
Port InspectorInspector (Office)Import SpecialistEntry
Specialist
Figure 25. U.S. Customs, Trade Compliance, UML Activity
Model
D.5. Business Use Case Model
A Use Case Model can describe either business processes or
systems functions depending
on the focus of the modeling effort. A Business Use Case
Model describes the business
processes of an enterprise in terms of business use cases and
business actors
corresponding to business processes and organizational
participants (people,
organizations, etc.). The Business Use Case Model is described
in Use Case Diagrams
and Use Case Specifications. In addition to representing
business participation and
process, the Use Case Diagram can also depict
interrelationships among use cases such as
Includes and Extends Relationships. An Includes Relationship
represents inclusion or
containment of use cases. An Extends Relationship depicts
variations or alternative
sequences or paths beyond the normal course of action.

The following figures show Use Case Diagrams and
Specifications for Customs Trade
Compliance Processing. Figure 26 and Figure 27 depict UML
Use Case Diagrams and
Figure 28 shows a Use Case Specification.
79
February 2001
TC_UC_8: Declare Goods
TC_UC_2: Estimate/Pay Duties,
Fees, and Taxes
TC_UC_37: Establish A cc ount
with Customs
TC_UC_38: Query Customs
TC_UC_10: File Protest
TC_UC_11: Make Drawback
Request
TC_A1: Im port er of
Record
Decision to Import
Figure 26. U.S. Customs, Trade Compliance�External, UML

Use Case Diagram
TC_A13: Entry Clerk
TC_A14: Import
Specialist
TC_A16: OGA
Inspec tor
TC_UC_62: Inspec t
Goods/Shipment
TC_A15: Customs
Inpector
TC_UC_61: Capture and Review
Importation Information
<<extend>>
TC_A3: US Customs
TC_UC_67: Process Protest from
Importer
TC_UC_60: Process Entry
<<include>>
Goods Declared
TC_UC_65: Process Drawback
Request from Importer
TC_UC_66: Liquidate Ent ry

<<extend>>
TC_UC_63: Collect Duties, Fees,
and Taxes
<<extend>>
<<extend>>
<<ex tend>>
TC_UC_64: Classify/Value Goods
<<include>>
TC_A14: Import
Special ist
Figure 27. U.S. Customs, Trade Compliance�Internal, UML
Use Case Diagram
80
February 2001
TC_A_1.0: Declare Goods
1. Overview:
The Importer of Record provides information about an intended
importation to Customs. Customs will
process the information and respond with notices that
determines what the Importer of Record will do next.

The Importer of Record corrects or completes the transaction
until it is known that the items will or will not
be released.
2. Characteristic Information
Use Case Name: Declare Goods
Owner: Mary Lou Collins
Version Creation Date: December 13, 2000
Date Last Updated: December 19, 2000
Scope: Trade compliance
Level: Strategic
Primary Actor: Importer of Record
Secondary Actors: Customs
Focus Classes: Goods, Entry, Entry docs, License, Permit, Visa,
Release Notification
Trigger Event: The Importer of Record decides to import goods.
Goal: Receive notification that the goods have been released.
3. Pre-conditions:
1 Importer of Record has made transportation arrangements for
the items.
2 Importer of Record is in good standing with Customs, e.g.,
registered, licensed, bo
4. Main Scenario (Normative Path)
Step Action Description
1 Compile the information required for an entry (CF 3461 or
7501)
2 Collect documentation required by Customs to accompany the
entry.
5. Post-conditions:

1 Customs records entry information
2 Importer of Record�s payment due or 10-day clock for
payment tarts.
3 Goods available for carrier to move them into the U.S.
6. Scenario Exceptions / Variations
Step Variable Possible Variations
1 Information needed Query Customs for tariffs, currency rates,
AD/CVD case numbers,
4 Method of filing Broad range of manual to highly automated
alternatives
7. Related Information
Priority:
Performance Target:
Frequency: Once for each set of items that can be released at
one ti
determined by the Importer or Record
Super Use Case:
Sub Use Case(s):
Dependent Use Cases: Process Entry
8. Target Architecture Differences
Baseline Architecture Target Architecture
Declaration is for a single import transaction Declarations will
be associated with an account for pay
duties, fees, and taxes.
9. Open Issues
Issue ID Issue Description

Figure 28. U.S. Customs, Trade Compliance, Declare Goods,
UML Use Case Specification
81
February 2001
D.6. Class Model
A Class Model is similar to a logical data model. It describes
static information and
relationships between information. A Class Model also
describes informational
behaviors. Like many of the other models, it also can be used
to model various levels of
granularity. Depending on the intent of the model, a Class
Model can represent business
domain entities or systems implementation classes. A business
domain model represents
key business information (domain classes), their characteristics
(attributes), their
behaviors (methods or operations), and relationships (often
referred to as multiplicity,
describing how many classes typically participate in the
relationship), and cardinality
(describes required or optional participation in the relationship).
Each class, attribute,
and relationship appearing in the Class Diagram is specified or
defined in a class,
attribute, or relationship specification. In the case of a
relationship, the specification

describes how each class participates in the relationship.
Specifications further elaborate
and detail information that cannot be represented in the class
diagram. Figure 29
illustrates a Customs UML Business Class Diagram.
First Draft Complete - 12/14/00
TC_A1: Importer of
Record
(from Owner/Planner
Trade Use Cases)
T_BC_01:
ImporterOfRecord
role
licenseNbr
registrationNbr
isLicensed()
isRegistered()
T_BC_05:
Invoice
T_BC_06:
PurchaseOrder
T_BC_07:
BlanketPurchaseAgreement
T_BC_04:
CommercialContract

T_BC_08:
Consignee
TC_A3: US Customs
(from Owner/Planner
Trade Use Cases)
T_BC_02:
TradeAgent
name
ID
address
phone
1n 1n
is realized by
Figure 29. U.S. Customs, Trade Compliance, Commercial View,
UML Class Diagram
82
February 2001
D.7. State Model
State Models are useful in understanding and representing
complicated business or
system behaviors over time. A State Model can be used to

describe the behavior of a
specific business process, systems function, business class, or
system class. State
modeling is not a good technique to describe interactions among
business processes or
classes. Other techniques such as activity modeling or
interaction modeling should be
used for this purpose.
A UML State Model begins with a start state represented as a
solid dot. Middle states are
represented as ovals. The ending state is represented as a solid
dot within a circle. State
transitions are represented as arrows between states. Figure 30
presents a sample
Customs UML State Diagram.
Transporting
Goods
Awaiting
Clearance
In Transit
arrived
Awaiting Transport
[ Bonded, Hired by Importer ] P̂ icks up goods
Conveyanc e / Goods Seized
cleared
illegal activity / forfeiture determined

Figure 30. U.S. Customs, Trade Compliance, Carrier, UML
State Diagram
83
February 2001
D.8. Node Connectivity Diagrams
The Node Connectivity Diagram illustrates and describes the
business locations (nodes),
the needlines between them, and the characteristics of the
information exchanged.
The Node Connectivity Description can be produced at three
levels:
• Conceptual Node Connectivity Description�an essential work
product that
describes the prominent, high-level nodes
• Logical Node Connectivity Description�a supporting work
product that
describes the design that details all categories and classes of
nodes, but does
not describe the physical implementation or locations of nodes
• Physical Node Connectivity Description�a supporting work
product that
describes the physical implementation and locations of nodes.

Each needline is represented by an arrow (indicating the
direction of information flow),
which is annotated to describe the characteristics of the data or
information. Examples of
characteristics include its substantive content; media (voice,
imagery, text and message
format, etc.); volume requirements; security or classification
level; timeliness; and
requirements for information system interoperability.
Information exchange
characteristics are shown selectively, or in summarized form, on
this diagram and more
comprehensively in the Information Exchange Matrix.
It is important to note that the arrows on the diagram represent
needlines only. Each
arrow indicates that there is a need for some kind of information
transfer between the two
connected nodes. There is a one-to-many relationship between
needlines and information
exchanges; that is, a single needline arrow on the Node
Connectivity Description is a
rollup of multiple individual information exchanges. The
individual information
exchanges are shown on the Information Exchange Matrix.
The diagram should illustrate connectivity with external nodes,
i.e., nodes that are not
strictly within the scope of the architecture but that act as
important sources of
information needed by nodes within the architecture or
important destinations for
information produced by nodes within the architecture. These
external needlines should
be labeled to show the external source or destination, as well as
the information

exchanged.
Functional/Operational views are not required to name real
physical facilities as nodes.
Functional/Operational views can instead focus on �virtual�
nodes, which could be based
on business �roles.� These �virtual� nodes will not always
be capable of directly
integrating with real (physical) nodes from other architectures,
but they could provide
insight concerning which physical nodes might be able to
assume the roles portrayed.
A node can represent a role (e.g., a Bureau Chief Information
Officer); an organization
(e.g., U.S. Secret Service); a business facility (e.g., a specific
IRS Service Center); and so
on. The notion of �node� will also vary depending on the
level of detail addressed by the
architecture effort.
84
February 2001
Organizations may choose to represent some nodes in physical
terms (i.e., geographic
location) if these nodes are intended to remain �constant� in
the architecture analysis,
e.g., an effort to determine the most cost-effective
communications options between two
facilities. On the other hand, organizations may choose to

represent nodes much more
generically, or notionally, if the entire business practice is
being analyzed without
constraints imposed by the existing architecture.
To emphasize the focus of the analysis and to ensure
comparability and integration across
efforts, it is important that each organization carefully
document its use of the �node"
concept.
The activities associated with a given information exchange
should be noted in some way
to provide linkages between each node and the activities
performed, and to link the Node
Connectivity Diagram with the Activity Model. When more
than one Node Connectivity
Description is included in an EA description, the architecture
team should perform the
appropriate mapping of conceptual to logical and/or logical to
physical levels.
Figure 31, Figure 32, and Figure 33 present examples of Node
Connectivity Diagrams.
TAP
NCAP
AES
CAPPS
ATS
ACS

AAT
MATS ESFAS
NIPS
SEACATS
AIMS
APIS
TECS
Figure 31. U.S. Customs, ACS, Customs Systems, Node
Connectivity Diagram
85
February 2001
Internal ACS Interfaces
Doc Ret
Collect
Statement
In Bond
Quota

Reconcil
ACH
Protest
ELVIS
Sum Sel
Liquid
BOND
AD/CVD
Drawback
Entry
Ent Sum/
EIP
BRASS
ABI
AMS
Manifest
Cargo
Select
Legend:
Read N2 Chart

in Clockwise Direction
Surety
1a 2a 3a 4a 5a 6a 7a
8a 9a
10a 11a 12a 13a 14a 15a 16a 17a 18a 19a
20a
21a 22a
23a 24a 25a
26a
1b
2b
3b
4b
27b
28b
30b
29b
32b14b

15b
6b
7b
36b
8b
9b 25b
34b
35b
17b
23b
31b
33b
Rev 3
as of: 29 June/1500
Figure 32. U.S. Customs, ACS, N2 Chart
The N2 Chart simply represents an alternative method to portray
the connectivity between
operational nodes of an enterprise. The nodes of the enterprise
are shown as boxes on the
diagonal of the chart. Information flow between the nodes is
captured as numbered
intersections at the vertical and horizontal axes. The chart is

read in the clockwise
direction. For example, the information flow from the ABI
system to the ACH system is
annotated at the intersection labeled 2a (above the diagonal).
The other side of that
interface�the flow of information from the ACH system to the
ABI system�is
annotated at the intersection labeled 2b (below the diagonal).
The details or characteristics of each of these information flows
are presented in the
accompanying Information Exchange Matrix (IEM). Each
numbered interface in the
Node Connectivity N2 Chart becomes a row in the IEM. The
information exchange is
thoroughly defined and described in the IEM.
86
February 2001
The Node Connectivity Diagram depicted in Figure 33
illustrates high-level information
exchanges between major operational nodes of the U.S. Air
Force (USAF). At this level
of detail, only the minimum essential, mission connectivities
are illustrated. This graphic
is color coded to show the connectivity required for the various
USAF mission areas.
These mission areas and the color code are presented as a
legend in the lower right corner
of the chart.

To: AFSOC,
Deployed
AFSOC,
USSTRATCOM
& JSOTF
To: Deployed SOFs, JTFs,
JICs, & Theater Cmd Ctrs
To: Theater
Commands
& JTFs
Non-DOD
DOD
Air Force
AFSCNICBM
LCCs
Deployed
SOF Forces
Force Mgmt
Ops Centers

Logistics
Agencies
C
o
n
t
r
a
c
t
o
r
s
To: NMCC, FAA RCCs, Unified Cmds, JTFs, JICs,
WOC/SOCs,AOC, MAJCOM & Theater Cmd Ctrs
User Agencies
TALCE
C
o
m
m
e
r
c
i
a
l

A
i
r
C
a
r
r
i
e
r
s
NAVSPOC
Satellite SystemsAFSPOC
ADOC
To:
Transport Ops
Maint
Ctrs
NASA
USTRANSCOM
Cmd Ctr
To: Trans
Ctrl Ctrs
To: JTF

Cmd Ctr
RAMCC
FEMA
To: JTF Cmd
Ctr , & Theater
Cmd Ctrs
To: Multiple
Users
JICs
To
NASA
NCA
NAIC AFIWC
To: Theater
Cmd Ctrs &
Nat'l Agencies
USSOCOM
Cmd Ctr
SATELLITE

LAUNCH
RANGES
To:
Supply
Ctrs
ARSPOC
352 SOG
353 SOG
AFFOR
R/F
16th SOW
To: AOC
To: FAA RCCs
To SOC, AIA
OSC, AFSOC
Cmd Ctr, &
JTF Cmd Ctrs
To: Satellite Launch
Ranges, NU/CC,
AFSPOC & SPADOC

WOC/
SOC
To: AF MAJCOM Ops
Ctrs, AIA OSC &
USTRANSCOM Cmd Ctrs
ABCCC
AWACS
ASOS/
TACP
Medical
Facilities
To: NMCC
To:
CRC/
FACP
Service
Land &
Maritime
Forces
CRE/
FACP
TACC

FAA RCCs
To R0CCs/SOCCs
& AIA OSC
Allied Gvt's
USSTRATCOM
Cmd Ctr
NSA
Wx Sources
AF MAJCOM
Ops Ctrs
Supply
Ctrs
Trans
Control
Ctrs
To: TACC
ROCC/
SOCC
N/U
CC
Transport
Ops

Combat
A/C
JSTARS
NMCC
Mission Support
DOD & External
Agencies
Integrated Air Force C4I Systems
Combat Operations
Joint or Combined (operated by AF)
Intel Support
Mobility Operations
Space Operations
Special Operations
Rev 3R, 24 July 95
Sensors
MWC
To
NASA
SPADOC

SOC
Deployed
AFSOC
Cmd Ctr
SOF A/C
Units
(USAF/USA)
To: AOC
To: AOC
& AFSOC
Cmd Ctr
Mobility
A/C
IWSM
Ctrs
To:
FMO Ctrs
To: Trans Cont. Ctrs
AFSOC
Cmd Ctr
To: 352 &

353 SOG,
USSOCOM,
TACC
A
l
l
i
e
d
F
o
r
c
e
s
O
p
s
C
t
r
s To: Service Air
Defense & Service
Land & Maritime
Forces

To: AFIWC
NDOC
To: AF MAJCOMs
CIA
AIA OSC
DMA
DIA
CIO
National
Agencies
To: NSA & Other
Nat'l Agencies
To: CIO
To: CIA
To: DIA & DMA
To: AIA OSC
To: AFSOC Cmd CtrTheater
Cmd Ctrs
To: Multi

Users
Service
Air
Defense
Units
To:
TACC
To:
AOC
To: AFFOR R/F &
ROCC/SOCC
AOC
AFAC
JSOTF
JTF
Cmd Ctr
Figure 33. U.S. Air Force Node Connectivity Diagram
D.9. Information Exchange Matrix
The Information Exchange Matrix documents the Information
Exchange Requirements
(IERs) for an EA. IERs express the relationships across three

basic entities (activities,
business nodes and their elements, and information flow) and
focus on characteristics of
the information exchange, such as performance and security.
IERs identify who
exchanges what information with whom, why the information is
necessary, and in what
manner. IERs identify the elements of information exchanged
between nodes in support
of a particular activity. Relevant attributes of the exchange are
noted. The specific
attributes included are dependent on the objectives of the
specific architecture effort, but
may include the type of information media (e.g., data, voice,
and video), quality (e.g.,
frequency, timeliness, and security), and quantity (e.g., volume
and speed).
The IEM can be produced at three levels:
• Conceptual Information Exchange Matrix�an essential work
product
that describes the prominent, high-level information exchanges
between
prominent nodes
87
February 2001
• Logical Information Exchange Matrix�a supporting work
product that describes

the design that details all categories and classes of information
exchanges, but
does not describe the physical implementation of them
• Physical Information Exchange Matrix� a supporting work
product that
describes the physical characteristics of the implementation of
information
exchanges.
Particular capabilities such as security level of communications
may also be captured for
each exchange. This work product emphasizes the logical and
operational characteristics
of the information, namely, what information is needed by
whom, from whom, and when.
Table 6 illustrates an example of an entry in the Logical IEM of
the US Customs Service
EA. In the table, AIS is the automated information system at
the source and destination
that sends and receives the information exchange and LISI is
the Level of Information
System Interoperability. LISI is scaled from zero for a totally
manual interface to five for
a fully electronic connection.
Table 6. Example Logical Information Exchange Matrix
208a
Source Destination Information Associated
Activity
Media LISISource
AIS

Destination
AIS
Event
Trigger
Frequency of
Transmission
Interoperability
Issues
No.
Customs
DOT
(NHTSA)
Vehicle
Declaration
(Form HS-7)
Cargo
Release
Processing
ACS MVII electronic 3 Import of
Vehicle
Daily
Two data fields
missing from
transmission

208b Customs
DOT
(NHTSA)
Tariff Data
Data Updates
Maintain
Systems
Information
ACSMVII electronic 3
Data
Update
Required
As needed None
The IEM is not intended to be an exhaustive listing of all the
details contained in every
IER of every node associated with the architecture. That would
be too much detail for an
architecture description. Rather, this work product is intended
to capture the most
important aspects of selected information exchanges. Selecting
the important details of
the information exchanges depends on the purpose of the
architecture description.
The number of information exchanges associated with an
architecture may be quite large,
even though the matrix may not contain all details about all
IERs. To aid in
understanding the nature of the information exchanges,

developers and users of the
architecture may want to view the IER data sorted in multiple
ways, such as by task, by
node, or by attribute. Consequently, using a matrix to present
that information is limiting
and frequently not practical. A spreadsheet or relational
database is well suited to the
highly structured format of the IEM. In practice, hardcopy
versions of this product
should be limited to high-level summaries or highlighted
subsets of particular interest.
D.10. Organization Chart
The Organization Chart illustrates the relationships among
organizations or resources.
These relationships can include oversight, coordination
relationships (influences and
connectivity), and many others, depending on the purpose of the
architecture. It is
important to show these fundamental roles and management
relationships in an
architecture. For example, oversight relationships may differ
under various
circumstances, which will affect the activities that may be
performed differently or by
different organizations. Different coordination relationships
may mean that connectivity
requirements are changed. Figure 34 shows a generic example
of an Organization Chart.

88
February 2001
Top-Level
Organization
Hierarchical
Relationship
Second-Level
Organization
Second-Level
Organization
Third-Level
Organization
Third-Level
Organization
Coordination or
Other Specified
Relationship
Figure 34. Generic Organization Chart
D.11. Systems Interface Description and Connectivity Diagram
The System Interface Description (SID) depicts the assignments
of systems and their
interfaces to the nodes and needlines described in the Node
Connectivity Diagram. The
Node Connectivity Description for a given architecture shows
nodes (not always defined
in physical terms), while the SID depicts the systems

corresponding to the system nodes.
The SID identifies the interfaces between nodes, between
systems, and between the
components of a system, depending on the needs of a particular
architecture. A system
interface is a simplified or generalized representation of a
communications pathway or
network, usually depicted graphically as a straight line, with a
descriptive label. Pairs of
connected systems or system components often have multiple
interfaces between them.
The SID depicts all interfaces between systems and/or system
components that are of
interest to the architect.
The graphic descriptions and/or supporting text for the SID
should provide details
concerning the capabilities of each system. For example,
descriptions of information
systems should include details concerning the applications
present within the system, the
infrastructure services that support the applications, and the
means by which the system
processes, manipulates, stores, and exchanges data. Figure 35
depicts a sample SID
Connectivity Diagram.
89
February 2001

NODES
COMMUNICATIONS
NETWORK
TO OTHER
COMMUNICATIONS
SYSTEM
1
COMMUNICATIONS
SYSTEM
2
SYSTEM
2
NODE A
PROCESSING
SYSTEM
1
PROCESSING
C
O
M
M
U
N

IC
A
T
IO
N
S
N
E
T
W
O
R
K
F
R
O
M
O
T
H
E
R

N
O
D
E
S
Interface
CS1/PS2
In
ter
fac
e P
S1
/PS
2
Interface P
S
2/C
S
2
SYSTEM 1
Component 1
FROM
OTHER

SYSTEM
Component 2
Component 4 Component 3
Component 5
TO
OTHER
SYSTEM
Internodal Perspective
System-to-System
Intranodal Perspective Intrasystem Perspective
Internodal Perspective
Node Edge-to-Node Edge
NODE A NODE B
NODE C
SYSTEM
2
SYSTEM
1
EXTERNAL
CONNECTION
SYSTEM
1

CO
MM
S I
nte
rfa
ce
CO
M
M
S
In
ter
fa
ce
COMMS Interface
One-way SATCOM
Interface
SYSTEM
2
SYSTEM
3
SYSTEM
1

SYSTEM
4
NODE A
NODE B
NODE C
SYSTEM
2
SYSTEM
1
EXTERNAL
CONNECTION
SYSTEM
1
CO
MM
S I
nte
rfa
ce
CO
M
M
S
In

ter
fa
ce
COMMS Interface
One-way SATCOM
Interface
SYSTEM
2
SYSTEM
3
SYSTEM
1
SYSTEM
4
Figure 35. Generic System Interface Description Connectivity
Diagram
D.12. Standards Profile
An architecture Standards Profile is the set of rules that governs
system implementation
and operation. In most cases, especially in describing
architectures with less than a
department-wide scope, building a Standards Profile will
consist of identifying the
applicable portions of existing standards guidance
documentation, tailoring those portions
in accordance within the latitude allowed, and filling in any

gaps.
This architecture product references the technical standards that
apply to the architecture
and how they need to be, or have been, implemented. The
profile is time-phased to
facilitate a structured, disciplined process of system
development and evolution. Time
phasing also promotes the consideration of emerging
technologies and the likelihood of
current technologies and standards becoming obsolete.
A Standards Profile table (see Figure 36) documents the use of
the following items within
an enterprise:
• Industry standards or technologies
• Federal, department, or bureau standards or technologies
• Commercial products
• Federal, department, or bureau products.
90
February 2001
. . .
Service Area Service Standard
Operating System
Software
Engineering Services

User
Interface
Data Management
Data Interchange
Graphics
Client Server
Operations
Object Definition and
Management
Data Management
Window Management
Dialogue Support
Kernel
Shell and Utilities
Programming Languages
Data Interchange
Electronic Data Interchange
Graphics
FIPS Pub 151-1 (POSIX.1)
IEEE P1003.2
FIPS Pub 119 (ADA)

FIPS Pub 158 (X-Window
System)
DoD Human Computer Interface
Style Guide
FIPS Pub 158 (X-Window
System)
Project Standard
FIPS Pub 127-2 (SQL)
FIPS Pub 152 (SGML)
FIPS Pub 161 (EDI)
FIPS Pub 153 (PHIGS)
Figure 36. Standards Profile Table
D.13. Technical Reference Model
A Technical Reference Model (TRM) is a taxonomy that
provides:
• A consistent set of service areas, interface categories, and
relationships used to
address interoperability and open-system issues
• Conceptual entities that establish a common vocabulary to
better describe,
compare, and contrast systems and components
• A basis (an aid) for the identification, comparison, and
selection of existing and
emerging standards and their relationships.
The TRM organizes the Standards Profile and any standards or
technology forecast

documents. It can also organize technology infrastructure
documentation. Frequently,
some combination of the documents organized using the TRM
are presented in a single
document. Figure 37 depicts the service areas of the U.S.
Customs Service TRM.
Workstation
Productivity
Tools
Analysis
Tools
User Environment
App Dev
Env
Web App
Services
Document
Mgmt.
Application Services
Middleware Workflow
Integration Services
Data Services
Communications

Common Services
Email
Infrastructure
Mgmt.
Storage
Interchange
Voice
Power Mgmt.
Technologies
Service Area
Domain
Databases
Data
Warehouse
Data
Mgmt.
Operating
Systems
Network Security
Distributed
Computing
Application
Servers

Workstation
Productivity
Tools
Analysis
Tools
User Environment
App Dev
Env
Web App
Services
Document
Mgmt.
Application Services
Middleware Workflow
Integration Services
Data Services
Communications
Common Services
Email
Infrastructure
Mgmt.
Storage

Interchange
Voice
Power Mgmt.
Technologies
Service Area
Domain
Databases
Data
Warehouse
Data
Mgmt.
Operating
Systems
Network Security
Distributed
Computing
Application
Servers
Figure 37. U.S. Customs Technical Reference Model

91
February 2001
Technology domains and sub-domains are defined along with
key roles and points of contacts. A
Technical Architecture Strategy is established for each sub-
domain, with specifications and
selection criteria, outlining how the products and technologies
are going to be utilized. Figure 38
illustrates the domain and sub-domain definition being used in
the planning strategy and as
building blocks to aid project planning. Components are
constructed to represent a set of sub-
domains that are used together to build a functional component
of the architecture.
Common Services
Operating Systems
Desktop/Client OS
Mainframe OS
Network OS
App/Data Server OS
Service Area
Domain
Sub-Domains
Prod
uct S

trate
gies
App/Data Server OS Planning Strategy
Baseline Tactical Strategic
Sub-Domain Products
Components: Database Server
App/Data Server OS NT, Solaris...
Enterprise DBMS
CA-Datacom,
Oracle...
DBMS Gateways Oracle APPC...
Oracle Toolset...Database Mgmt. Tools
Message Oriented
Middleware
MQ Series...
Example Components
(Functional Collection of Sub-Domains)
Sub-Domain Planning Strategy
Example
Domain and Sub-domain

�Definitions
�Key Roles & POCs
�Specifications
�Criteria
�Benefits
Figure 38. Generic TRM Domain and Sub-domain Definitions
and Components
92
February 2001
93
March 15, 2002
Appendix E: Sample Architectural Principles
The following architecture principles derive from the many
architectural principles identified
throughout the available architecture literature. They are
presented as a starting point in the
architecture process. Each individual Agency, with unique
needs and requirements, should first
consider these, then modify, add to, or replace this list as
appropriate to its purposes.
1. Architectures must be appropriately scoped, planned, and
defined based on the intended use
of the architecture.

Rationale: The architecture development effort needs direction
and guidance to meet
expectations for specific uses of the architecture end products.
Detailed models may not be
needed for high-level decision making; similarly, simple,
descriptive architectures may not
provide enough information to support engineering choices.
Implications: The architecture must be generated with a
specific purpose and for a specific
audience to ensure it meets the expectations of its intended
stakeholders.
2. Architectures must be compliant with the law as expressed in
legislative mandates, executive
orders, Federal regulations, and other Federal guidelines.
Rationale: Federal Agencies must abide by laws, policies, and
regulations. However, this
does not preclude business process improvements that lead to
changes in policies and
regulations.
Implications: Federal Agencies should be aware of laws,
regulations, and external policies
regarding the development of architectures and the collection,
retention, management, and
security of data. Changes in the law (Clinger-Cohen Act) and
changes in policy (OMB
Circular A�130) may drive changes in architectural processes
or applications.
3. Architectures facilitate change.
Rationale: In the rapidly changing IT environment,

organizations need tools to manage and
control their business and technical growth and change. As the
technical development life
cycle shortens, with new technologies replacing older systems
every 18 months,
organizations require an overarching architecture to capture
their systems design and
operating environment.
Implications: The systems developer and the chief architect
should ensure the coordination
between technology investments and business practices.
Architectures must be used in the
evaluation function of the Capital Planning and Investment
Control process.
4. Enterprise architectures must reflect the Agency�s strategic
plan.
Rationale: The target architecture has maximum value when it
is most closely aligned with
the organization�s strategic plan and other corporate-level
direction, concepts, and planning.
Implications: The target architecture must be developed in
concert with strategic planners as
well as the operational staff. As the strategic plan changes, so
do the future environment and
the target architecture.
E: Sample Architectural Principles
94

February 2001
5. Architectures continuously change and require transition.
Rationale: The organization is constantly evolving towards its
future. As today�s
architecture transitions to the target architecture, the target
becomes the organization�s
baseline architecture at some point in the future. The baseline
architecture continuously
moves and transitions toward the target architecture.
Implications: The target architecture is a rolling set of
products, continually portraying the
out-year environment. As a component of strategic planning
and change management, the
target architecture captures the future environment including
data requirements and systems
transitions. The sequencing plan is the organization�s roadmap
to systems migration.
6. Target architectures should project no more than 3 to 5 years
into the future.
Rationale: Technology life cycles currently are in the
neighborhood of 18 months, and new
IT products appear on the market every 18 months. Federal
acquisition practices are aligning
to these rapid changes, which means that an organization�s
future information needs and
technical infrastructure requirements are changing just as
rapidly. Consequently, no one can
accurately predict what business practices will prevail 10 to 20
years into the future and what
type of IT capabilities and resources will be available.

Implications: Target architectures will need to be revised and
updated regularly. The
sequencing plan, illustrating intermediate points in time, may
become more valuable than the
target architectures.
7. Architectures provide standardized business processes and
common operating environments
(COEs).
Rationale: Commonality improves interoperability, cost
avoidance, and convergence. For
example, the integration of architectural Activity Models and
Operational Sequence
Diagrams (on the business side) and the Technical Reference
Model and technology forecasts
(on the technical side) helps establish a COE within the
organization�s logical and physical
infrastructures.
Implications: The systems architect and the chief architect must
ensure the coordination
between technology investments and business practices. A COE
grounded on standard
business practices yields improved data structures.
8. Architecture products are only as good as the data collected
from subject matter experts and
domain owners.
Rationale: The architect is not vested with the organizational
information. It is incumbent
upon the architect to collect the needed architectural
information from the members of the
organization who possess the knowledge of the business
processes and associated

information. These subject matter experts tend to be
operational staff, field representatives,
systems developers, software designers, etc. The domain
owners are the responsible
managers of specific business areas.
Implications: The development of the architecture can be a
slow process, dependent on the
architect�s access to subject matter experts and domain owners.
The validity of the
architecture can be limited by the accuracy of the collected
data. Development of the
95
February 2001
architecture is an iterative process of data gathering and
interviewing to obtain verification
and validity checks of the architectural products.
9. Architectures minimize the burden of data collection,
streamline data storage, and enhance
data access.
Rationale: Data, as a corporate asset, is key to an
organization�s vision, mission, goals, and
daily work routine. The more efficiently an Agency gathers
data, stores and retrieves that
data, and uses the data, the more productive the Agency.
Information is power.

Implications: Business processes are best improved by
streamlining the flow and use of data
and information. The development of architectural Node
Connectivity Descriptions,
Information Exchange Matrices, and other information models
will aid in the design of
improved data management systems.
10. Target architectures should be used to control the growth of
technical diversity.
Rationale: The rapid adoption of new and innovative IT
products can easily lead to
introducing a diverse set of IT products that may not always be
fully compatible within the
existing enterprise infrastructure. This necessitates the
selection and implementation of
proven market technologies.
Implications: The target architecture must be used in
conjunction with the organization�s
investment review process and technology insertion plans.
Relying on the architecture as an
integral component of IT decision making helps control the
introduction of incompatible
products.
96
February 2001

97
March 15, 2002
Appendix F: Bibliography
Beckner, S. G., & S. T. Norman, Air Force Architecture
Development Guide. MITRE Technical Report
98B0000074. Colorado Springs, CO, 1998.
Boar, B. H. Constructing Blueprints for Enterprise IT
Architectures. Wiley Computer Press. New York,
NY, 1999.
Cook, M. A., Building Enterprise Information Architectures:
Reengineering Information Systems.
Prentice Hall. Upper Saddle River, NJ, 1996.
Department of Defense, C4ISR Architecture Working Group,
DoD C4ISR Architecture Framework,
Version 2.0, 18 December 1997.
Department of the Treasury, Chief Information Officer Council,
Treasury Enterprise Architecture
Framework (TEAF), Version 1.0, 3 July 2000.
Department of the Treasury, Treasury Information Systems
Architecture Framework (TISAF), Office of
the Deputy Assistant Secretary for Information Systems and
Chief Information Officer, 3 January 1997.
Executive Guide: Measuring Performance and Demonstrating
Results of IT Investments. GAO/AIMD-
98-89. March 1998.
Federal Chief Information Officer (CIO) Council, Federal

Architecture Working Group, Architecture
Alignment and Assessment Guide, October 2000.
Federal Chief Information Officer (CIO) Council, Federal
Enterprise Architecture Framework (FEAF).
Version 1.1, September 1999.
Federal Chief Information Officer (CIO) Council, Capital
Planning and IT Management Committee,
Smart Practices in Capital Planning, October 2000.
Clinger-Cohen Act of 1996 (formerly, Information Technology
Management Reform Act [ITMRA]),
Public Law 104-106. 10 Feb 1996.
Freedom of Information Act (FOIA). 5 U.S.C. §552, as
amended by Public Law 104-231, 110 Stat. 3048
(1996).
Government Paperwork Elimination Act (GPEA) of 1998.
Public Law 105-277, Title XVII. 21 Oct
1998.
Government Paperwork Reduction Act (PRA) of 1980, amended
1996. Public Law 104-13, 44 USC
Chapter 35.
Government Performance Results Act (GPRA) of 1993. Public
Law 103-58. 16 June 1993.
Information Technology Investment Evaluation Guide:
Assessing Risks and Returns. A Guide for
Evaluating Federal Agencies� IT Investment Decision-making.
GAO/AIMD-10.1.13. February 1997.

F: Bibliography
98
February 2001
Information Technology Investment Management: A Framework
for Assessing and Improving Maturity.
GAO/AIMD-10.1.23. Exposure Draft.
OMB Circular A�11. Preparation and Submission of Budget
Estimates. 19 July 2000.
OMB Circular A�130. Management of Federal Information
Resources. 30 November 2000.
Rechtin, E., & M. W. Maier, The Art of Systems Architecting.
CRC Press. New York, NY, 1997.
Sowa, J. F., & J. A. Zachman, Extending and Formalizing the
Framework for Information Systems
Architecture. IBM Publication G321-5488. IBM Journal, Vol.
31(3). 1992.
Spewak, S. H., Enterprise Architecture Planning. Wiley and
Sons, New York, NY, 1992.
Systems Development Life Cycle, CIS Handbook 5500�07,
U.S. Customs Service, October 1998.
Thomas, R, II, R. A. Beamer, & P. K. Sowell, Civilian
Application of the DoD C4ISR Architecture
Framework: A Treasury Department Case Study. Proceedings
of 5th International Command and Control
Research and Technology Symposium, Canberra, Australia.

October 2000.
U.S. Customs Service, Enterprise Architecture Blueprint,
August 1999.
Zachman, J. A. A Framework for Information Systems
Architecture. IBM Systems Journal.
Vol. 26(3). 1987.
Zachman, J. A. The Framework for Enterprise Architecture:
Background, Description and Utility. 1996.
Internet/WEB Links
Federal Chief Information Officer Council
www.cio.gov
Federal Architecture Working Group
www.cio.gov/docs/interopeability.html
ArchitecturePlus
www.itpolicy.gsa.gov/mke/archplus/archhome.htm
Clinger-Cohen Act
www.itpolicy.gsa.gov/mks/regs-leg/s1124_en.htm
The Clinton Administration's Policy on Critical Infrastructure
Protection: Presidential Decision Directive
63, May 1998.
www.ciao.gov/CIAO_Document_Library/paper598.html
Department of Defense Technical Reference Model, Version
1.0, November 5, 1999.
www-trm.itsi.disa.mil
Department of the Treasury CIO

www.treas.gov/cio/
http://www.cio.gov/
http://www.itpolicy.gsa.gov/mke/archplus/group.htm
http://www.itpolicy.gsa.gov/mke/archplus/archhome.htm
http://www.itpolicy.gsa.gov/mks/regs-leg/s1124_en.htm
http://www.ciao.gov/CIAO_Document_Library/paper598.html
http://www-trm.itsi.disa.mil/
http://www.treas.gov/cio/
F: Bibliography
99
February 2001
Digital Consulting, Inc (DCI)
www.dci.com
Enterprise-wide Information Technology Architectures
(EWITA)
www.ewita.com
Federal Enterprise Architecture Framework, Version 1,
September 1999.
www.itpolicy.gsa.gov/mke/archplus/fedarch1.pdf
General Accounting Office, Assessing Risks and Returns: A
Guide for Evaluating Federal Agencies' IT
Investment Decision-making, Version 1, GAO/AIMD-10.1.13,
February 1997.
www.gao.gov/policy/itguide/
General Accounting Office, Information Technology Investment
Management: A Framework for

Assessing and Improving Process Maturity, Exposure Draft,
Version 1, GAO/AIMD-10.1.23, May 2000.
www.gao.gov/special.pubs/10_1_23.pdf
General Accounting Office, Measuring Performance and
Demonstrating Results of Information
Technology Investments, AIMD-98-89, March 1998.
www.gao.gov/special.pubs/ai98089.pdf
General Services Administration, Office of Information
Technology
www.itpolicy.gsa.gov
IEEE 1471, Recommended Practice for Architectural
Description, DRAFT
Information Assurance Technical Framework Forum
www.iatf.net
Information Technology Investment Portfolio System (I-TIPS)
www.itips.gov
International Enterprise Architects Consortium and Architecture
Center
www.ieac.org
MetaGroup, Inc. Stamford, CT
www.metagroup.com
Object Management Group
www.omg.org
OMB Circular A�130, Management of Federal Information
Resources, Revised, November 30, 2000.
www.whitehouse.gov/OMB/circulars/a130/a130.html
OMB Memorandum M-97-16, Information Technology

Architectures, June 18, 1997.
www.whitehouse.gov/OMB/memoranda/m97-16.html
OMB Memorandum M-00-07, Incorporating and Funding
Security in Information Systems Investments,
28 February 2000.
www.whitehouse.gov/OMB/memoranda/m00-07.html
http://www.dci.com/
http://www.ewita.com/
http://www.itpolicy.gsa.gov/mke/archplus/fedarch1.pdf
http://www.gao.gov/policy/itguide/
http://www.gao.gov/special.pubs/10_1_23.pdf
http://www.gao.gov/special.pubs/ai98089.pdf
http://www.itpolicy.gsa.gov/
http://www.iatf.net/
http://www.itips.gov/
http://www.ieac.org/
http://www.megagroup.com/
http://www.omg.org/
http://www.whitehouse.gov/OMB/circulars/a130/a130.html
http://www.whitehouse.gov/OMB/memoranda/m97-16.html
http://www.whitehouse.gov/OMB/memoranda/m00-07.html
F: Bibliography
100
February 2001
OMB, Proposed revision of OMB Circular No. A�130, in
Federal Register, Vol. 65, No. 72, April 13,
2000, pages 19933-19939
www.whitehouse.gov/omb/fedreg/rev-a130.pdf

Software Engineering Institute (SEI) Architecture Technology
Page
www.sei.cmu.edu
Steven Spewak Enterprise Architecture Planning Home Page
www.eap.com
Stanford University, Enterprise Architecture Home Page
www.standford.edu/group/APS/arch/index.html
The Open Group Architecture Framework (TOGAF) Technical
Reference Model, version 5, 1999.
www.opengroup.org/togaf
U. S. Customs Service, Enterprise Architecture Blueprint,
October 1999.
www.itpolicy.gsa.gov/mke/archplus/eab.pdf
U.S. Customs Service, Technical Reference Model Introductory
Guide, August 1999.
www.itpolicy.gsa.gov/mke/archplus/trm.pdf
UML � Unified Modeling Language
www.omg.org/uml
Zachman Institute for Framework Advancement
www.zifa.com
http://www.whitehouse.gov/omb/fedreg/rev-a130.pdf
http://www.sei.cmu.edu/
http://www.sei.cmu.edu/
http://www.standford.edu/group/APS/arch/index.html
http://www.opengroup.org/togaf
http://www.itpolicy.gsa.gov/mke/archplus/eab.pdf
http://www.itpolicy.gsa.gov/mke/archplus/trm.pdf
http://www.omg.org/uml

http://www.zifa.com/
101
February 2001
Appendix G: The Zachman Framework
In September 1987, John Zachman published an important
article in the IBM Systems Journal
identifying what he called �A Framework for Information
Systems Architecture,� sometimes
simply referred to as �The Zachman Framework.� This article
has grown to become a de facto
standard for enterprise architecture development. In fact, the
Zachman Framework provides
much of the foundation for the FEAF and the frameworks of
several Federal Departments and
Agencies.
Two key ideas are illustrated in the Zachman Framework:
1. There is a set of architectural representations produced over
the process of building a
complex engineering product representing the different
perspectives of the different
participants.
2. The same product can be described, for different purposes, in
different ways, resulting in
different types of descriptions.
The Zachman Framework provides the necessary detailed and
robust views of the enterprise
information architecture. It outlines six increasingly detailed
views or levels of abstraction for six

architecture descriptions. The levels of abstractions are:
1. The Planner or Ballpark View
2. The Owner�s or Enterprise Model View
3. The Designer�s or Systems Model View
4. The Builder�s or Technology Model View
5. The Subcontractor�s or Detailed Representation View
6. The Functioning Enterprise or Actual System View.
And the six architecture descriptions�and the interrogatives
that they answer�are:
1. The Data Description�What
2. The Function Description�How
3. The Network Description�Where
4. The People Description�Who
5. The Time Description�When
6. The Motivation Description�Why.
In Zachman�s opinion, the single factor that makes his
framework unique is that each element on
either axis of the matrix is explicitly distinguishable from all
other elements on that axis. The
representations in each cell of the matrix are not merely
successive levels of increasing detail, but
actually are different representations�different in context,

meaning, motivation, and use.
Because each of the elements on either axis is explicitly
different from the others, it is possible to
define precisely what belongs in each cell.
Figure 39 illustrates the Zachman Framework in a 6x6 matrix
format. The six views or levels of
abstraction are the rows of the matrix, while the architectural
descriptions�the answers to the
G: The Zachman Framework
102
February 2001
enterprise interrogatives�are the columns. Each of the 36 cells
of the matrix represents a
descriptive model or architecture product that form the building
blocks of the EA.
e.g.
Builde
SCOP
(CONTEXTUA
MODE
(CONCEPTUA
ENTERPRIS
Designe

SYSTE
MODE
(LOGICAL
TECHNOLOG
MODE
(PHYSICAL
DETAILE
REPRESEN
(OUT-
Sub-
Contracto
FUNCTIONIN
ENTERPRIS
DATA FUNCTIO NETWOR
e.g. Data
Ent =
Reln =
e.g. Physical Data
Ent =
Reln =
e.g. Logical Data
Ent = Data

Reln = Data
e.g. Semantic
Ent = Business
Reln = Business
List of Things
to the
ENTITY = Class
Business
List of Processes
Business
Function = Class
Business
e.g. Application
I/O = User
Proc .= Application
e.g. System
I/O = Data
Proc.= Computer
e.g.
I/O = Control
Proc.= Language
e.g.

e.g. Business Process
Proc. = Business
I/O = Business
List of Locations in
the Business
Node = Major
Locatio
e.g. Business
Node = Business
Link = Business
e.g. Distributed
Node = I/S
(Processor, Storage,
Link = Line
e.g. Technology
Node =
Softwar
Link = Line
e.g. Network
Node =
Link =
e.g.

Architectur
Planne
Owne
Builde
ENTERPRIS
MODE
(CONCEPTUAL
Designe
SYSTE
MODE
(LOGICAL)
TECHNOLOG
MODE
(PHYSICAL
DETAILE
REPRESEN
TATIONS
(OUT-OF
CONTEXT
Sub-
Contracto

FUNCTIONIN
MOTIVATIOTIMEPEOPL
e.g. Rule
End = Sub-
Means =
e.g. Rule
End =
Means =
e.g., Business Rule
End = Structural
Means =Action
End = Business
Means = Business
List of Business
Ends/Means=Major Bus.
Critical Success
List of Events
Time = Major Business
e.g. Processing

Cycle = Processing
Time = System Event
e.g. Control
Cycle = Component
Time =
e.g. Timing
Cycle = Machine
Time =
e.g.
e.g. Master
Time = Business
Cycle = Business
List of
People = Major
e.g. W ork Flow
People = Organization
W ork = W ork
e.g. Human
People =
W ork =
e.g. Presentation

People =
W ork = Screen
e.g. Security
People =
W ork =
e.g.
Planne
Owne
to theImportant to the
What How Where Who When Why
John A. Zachman, Zachman International (810) 231-0531
SCOP
(CONTEXTUA
Architectur
e.g. ENTERPRIS
e.g. Business
Figure 39. The Zachman Framework Matrix
For further readings and more detailed information on the
Zachman Framework, please refer to
any of John Zachman�s publications, the Zachman Institute for
Framework Advancement (ZIFA)
web site (http://www.zifa.com), and a number of publications

by other authors such as Melissa A.
Cook �s text, Building Enterprise Information Architectures:
Reengineering Information Systems,
Prentice Hall, Upper Saddle River, NJ, 1996. See Appendix F
for a listing of related resources.

A Practical GuidetoFederal Enterprise ArchitectureCh.docx

More Related Content

Similar to A Practical GuidetoFederal Enterprise ArchitectureCh.docx (20)

More from evonnehoggarth79783 (20)

Recently uploaded (20)

A Practical GuidetoFederal Enterprise ArchitectureCh.docx