EA Memo

This assignment gives you the opportunity to demonstrate your ability to research, evaluate, and explain enterprise systems, and to communicate effectively at the executive level. This assignment specifically addresses the following course outcomes:

· analyze and examine how enterprise architecture and enterprise systems influence, support, and enable an organization’s ability to contribute to strategic decision making and to respond and adapt to the business environment

· analyze enterprise system solutions to make recommendations based on benefits, limitations, and best fit within the enterprise environment

· analyze and explain the elements of a successful plan for implementing enterprise solutions, addressing structure, processes, culture, and other considerations

Assignment

Your instructor has assigned each group one of several types of enterprise systems (ERP, SCM, CRM, etc.) to research and prepare a paper and an executive-level informational presentation. In Group Project 1, your team prepared a 2-3 page paper summarizing the case studies, evaluating the success of the implementations, and identifying lessons learned. For this assignment, you are to work independently and write a 1-2 page memo (not including references page) to the CIO that identifies at least seven success criteria for implementation of enterprise systems, for the category of enterprise systems assigned to your group (ERP, SCM, CRM, etc.).

Each of these success criteria should be briefly explained and then related to how they would be applied during an enterprise system implementation within an organization. Some areas to consider include the structure of the organization and its processes and culture; other aspects of a proposed implementation relate to the phases of the system development life cycle (needs analysis, design, development, implementation, maintenance). The case studies your group is using may be a good source of ideas as well. The criteria you identify must be applicable to enterprise systems (in the category assigned to your group) and should come from your research.

You are to use a Microsoft Word memo template. The use of at least three external scholarly resources (in addition to your case studies and other class materials) is required. You should use scholarly journals (rather than Wikipedia and authorless website postings). Remember to correctly cite and reference all sources. Since you are writing a memo, you should use in-text citations and list the references on a separate page at the end.

An example that is not related to enterprise systems but can give you an idea of what is needed follows. One criterion for successful implementation of an individual customer’s Internet connection might be that the customer’s system is fully functioning when the technician leaves the customer’s home. The explanation of how that would be applied is that the technician has completed the installation, tried it to be sure it is working, explained to the customer how to connect and use the system, and answered any questions that the customer had. As a result the reader now knows what one of the success criteria is and how it would be applied.

Note: The filename of your paper should include your last name. An example would be: Smith_Memo .

Grading Rubric

Your work will be graded according to the rubric below.

Attribute

Full Points

Partial Points

No Points

Possible Points

Points Earned

Introduction

There is an effective introduction to the memo, stating the purpose, using sophisticated writing.

The introduction somewhat effectively or adequately sets the stage for the memo.

No introduction is provided.

5

Criteria

At least 7 criteria for successful implementation of enterprise systems (in the category assigned) are included. Each of the criteria is clearly explained and each is applicable to enterprise system implementation success, demonstrating a sophisticated understanding of course concepts, analysis, critical thinking and synthesis.

Fewer than 7 criteria for successful implementation of enterprise systems (in the category assigned) may be included. Some of the criteria may be somewhat clearly explained, and/or may be somewhat applicable to enterprise system implementation success, and may demonstrate an adequate understanding of course concepts, analysis, critical thinking and/or synthesis.

No success criteria applicable to enterprise system implementation are included.

21
(3 points each)

Application of Criteria

The application in a successful implementation of enterprise systems is fully described for at least 7 criteria. Each of the criteria is appropriately related to implementation of enterprise systems (in the category assigned) and demonstrates sophisticated incorporation of course concepts and research, analysis, critical thinking and synthesis.

The application in a successful implementation of enterprise systems may be only partially described for the 7 criteria and/or fewer than 7 criteria may be discussed. The criteria may be somewhat appropriately related to implementation of enterprise systems (in the category assigned) and/or may somewhat demonstrate effective incorporation of course concepts and research, analysis, critical thinking and synthesis.

The explanations for application of the criteria do not relate to successful implementation of enterprise systems, or are missing.

49
(7 points each)

External Research

More than three scholarly sources other than the class resources are incorporated and used effectively, contextualized, appropriately researched and supported, and synthesized with original arguments. Sources used are credible, relevant, and timely.

Three or fewer sources other than the class resources may be used; may or may not be properly incorporated or used to support arguments; may rely too heavily on the reporting of external sources, and/or are not effective or appropriate; and/or are not credible, relevant, or timely.

No external research incorporated.

15

Memo Format

Memo reflects effective organization and sophisticated writing; correct structure, grammar, and spelling; presented in a professional format using Word memo template; references are appropriately incorporated and cited using APA style.

Memo is not well organized, and/or may be somewhat clear and concise; and/or contains grammatical and/or spelling errors; and/or is not in Word memo template; and/or does not follow APA style for references and citations.

Memo is extremely poorly written and does not convey the information.

10

TOTAL Points

100

100 points = 10% of final course grade

Points Recorded(total points x .10)

Requirements for Each Writing Assignment

1. Writing Quality

· Correctly use grammar, verb tenses, pronouns, spelling, and punctuation. Exhibit good writing competency.

· Remember: spell-check, then proofread. Better yet, have a friend or colleague read the assignment before submitting it. Read the assignment out loud.

· Remember: “There” is not “their,” “your” is not “you’re,” “its” is not “it’s,” “too” is not “to” or “two,” “site” is not “cite,” and “who,” not “that,” should be used after an individual. For example, it should read “the person who made the speech,” not “the person that made the speech.”

· In a professional paper, one does not use contractions (doesn’t, don’t, etc.) and one does not use the personal I, we, you, or your. Use the impersonal voice as in the previous sentence or a term such as “the company.” It is more businesslike than saying, “Also in a professional paper, you don’t use contractions.”

2. References

· Use APA format for references and citations. Use a separate References page.

· Some assignments require external sources. Be sure to use scholarly references. You should use scholarly journals (rather than Wikipedia and authorless website postings); if you need assistance with determining what a scholarly journal is, the UMUC library is a good source of information, accessed via the following link: 

http://www.umuc.edu/library/libhow/articles.cfm

.

3. Word Processing

· Deliverables can be created in either Office 2003 or 2007, but Microsoft Word documents must be saved as (2003 format).

· Use Page Setup in the printer options to configure the document.

· Use 1-inch margins along top, bottom, left, and right sides.

· Use Times New Roman, 12 point font.

· Use double spacing.

· In all writing assignments, use appropriate headings and subheadings. Headings and subheadings should be placed at the left margin.

· Number each page in the bottom right corner. (The cover page should never be numbered.)

4. Cover Page

· Use a cover page. In the center of the page, in this order, double-spaced, put:

o Your name or the names of all group members that produced the document

o IFSM 311: Enterprise Architecture and Systems

o Title of the assignment

· Nothing else needs to be added to the cover page. Remember, the cover page is not a separate document; it is the first (unnumbered) page of your assignment and does not count toward the number of assignment page requirements.

A Practical Guide
to

Federal Enterprise Architecture

Chief Information Officer

Council

Version 1.0

February 2001

iii
February 200

1

Preface

An enterprise architecture (EA) establishes the Agency-wide roadmap to achieve an Agency�s missio

n

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 Officer

s

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 syste

ms

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

i

v
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 maturi

ty

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 i

ts

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 rob.c.thomas@customs.treas.gov, 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:rob.c.thomas@customs.treas.gov

A Practical Guide to Federal Enterprise Architecture Preface
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

A Practical Guide to Federal Enterprise Architecture Preface

vi
February 2001

vii
February 2001

Table of Cont

ents

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

i

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

A Practical Guide to Federal Enterprise Architecture 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

A Practical Guide to Federal Enterprise Architecture 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

Architecturethe structure of components, their
interrelationships, and the principles and
guidelines governing their design and evolution
over time.

Enterprisean organization (or cross-
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).

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.

Target architecturethe set of products that
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.

Sequencing Plana document that defines the
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.

Enterprise Architecture Productsthe
graphics, models, and/or narrative that depicts
the enterprise environment and design.

Enterprise Architecturea strategic
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.

A Practical Guide to Federal Enterprise Architecture 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.

A Practical Guide to Federal Enterprise Architecture Definitions, Drivers, and Principles

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

A Practical Guide to Federal Enterprise Architecture Definitions, Drivers, and 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

A Practical Guide to Federal Enterprise Architecture Definitions, Drivers, and Principles

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

A Practical Guide to Federal Enterprise Architecture Definitions, Drivers, and Principles

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

A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program

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

A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program

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

A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program

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

A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program

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.

A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program

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.

A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program

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)

A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program

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.

A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program

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

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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.

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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.

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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 3×5 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

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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.

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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.

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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.

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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.

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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.

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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
Enterprise Architecture

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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.

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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.

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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.

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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.

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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,

A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach

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 Enterprise Architecture

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

Architecture Process

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

A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture

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
Architecture Process

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.

A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture

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.

A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture

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.

A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture

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.

A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture

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

A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture

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.

A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture

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

Systems Architecture
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

A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture

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.

A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture

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

Systems Architecture
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.

A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture

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

A Practical Guide to Federal Enterprise Architecture Maintain the Enterprise Architecture

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?

A Practical Guide to Federal Enterprise Architecture Maintain the Enterprise Architecture

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.

A Practical Guide to Federal Enterprise Architecture Maintain the Enterprise Architecture

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.

A Practical Guide to Federal Enterprise Architecture Maintain the Enterprise Architecture

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.

A Practical Guide to Federal Enterprise Architecture Maintain the Enterprise Architecture

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.

Enterprise Architecture
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.

Enterprise Architecture
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.

Enterprise Architecture
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.

A Practical Guide to Federal Enterprise Architecture Appendix B: Glossary

68
February 2001

Term Source Definition
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).

Enterprise Architecture
(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.

Enterprise Architecture
Policy

A statement governing the development,
implementation, and maintenance of the enterprise
architecture.

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

A Practical Guide to Federal Enterprise Architecture Appendix B: Glossary

69
February 2001

Term Source Definition
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

Enterprise Architecture
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 6×6 matrix of architecture views and
perspectives with products.

A Practical Guide to Federal Enterprise Architecture Appendix 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

A Practical Guide to Federal Enterprise Architecture Appendix 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.

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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.

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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.

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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.

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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

<>

TC_A3: US Customs

TC_UC_67: Process Protest from
Importer

TC_UC_60: Process Entry

<>
Goods Declared

TC_UC_65: Process Drawback
Request from Importer

TC_UC_66: Liquidate Ent ry

<>

TC_UC_63: Collect Duties, Fees,
and Taxes

<>
<>

<>

TC_UC_64: Classify/Value Goods

<>
TC_A14: Import

Special ist

Figure 27. U.S. Customs, Trade Compliance�Internal, UML Use Case Diagram

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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.

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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

2

7b

2

8b

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.

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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.

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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.

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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

r

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

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture 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

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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

A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products

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.

A Practical Guide to Federal Enterprise Architecture Appendix 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

A Practical Guide to Federal Enterprise Architecture Appendix E: Sample Architectural Principles

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.

A Practical Guide to Federal Enterprise Architecture Appendix E: Sample Architectural Principles

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.

A Practical Guide to Federal Enterprise Architecture Appendix 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/

A Practical Guide to Federal Enterprise Architecture Appendix 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

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

General Accounting Office, Measuring Performance and Demonstrating Results of Information
Technology Investments, AIMD-98-89, March 1998.
www.gao.gov/special.pubs/ai98089

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

http://www.gao.gov/policy/itguide/

http://www.gao.gov/special.pubs/10_1_23

http://www.gao.gov/special.pubs/ai98089

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

A Practical Guide to Federal Enterprise Architecture Appendix 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

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

U.S. Customs Service, Technical Reference Model Introductory Guide, August 1999.
www.itpolicy.gsa.gov/mke/archplus/trm

UML � Unified Modeling Language
www.omg.org/uml

Zachman Institute for Framework Advancement
www.zifa.com

http://www.whitehouse.gov/omb/fedreg/rev-a130

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

http://www.itpolicy.gsa.gov/mke/archplus/trm

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 6×6 matrix format. The six views or levels of
abstraction are the rows of the matrix, while the architectural descriptions�the answers to the

A Practical Guide to Federal Enterprise Architecture Appendix 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.

www.ids-scheer.com

Why two thirds of Enterprise Architecture
projects fail

An explanation for the limited success of
architecture projects

ARIS Expert Paper

����
�������

��
��
���
�

This is the conclusion of a study for the Rotterdam University carried out by
Jonathan Broer in the summer of 2008, ordered by BPM and EA software vendor
IDS Scheer. Broer questioned 161 respondents from 89 organizations represent-
ing a range of industries about their vision and implementation of the enterprise
architecture concept.

A clear majority of respondents – 92 percent – believes that EA should be deter-
mined by the vision, strategy and objectives of the company. Yet only 40 percent
of them actually included objectives and policies in their EA program. The align-
ment of Business and IT is seen as the most important argument for organiza-
tions to start using EA. At the same time connecting IT architecture and business
elements, and arriving at important decisions about structure and layout on that
basis, is found to be one of the biggest problems confronting businesses. Among
the reasons for the failure of EA programs to fulfill expectations were a lack of
EA awareness and the fact that it took longer than expected to set up an archi-
tecture.

Why two thirds of Enterprise Architecture projects fail

An explanation for the limited success of architecture projects

Large and medium-sized organizations regard the alignment of business and
IT as the most important motive for working on an enterprise architecture
(EA). Other important reasons for putting EA on the agenda are support for
change processes and strengthening the flexibility of the company. In spite
of the huge interest in EA it turns out that 66 percent of programs did not ful-
fill expectations.

2

ARIS Expert Paper

This ARIS Expert Paper comprises:
� an overview of typical Enterprise Architecture project roles and

drivers

� main targets of Enterprise Architecture projects and initiatives
� critical success factors derived out of the survey

About the authors:

Sven Roeleven
is Global Solutions Manager at IDS
Scheer. After graduating in Public

Administration from Erasmus
University Rotterdam (the

Netherlands), he went on to spe-
cialize in business process man-

agement within ERP environ-
ments. Since joining IDS Scheer in

2002, Sven has gained extensive
hands-on experience covering all
ARIS platform products through-
out the course of dozens of proj-

ects within medium-sized and
larger organizations across a vari-

ety of industries.

Jonathan Broer
completed his studies in Business

Informatics at the Rotterdam
University in 2008 (with a minor in
BPM). For his practical training in

the final year of his degree, he
carried out a study of enterprise
architecture at IDS Scheer. Since

September 2008 he has been
employed by Capgemini as a con-

sultant in the field of Architecture,
Governance & Infrastructure.

Contact:
arisproductmarketing@ids-scheer.com

Fig. 1: Industries that participated in the study

Drivers for EA

Organizations start using EA for different reasons.
Business and IT streamlining, supporting change
processes and achieving greater flexibility are
the three most important reasons for starting an
EA project. This fits the definition of EA used by
research agency Gartner:

“Enterprise architecture is the process of trans-
lating business vision and strategy into effective
enterprise change [..]”.

The fact that EA is determined by vision, strategy
and objectives is also affirmed by 92 percent of
the organizations taking part in the study. In other
words, organizations have a clear understanding
of the reasons for starting an EA project, and they
know that these drivers are partly determined by
the business strategy. In their vision EA is there-
fore a holistic, business-driven discipline.

Older organizations have higher integration of architectures

Apart from their well-developed vision, organizations have also come quite far in the implementation of enterprise archi-
tectures. 74 percent already use a framework for EA, and the majority of those without a framework are in the process of
choosing one. The most commonly used standard frameworks are TOGAF (The Open Group Architecture Framework) and
ArchiMate (adopted by TOGAF in 2008 as standard modeling language).

The older organizations (more than 50 years old) are often further ahead in the integration of domain architectures. In
many cases they have been involved in mergers or takeovers which necessitate a good integration. The presence of lega-
cy systems also plays an important role. It is important after all to know what the consequences of phasing out a system
will be for the entire operational management – the consequences for data exchanged with the system for example, or
for the infrastructure on which it runs, or for the processes supported by the system which is about to be phased out.

Large organizations have more EA roles

There is also a connection between the size of
an organization and the presence of EA relat-
ed roles. The larger the organization, the larg-
er the presence of these roles in the EA work
field.

For small organizations the information archi-
tect is used the most. For large organizations it
is the business architect. Respondent com-
ments show that small organizations approach
EA much more from an IT point of view. Larger
organizations which appear to be more mature
in their enterprise architecture have a more
business-oriented approach, and they cite the
business architect as the most common role.

3

ARIS Expert Paper

Fig. 2: Drivers for EA projects

Fig. 3: Presence of EA related roles

Who is responsible for the purchasing of an EA tool?

As regards the responsibility for purchasing an
EA tool, it is notable that the IT manager and
CIO play a far bigger role in the purchase of an
EA tool than in the purchase of an ERP pack-
age for example. When purchasing an ERP
package there is a larger contribution from the
business, whereas EA tooling is primarily
approached from the IT perspective. This is
rather surprising considering that the older,
larger companies tend to approach EA from a
business perspective. One possible explana-
tion for this is that the business reality has
already been reproduced in a process model-
ing tool, and this is the responsibility of the CIO
and the IT manager in most organizations.

Explanations for disappointing results

In spite of the fact that organizations already have a reason-
ably mature vision and implementation, the expected results
are not achieved in 66 percent of the EA projects. The most fre-
quent explanation given for this failure is that connecting EA to
business elements such as strategy and BPM is found to be
difficult in practice.

Other reasons given by many respondents for the failure to meet expectations were:

� Not enough support from C-level (CIO and CFO for example) so that EA is not given enough status and expectations
cannot be fulfilled in practice.

� Limited commitment from interested parties so that there is a return to old habits, and agreements are not complied
with.

� Not enough EA awareness among interested parties inside the organization. EA not a generally accepted concept
in daily business activities.

� Financial and political issues that thwart EA projects.

� Setting up an architecture takes longer than expected. This means it takes longer for the results to become visible,
which means there is a considerable risk factor for EA.

Another possible explanation is the discrep-
ancy between initial intentions for EA on the
one hand and the actual realization of the
architectures and degree of compliance with
agreements on the other. For example: 92 per-
cent of the organizations believe that vision,
strategy and objectives are determining fac-
tors for EA, yet only 40 percent incorporated
them in the architecture. On this basis it is of
course impossible to define the direct impact
of strategic choices on the architectural lay-
out. The following histogram provides an
overview of the most frequently recorded
domain architectures, including those for
objective and policies.

4

ARIS Expert Paper

Fig. 4: Responsibility for IT investments

Fig. 5: Most common EA problems

Fig 6: Most commonly recorded domain architectures

The three most frequently recorded architectures are found to be the application architecture, process architecture and
information architecture.

The recording of domain architectures does not mean there is a successful enterprise architecture in place however.
Agreements also have to be complied with about the use of one another’s information, the methods to be used, owner-

ship, and procedures for arriving at innovations. All
this is collectively referred to as EA Governance. In the
following graph, four principles of EA Governance
show that the organizations do not score highly for
maturity. This may help to explain the disappointing
results of EA projects. Even when a big effort has been
made to sort out EA, a lack of (compliance with) agree-
ments leads to relatively low yields.

Since the recorded EA is not an integrated component
of operational management, there is a lack of commit-
ment. This undermines the status of EA inside the
organization. Also, architectures are often constructed
which bear no relation to other architectures inside
the organization. As a result there are no gains from
rapid impact analyses, coordination between domain

owners and integrated project scheduling. Structural monitoring of compliance with architectural principles can help in
this regard, but this is not sufficiently applied in practice.

How can we ensure the success of an EA project?

The study shows that the following three rules will help to create the right conditions for making EA successful in an
organization:

1. Set clear, enterprise-wide EA objectives before you start, and manage expectations inside the organization. The
objectives affect the choice of the EA concept, including the choice of domain architectures and the degree of inte-
gration between them. With clear objectives it is easier to manage expectations in relation to EA inside the organi-
zation. In this way disappointment is avoided and the organization does not have to spend a lot of time and energy
trying to create an architecture which is never realized. By deploying EA enterprise-wide it is also easier to demon-
strate that a shared approach to EA pays off, in comparison to the silos of documentation in Excel, Word and niche
tools, with all the duplication and inconsistencies these involve. Use it to raise the level of commitment and cele-
brate the successes achieved.

2. Set up EA Governance and comply with it. If the methods and agreements drawn up are not complied with by the EA
roles, the yield from the EA initiative will be inadequate. Appoint a Chief EA to oversee compliance who also reports
to higher management (C-level). Higher management can in turn ask for feedback through the Chief EA about the
impact of strategic management choices on operational management and operational structures. In the context of
EA Governance, it is important to specify in the standard project approach that it is mandatory to check what infor-
mation has already been recorded on the scope of the project; this information should be used as a starting point
for the TO-BE situation. It is also important of course that EA owners validate innovations according to a fixed
release procedure, and for the new AS-IS situation to be documented in the EA tool before discharging responsibil-
ity for the project.

3. Make sure the business is sufficiently involved in these initiatives, starting with the choice of the EA tool. Do not
allow EA procedures and tooling to become an IT matter, otherwise the EA will not serve as driver of business and
IT streamlining. Choose a tool that supports all domain architectures and is able to connect them in a single repos-
itory. Also make sure the tool can incorporate ownership, combine the different methods used, and produce flexible
reports. Tools that already provide standard EA frameworks such as TOGAF, IAF and ArchiMate are preferable in this
regard.

5

ARIS Expert Paper

Fig 7: The way EA is implemented

ARIS Expert Paper
����
�������

��
��
���
�

IDS Scheer AG

Headquarters
Altenkesseler Str. 17
66115 Saarbruecken
Phone: +49 681 210-0
Fax: +49 681 210-1000
E-mail: info@ids-scheer.com

www.ids-scheer.com

© Copyright (C) IDS Scheer AG, 2001 – 2009. All rights reserved. The contents of this document is subject to copyright law. Changes, abridgments, extensions and sup-
plements require the prior written consent from IDS Scheer AG, Saarbrücken, Germany. Reproduction is only permitted provided that this copyright notice is retained
on the reproduced document. Each publication or translation requires the prior written consent from IDS Scheer AG, Saarbrücken, Germany. “ARIS”, “IDS”,
“ProcessWorld”, “PPM”, “MashZone”, ARIS with Platform symbol and Y symbol are trademarks or registered trademarks of IDS Scheer AG in Germany and in many
countries all over the world. “SAP NetWeaver” is a trademark of SAP AG, Walldorf. All other trademarks are the property of their respective owners.
U.S. pat. D561,778, pat. D561,777, pat. D547,322, pat. D547,323, pat. D547,324

ID-Number: EP-EA-0609-EN

A framework for information
systems architecture

by J. A. Zachman

With increasing size and complexity of the implementa-
tions of information systems, it is necessary to use
some logical construct (or architecture) for defining
and controlling the interfaces and the integration of all
of the components of the system. This paper defines
information systems architecture by creating a d e
scriptive framework from disciplines quite independent
of information systems, then by analogy specifies in-
formation systems architecture based upon the neu-
tral, objective framework. Also, some preliminary
conclusions about the implications of the resultant
descriptive framework are drawn. The discussion is
limited to architecture and does not include a strategic
planning methodology.

T he subject of information systems architecture is beginning to receive considerable attention.
The increased scope of design and levels of complex-
ity of information systems implementations are forc-
ing the use of some logical construct (or architecture)
for defining and controlling the interfaces and the
integration of all of the components of the system.
Thirty years ago this issue was not at all significant
because the technology itself did not provide for
either breadth in scope or depth in complexity in
information systems. The inherent limitations of the
then-available 4K machines, for example, con-
strained design and necessitated suboptimal ap-
proaches for automating a business.

Current technology is rapidly removing both concep-
tual and financial constraints. It is not hard to spec-
ulate about, if not realize, very large, very complex
systems implementations, extending in scope and
complexity to encompass an entire enterprise. One
can readily delineate the merits of the large, complex,

enterprise-oriented approaches. Such systems allow
flexibility in managing business changes and coher-
ency in the management of business resources. How-
ever, there also is merit in the more traditional,
smaller, suboptimal systems design approach. Such
systems are relatively economical, quickly imple-
mented, and easier to design and manage.

In either case, since the technology permits “distrib-
uting” large amounts of computing facilities in small
packages to remote locations, some kind of structure
(or architecture) is imperative because decentraliza-
tion without structure is chaos. Therefore, to keep
the business from disintegrating, the concept of in-
formation systems architecture is becoming less an
option and more a necessity for establishing some
order and control in the investment of information
systems resources. The cost involved and the success
of the business depending increasingly on its infor-
mation systems require a disciplined approach to the
management of those systems.

On the assumption that an understanding of infor-
mation systems architecture is important to the de-
velopment of a disciplined approach, the question
that naturally arises is “What, in fact, is information

Copyright 1987 by International Business Machines Corporation.
Copying in printed form for private use is permitted without
payment of royalty provided that ( 1 ) each reproduction is done
without alteration and ( 2 ) the Journal reference and IBM copyright
notice are included on the first page. The title and abstract, but no
other portions, of this paper may be copied or distributed royalty
free without further permission by computer-based and other
information-service systems. Permission to republish any other
portion of this paper must be obtained from the Editor.

276

ZACHMAN

IBM SYSTEMS JOURNAL, VOL 26. NO 3, 1987

systems architecture?” Unfortunately, among the
proponents of information systems architecture,
there seems to be little consistency in concepts or in
specifications of “architecture,” to the extent that the
words “information systems architecture” are al-
ready losing their meaning! Furthermore, it probably
is not reasonable to expect reconciliation or com-
monality of definition to emerge from the profes-
sional data processing community itself. The emo-
tional commitment associated with vested interests
almost demands a neutral, unbiased, independent
source as a prerequisite for any acceptable work in
this area.

In any event, it likely will be necessary to develop
some kind of framework for rationalizing the various
architectural concepts and specifications in order to
provide for clarity of professional communication,
to allow for improving and integrating development
methodologies and tools, and to establish credibility
and confidence in the investment of systems re-
sources.

Although information systems architecture is related
to strategy, both information strategy and business
strategy, this paper deliberately limits itself to archi-
tecture and should not be construed as presenting a
strategic planning methodology. The development
of a business strategy and its linkage to information
systems strategies, which ultimately manifest them-
selves in architectural expression, is an important
subject to pursue; but it is quite independent of the
subject of this work, which is defining a framework
for information systems architecture.

Derivation of the architectural concept

In searching for an objective, independent basis upon
which to develop a framework for information sys-
tems architecture, it seems only logical to look to the
field of classical architecture itself. In so doing, it is
possible to learn from the thousand or so years of
experience that have been accumulated in that field.
Definition of the deliverables, i.e., the work product,
of a classical architect can lead to the specification
of analogous information systems architectural prod-
ucts and, in so doing, can help to classify our con-
cepts and specifications.

With this objective in mind, that is, discovering the
analogous information systems architectural repre-
sentations, the following is an examination of the
classical architect’s deliverables produced in the
process of constructing a building.’

IBM SYSTEMS JOURNAL, VOL 26 NO 3 1987

Bubble charts. The first architectural deliverable cre-
ated by the architect is a conceptual representation,
a “bubble chart,” which depicts, in gross terms, the
size, shape, spatial relationships, and basic intent of
the final structure. This bubble chart results from
the initial conversations between the architect and
prospective owner. A sample of such an initial con-
versation follows:

“I’d like to build a building.”
“What kind of building do you have in mind?

Do you plan to sleep in it? Eat in it? Work in
it?”

“Well, I’d like to sleep in it.”
“Oh, you want to build a house?”
“Yes, I’d like a house.”
“How large a house do you have in mind?”
“Well, my lot size is 100 feet by 300 feet.”
“Then you want a house about 50 feet by 100

“Yes, that’s about right.”
“How many bedrooms do you need?”
“Well, I have two children, so I’d like three

feet?”

bedrooms.”

Note that each question serves to pose a constraint
(the lot size) or identify a requirement (the number
of bedrooms) in order to establish the “ballpark,” or
approximate conditions, within which any design

The architect’s drawings are a
transcription of the owner’s
perceptual requirements.

will take place. From the above dialogue, the archi-
tect can depict what the owner has in mind in the
form of a series of “bubbles,” each bubble represent-
ing a room, its gross size, shape, spatial relationship,
etc. (See Figure 1 .)

The architect prepares this bubble chart for two
reasons. First, the prospective owner must express
what he or she has in mind that will serve as a
foundation or basis for the architect’s actual design

278

work. Second, the architect must convince the owner
that the owner’s desires are understood well enough
so that the owner will p a y for the creative work to
follow, and in effect, initiate the project.

Having established a basic understanding with the
prospective owner, the architect produces the next
set of architectural deliverables, which are called
architect’s drawings.

Architect’s drawings. The architect’s drawings are a
transcription of the owner’s perceptual require-
ments, a depiction of the final product from the
owner’s perspective.

The drawings include horizontal sections (floor
plans), vertical sections (cutaways), and pictorial rep-
resentations depicting the artistic motif of the final
structure. The purpose of these drawings is to enable
the owner to relate to them and to agree or disagree:
“That is exactly what I had in mind!” or “Make the
following modifications.”

The drawings can be very detailed; however, they
are normally developed only to the level of detail
required for the prospective owner to understand
and approve the design.

Once the owner agrees that the architect has captured
what he or she has in mind, and further agrees to
pay the price for continuing the project, the architect
produces the next set of architectural deliverables,
which are called the architect’s plans.

Architect’s plans. The architect’s plans are the trans-
lation of the owner’s perceptions/requirements into
a product. The plans are a designer’s

representation

of the final product (as opposed to an owner’s rep-
resentation, which is embodied in the drawings).
The designer’s representation (plans) puts an explicit
specification around the material composition of the
final product.

The plans are composed of 16 categories of detailed
representations, including site-work, electrical sys-
tem, masonry, wood structure, etc. They describe
material relationships in the form of diagrams (draw-
ings) as well as bills-of-materials. These plans are the
final deliverables prepared by the architect and ulti-
mately become the official “record” of the finished
structure.

The architect’s plans are prepared to serve as a basis
for negotiation with a general contractor. The owner

ZACHMAN

279

takes the plans to a contractor and says, “Build me
one of these.” If the contractor builds “one of these,”
which is represented in the architect’s plans, the
owner knows that there is a high probability of
getting the desired product, as depicted in the archi-
tect’s drawings.

As a result of the negotiations between the owner
and general contractor, the plans may be modified
because of cost/price and other considerations, but
they finally serve to represent what is committed to
construction.

Contractor’s plans. At this point, the contractor re-
draws the architect’s plans to produce the contrac-
tor’s plans representing the builder’s perspective.
Such plans are prepared because complex engineer-
ing products are not normally built in a day. Some
phased approach is required which, in the case of a
building, may comprise first some site work; next
the foundation; then the first floor, and so on, until
the building is completed. Furthermore, the contrac-
tor may have technology constraints. Either the tool
technology or the process technology may constrain
his ability to produce precisely what the architect has
designed. In either case, the contractor will have to
design a reasonable facsimile which can be produced
and yet satisfies the requirements. These technology
constraints, plus the natural constraints requiring
phased construction, are reflected in the contractor’s
plans, which serve to direct the actual construction
activity.

Shop plans. Other representations, short of the final
structure itself, are prepared by subcontractors.
These representations are called shop plans and are
drawings of parts or subsections which are an out-of-
context specification of what actually will be fabri-
cated or assembled. The drawings, architect’s plans,
and contractor’s plans are in-context because the
owner, architect, and contractor are all concerned
with the entirety of the structure, whereas the sub-
contractors’ representations are concerned with
components or parts of the total structure. These
shop plans might even serve as patterns for a quantity
of identical parts to be fabricated for the project.

The building. In the case of producing a building,
the final representation is the physical building itself.

In summary, there is a set of “architectural” repre-
sentations that are produced during the process of
constructing a building. The set is given in Table 1.

280 ZACHMAN

A generic set of architectural representations

Now that we have specified the set of architectural
representations produced during the process of con-
structing a building, it becomes apparent that this
set of “architectures” may be generic to the process
of building any complex engineering product. A
cursory examination of military airframe manufac-
turing appears to validate this hypothesis as follows:

a. Concepts equals “bubble charts” (ballpark view).
The airframe manufacturers begin with some
“concepts,” which are specifications for the “ball-
park” in which they intend to manufacture. For
example, concepts for the final product indicating
that it will fly so high, so fast, so far, for such and
such purpose, with so many people, etc. are for-
mulated to establish its gross size, shape, and
performance.

b. Work breakdown structure equals architect’s
drawings (owner’s view). The work breakdown

IBM SYSTEMS JOURNAL, VOL 26. NO 3, 1987

structure is the “owner’s perspective.” The gov-
ernment requires that the manufacturer specify
the work to be accomplished in terms of the
components/systems against which costs are ac-
crued and schedules are managed. In this fashion,
the government controls the manufacturer in the
production of the product.

c. Engineering design equals architect’s plans (de-
signer’s view). Engineering, the designer, trans-
lates the work breakdown structure into a physi-
cal product. The resultant “engineering design” is
composed of drawings and bills-of-material.

d. Manufacturing engineering bill-of-materials
equals contractor’s plans (builder’s view). Manu-
facturing engineering, the builder, applies the laws
of nature and technology constraints to the engi-
neering design to describe how to build the prod-
uct (i.e., inside-out, bottom-up) and to ensure
that everything designed is actually producible.

e. Assembly and fabrication drawings equals shop
plans (detail view). Assembly and fabrication

An analogous set of architectural
representations is likely to be

produced in building any complex
product.

drawings are the instructions to the shop floor
personnel on how they are to assemble/fabricate
the pieces or parts as stand-alone entities.

f. Machine tool representation (machine view). Be-
cause manufacturing uses computer-controlled
equipment to produce some parts, they insert an
additional representation of the final piece or
part, short of the physical part itself. This repre-
sentation is a “program” (i.e., “numerical code
program”) that is a machine language represen-
tation.

g. Airplane equals building (finished product). The
final representation is the actual, physical item
itself.

In any case, there appear to be conceptual equiva-
lents in the manufacturing industry for the architec-

IEM SYSTEMS JOURNAL, VOL 26, NO 3, 1987

tural representations of the construction industry.
This equivalency would strengthen the argument
that an analogous set of architectural representations
is likely to be produced during the process of building
any complex engineering product, including an in-
formation system,

Before identifying the information systems analogs,
it is useful to make some general observations re-
garding architecture.

First, there appear to be three fundamental architec-
tural representations, one for each “player in the
game,” that is, the owner, the designer, and the
builder. The owner has in mind a product that will
serve some purpose. The architect transcribes this
perception of a product into the owner’s perspective.
Next the architect translates this representation into
a physical product, the designer’s perspective. The
builder then applies the constraints of the laws of
nature and available technology to make the product
producible, which is the builder’s perspective.

Preceding these three fundamental representations,
a gross representation of size, shape, and scope is
created to establish the “ballpark” within which all
of the ensuing architectural activities will take place.

Succeeding the three fundamental representations
are the detailed, out-of-context representations
which technically could be considered architectures
because they are representations short of being the
final physical product. However, they are somewhat
less interesting “architecturally,” since they do not
depict the final product in total and are more ori-
ented to the actual implementation activities. None-
theless, they are included in this discussion for the
purpose of ensuring a comprehensive framework.

A significant observation regarding these architec-
tural representations is that each has a different
nature from the others. They are not merely a set of
representations, each of which displays a level of
detail greater than the previous one. Level of detail
is an independent variable, varying within any one
architectural representation. For example, the de-
signer’s representation (i.e., architect’s plans) is not
merely a succeeding, increasing level of detail of the
owner’s representation (i.e., architect’s drawings). It
is different in nature, in content, in semantics, and
so on, representing a different perspective. The level
of detail of the designer’s representation (i.e., plans)
is variable, and quite independent of the level of
detail of the owner’s representation (i.e., drawings).

ZACHMAN 281

Table 2 The architectural representations produced over the process of building a complex engineering project, along with
analogs in the building, airplane, and information systems communities

Generic Buildings Airplanes

Owner’s Architect’s Work hmkdown

Designer’s

Builder’s Contractor’s Manu

Out-of-contex t

Machine language – Numerical code

representation drawings

representation
representation
representation
representation

In the same fashion, each of the architectural repre-
sentations differs from the others in essence, not
merely in level of detail.

Given this description of the perspectives (i.e., own-
er’s perspective, designer’s perspective, builder’s per-
spective, etc.) of architectural representation pro-
duced over the process of building a complex engi-
neering product, it is relatively straightforward to
identify the analogs in the information systems area,
since information systems are also “complex engi-
neering products.” Table 2 identifies those informa-
tion systems analogs along with the building and
airplane equivalents.

Different types of descriptions for the same product.
Before the idea regarding the different perspectives
(and therefore the different architectural representa-
tions produced over the process of building complex
engineering products) is developed further, it is nec-
essary to introduce a second, entirely different idea.
Specifically, there exist different types of descriptions
oriented to different aspects of the object being de-
scribed. Table 3 characterizes three such types of
descriptions, one of which is oriented to the material
of the product, another to its function, and the third
to the relative location of its components.

In spite of the fact that each of the descriptions may
be describing the same product, each of them is
unique and stands alone because each serves quite
different purposes. Furthermore, none of the descrip-

tions explicitly says anything about any of the other
descriptions. Only assumptions can be made from
one about the contents of another. For example, a
bill-of-materials exists independently of, and is
clearly different from, functional specifications or
drawings. Looking at a bill-of-materials tells nothing
about functional specifications or drawings (relative
locations of components). Only assumptions can be
made about function or location, depending upon
how descriptively named the parts are in the bill-of-
materials. Similarly, the functional specifications say
nothing explicit about the bill-of-materials or the
drawings, and the drawings say nothing explicit
about the bill-of-materials or functional specifica-
tions.

In short, each of the different descriptions has been
prepared for a different reason, each stands alone,
and each is different from the others, even though
all the descriptions may pertain to the same object
and therefore are inextricably related to one another.

The “description” row of Table 3 suggests that there
likely are additional descriptions not characterized
in the table as the material description addresses
“WHAT,” the functional description addresses
“HOW,” and the location description addresses
“WHERE.” The implications are that there must be
at least “WHO,” “WHEN,” and “WHY” descriptions as
well. Discussion of these additional types of descrip-
tions is reserved for the future, since using only three
different descriptions introduces considerable com-

282 ZACHMAN

IBM SYSTEMS JOURNAL, VOL 26, NO 3, 1987

Table 3 Three different types of descriptions of the same product

Description I Description H Description 111

Orientation Material Function Location

Focus Structure Transform Flow

Description WHATthe thing is made HOWthe thing works WHERE the flows (connections)

Example Bill-of-materials Functional specifications Drawings

Descriptive model Part-relationshippart Input-process-output Site-link-site

of exist

Table 4 Information systems analogs for the different types of descriptions

Description I Description II Description 111
(material) (funoti) (l-tw

Information systems analog Data model Rocess model Network model

I/S descriptive model Entity-relationshipentity Input-process-output Node-line-node

plexity into the subject of information systems ar-
chitecture at this time. Therefore, the remainder of
this paper will be limited to the three types of de-
scriptions contained in Table 3. For future reference,
Appendix A is included and contains a preliminary,
Table 3-like characterization of the additional de-
scriptive types related to people (who), time (when),
and motivation (why).

As was the case with the earlier idea regarding the
different perspectives of the different participants in
the architecture process, once again it is straightfor-
ward to identify the information systems analogs for
the elements of the second idea, that is, the different
types of descriptions for the same object, as follows:

a. Functional description-In information systems
terms this would likely be called a process (or a
functional) model, and the descriptive represen-
tation would be called the same as the general
case, “input-process-output.”

b. Material description-Generally speaking, the
material description describes the “stuff the thing
is made of,” which in the case of information
systems is data. Therefore, in information systems
terms, the analog for the material description
would be a data model, and in the data vernacu-
lar, “part-relationship-part” would become “en-
tity-relationship-entity.’’ The data model is the

equivalent of the bill-of-materials for the infor-
mation systems product.

c. Location description-In information systems,
this would likely be called the network model, in
which the focus is on the flows (connections)
between the various components. In the infor-
mation systems network vernacular, “site-link-
site” would become “node-line-node.”

Therefore, the rows of Table 4, which constitute the
analogs in information systems for the more generic
types of descriptions, could be added to Table 3.

The framework. Two ideas have been discussed thus
far:

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

b. The same product can be described, for different
purposes, in different ways, resulting in different
types of descriptions.

The combination of the two ideas suggests that for
every different type of description, there are different
perspectives (and actually different representations)
for each of the different participants. For example,
for the material (or data) description, there are the

ZACHMAN 283 IBM SYSTEMS JOURNAL, VOL 26 NO 3. 1987

owner’s representation, the designer’s representa-
tion, the builder’s representation, etc. For the func-
tional (or process) description, there are the owner’s
representation, the designer’s representation, the
builder’s representation, etc. For the location (or
geographic) description, there are also the owner’s
representation, the designer’s representation, the
builder’s representation, etc.

Figure 2 illustrates the total set of different perspec-
tives for each type of description. Note that because
the intent is to depict a framework for information
systems architecture, all the information systems
analog names from Tables 2, 3, and 4 have been
used in Figure 2 in place of the more generic man-
ufacturing or construction names. Also, the machine
language perspective in Table 2 has been omitted,
merely because it is not as interesting as the others
from an “architectural” point of view.

The one single factor that makes this framework
extremely interesting is the fact that each element
on either axis of the matrix is explicitly differentiable
from all other elements on that one axis. That is, the
model of the business (owner’s perspective) is differ-
ent from the model of the information system
(designer’s perspective), and so on. (Remember from
earlier discussions that these representations are not
merely successive levels of increasing detail but are
actually diferent representations-different in con-
tent, in meaning, in motivation, in use, etc.) Also,
the data description column (entity-relationship-en-
tity) is different from the process description column
(input-process-output), and so on. 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, and further, each cell in the
matrix will be explicitly different from all the other
cells.

Architectural representations for describing data

To illustrate how each cell differs from all of the
others, examine the data description column of Fig-
ure 2. Even though every cell in the column is
descriptive type I relating to data, and the descriptive
model is “entity-relationship-entity,’’ the meanings
of “entity” and “relationship” change with the dif-
ferent perspectives of the participants in the archi-
tecture process. The only exception is the scope
description (ballpark) cell, in which entity is defined
the same as entity in the model of the business cell.
This ballpark perspective is merely a very high level
of aggregation which is being used like the architect’s

“bubble charts” to establish the gross size and scope
of the data strategy, leading to the decision regarding
investment of data processing resources in managing
data.

Scope/description (ballpark perspective)-data col-
umn. The scope description cell in the data descrip-
tion column of Figure 2 could be expected to be a
list of all the things that are important to the business,
and therefore, that the business manages.*

Table 53 is an example of an architectural represen-
tation in the data description column from the scope
description perspective.

This representation would be a list of things (i.e.,
material-grammatically, nouns) as opposed to a list
of actions (i.e., processes-grammatically, verbs). A
list of actions (verbs) could be expected in the next
column, process description. The list of things (ma-
terial) in the data description column would be called
“entities” in data vernacular.

Since this architectural representation is at the scope
description row, one could also expect that the enti-
ties (things) would likely be entity “classes,” that is,
higher levels of aggregation, because the decision
being made as a result of this representation would
be one of scope, not one of design. A selection would
be being made of the entity class or classes in which
to invest actual information system (I/s) resources
for data “inventory” management purposes.

Further, in this cell, one might not expect to be
definitive about the relationship between entities.
The scope decision would constitute overlaying the
business values on the total range of possibilities to
identify a subset of entity classes for implementation
which is consistent with the resources available for
investing in information systems-specifically, in
this case, the management of the selected class (or
classes) of data. Furthermore, it is useful to start with
the total list of entities because, at times, the entities
that are not selected are as significant as those that
are selected.

The strategy/resource investment decision is made
by understanding the values/strategies of the busi-
ness, which can be done by using various data-
gathering/analytical techniques. The decision is
made by overlaying the analytical conclusions on
the total list of business entities in the scope descrip-
tion cell and thereby selecting the subset of business
entities in which to actually invest data processing

284 ZACHMAN IBM SYSTEMS JOURNAL, VOL 26, NO 3, 1987

Figure 2 Framework for information systems architecture

~~~

IBM SYSTEMS JOURNAL, VOL 26 NO 3 1987 ZACHMAN 285

Table 5 Sample entities-Architectural representation in the
data description column from the scope description
perspective3

Product Policies and procedures
Legal requirements
G/L accounts
Accounts payable
Accounts receivable
Long-term debt
Marketplace

Competitor Promotion
Building and real estate Purchase order
Objectives Customer order
Job Pruduction order
Organization unit Shipment

resources. Since this paper is intended to define
architecture, not to describe strategy methodologies,
nothing further will be said about strategic planning
except to point out that similar kinds of decisions
have to be made relative to every other scope descrip-
tion cell. That is, out of the total list of business
processes, the business likely does not have enough
data processing resources to automate all the pro-
cesses. Therefore, a decision will have to be made to
select a subset in which to invest data processing
resources for actual automation. By the same token,
out of the total list of locations in which the business
operates, it probably does not have enough data
processing resources to put hardware and software
in every location. Again, decisions will have to be
made in selecting a subset of locations in which to
actually install hardware and software.

These are the strategy/resource investment decisions
that are supported by the scope description cells in
the top row of Figure 2. Although they are inextri-
cably related, the probability is that each decision
will have to be addressed independently of the others.
Discussion now continues on the framework, partic-
ularly the data description column of Figure 2.

Model of the business (owner’s perspective)-data
description column. Since this model (or description)
appears in the data description column, the descrip-
tive model will be “entity-relationship-entity,” and
when owners (users) describe the business and say
“entity,” what they have in mind are business enti-
ties?

For example, when owners (users) specify an entity
such as “employee,” what they have in mind would
be real beings, that is, flesh and blood employees
who work for the business. That meaning of “em-

ployee” is entirely different from the one used in an
information systems model (the designer’s perspec-
tive), in which “employee” would refer to a record
on a machine, which also happens to be called
“employee,” however conceptually and entirely dif-
ferent it is. (This data entity, as opposed to business
entity, would be found in the cell directly below.)
Figure 3 is an example of a model of a business,
oriented to data.

Further, when owners, describing a business, specify
a relationship between the entities, what they have
in mind would be the business rule or strategy that
relates one entity to another entity.5 A business rule
or strategy, for example, might be “in this business
we ship this product from that warehouse only.” An
entirely different rule would be “in this business, we
ship this product from any warehouse we have.”
These are business rules and not data relationships
such as would be expected in the model of the
information system (designer’s perspective) in the
cell below the Model of the Business shown in Figure
2.

Finding good “real-life’’ examples which crisply il-
lustrate each of the architectural representations is
difficult. There are two reasons for this difficulty.
First, when the real-life representations were being
developed, no framework existed to clearly define
and differentiate one representation from the others.
Therefore, many real-life illustrations are a mixture
of representations, both conceptually (e.g., business
entities and data entities get mixed together) and
physically (e.g., entities and inputs/outputs, that is,
user views from the process description column of
Figure 2, get mixed together). Second, real-life ex-
amples are hard to understand because it is not
always clear what model, or cell, the author had in
mind when developing the representation.

An illustration of this difficulty is found in Figure 3 .
It is clear that this model is describing data and not
process, but the question is, did the author have in
mind a description of a business or a description of
an information system? In this case, it is likely that
the description is of a business because of the exis-
tence of the “many-to-many’’ relationships. In real
life, there are many “many-to-many’’ relationships,
but the database management concepts that are pop-
ular today require that the “many-to-many’’ relation-
ships be resolved in order to run on a machine.
Therefore, “artificial” entities have to be created to
resolve the “many-to-many’’ relationships, and the
model in Figure 3 would have to be “normalized”

286 ZACHMAN IBM SYSTEMS JOURNAL, VOL 26. NO 3, 1987

Figure 3 Sample entity relationship model – Model of the business (owner’s perspective) – Data column3

before it could be a legitimate model of an infor-
mation system. In any case, since the model in Figure
3 is not “normalized,” by today’s standards at least,
it is clearly a model of a business as opposed to a
model of an information system.

Model of an information system (designer’s perspec-
tive)-data description column. Once again, since
the model of the information system is in the data
description column of the framework, the descriptive
model used is “entity-relationship-entity.” But from
the designer’s perspective, the meaning of “entity”
would change to that of a record on a machine, and
relationship would change to that of a data relation-
ship. Clearly, the example in Figure 4 is a model of
an information system and not a model ofa business,
because of the existence of “artificial” entities, spe-
cifically the “DEPTPROJ” entity (resulting from the
concatenation of department and project), which is
not a real-life item, but something in an information
system, created in the process of translating the
business description into an information systems
“product.” In the data design vernacular, this ex-

ample of Figure 4 would likely be called a data

Technology model (builder’s perspective)-data de-
scription column. As in the previously described cells,
the descriptive model in the builder’s cell is “entity-
relationship-entity,’’ and what could be expected is
the physical implementation or data design for the
conceptual model of the information system.

In the technology model, the laws of nature and
technology constraints are being applied. A decision
is made to use Information Management System
(IMS) or I B M Database 2 ( D B ~ ) or XYZ, and depending
on the choice, the meaning of entity and relationship
change. In the case of IMS, entity means “segment”
and relationship means “pointer.” In the case of D B ~ ,
entity means “row” and relationship means “key,”
e t ~ . ~ Figure 5 is an example of an architectural
representation of the technology model (builder’s
perspective) in the data description column of the
framework.

IBM SYSTEMS JOURNAL, VOL 26. NO 3, 1987 ZACHMAN 287

Figure 4 Sample conceptual data model – Model of
the information system (designer’s perspective) –
Data column3

Detailed description (out-of-context perspective)-
data description column. The descriptive model is
“entity-relationship-entity” in the detailed descrip-
tion cell. This cell is analogous to the subcontractors’
out-of-context descriptions. What could be expected
is Data Definition Language. An example might be
a DBDGEN in which the entities are specifications of
the “fields,” and relationships are specifications of
the “addre~ses.”~ An example is shown in Figure 6.

This description is “compiled” to produce the ma-
chine language representation (relative addressing-
not shown in the figure), which is further “link-
edited” to produce the actual physical data (absolute
addressing) residing in the machine.

It is clear that real-life examples can be found to
illustrate all of the architectural representations for
the various viewpoints or perspectives that are cre-

Real-life examples can be found to
illustrate all of the architectural

representations.

ated for the data (or material) description of the
information system.

Although actual samples (figures) for each of the
remaining cells are available, no attempt will be
made to include them in this paper. Let it be suffi-
cient merely to describe how the meanings of the
descriptive model terms change in the remaining two
columns as the representations shift from perspective
to perspective.

Architectural representations for describing the
process

The descriptive model for describing the process is
input-process-output,” and, as in the case of the

data description column, each of the representations
in the different cells in the process description col-
umn of Figure 2 have different meanings associated
with “input,” “process,” and “output.”

“ ’

At the scope description (ballpark perspective) cell,
“process” would mean business process. It would
likely be some process “class,” a relatively high level
of aggregation, as the decision being made from the
scope description cell is the selection of some subset
of the appropriate business processes in which to
invest some finite amount of information systems
resources for actual automation purposes. Further,
in making the scope decision, it is unnecessary to be
definitive about the input and output linkages be-
tween the functions by overlaying the business values
against the total range of automation possibilities.
Therefore, just a list of business processes would
appropriately be expected in this cell representation.

In the model of the business (owner’s perspective) in
the process description column, an example might

288 ZACHMAN IBM SYSTEMS JOURNAL, VOL 26. NO 3, 1987

Figure 5 Sample DL/I physical model -Technology model (builder’s perspective) – Data column3

DEPT

T I r – – – A \ I > I IPHONE \ /

be a functional flow diagrams.’ in which “process”
would be a business process (not an information
systems process) and inputs and outputs would be
business resources such as people, cash, material,
product, etc.

In the model of the information system (designer’s
perspective) for the process description column, an
example would be a data flow diagram8-’’ in which
processes are information systems (application)
processes (not business processes) and the inputs/
outputs are “user views”-some aggregations of data
elements that flow into and out of the application
processes, connecting them in some sequential fash-
ion. (Note that this does not preclude depicting
manual functions that are introduced as part of the
information system.)

Proceeding to the technology model (builder’s per-
spective)-process description column, we see that

the meaning of “input-process-output’’ changes once
again. In applying the physical constraints of the
technology chosen for implementation, for example,
I B M 3380 Direct Access Storage Devices versus I B M
3480 Magnetic Tape Subsystems (disks), I M S versus
Customer Information Control System (CICS), COBOL
versus FORTRAN; I B M 3270 terminal devices (video
displays) versus I B M Personal Computers, etc., the
builder’s perception of a process becomes a computer
function, and inputs and outputs are device formats.
The predictable example would be a structure
chart l o – ” and screen/device formats.

For the detailed description (out-of-context) cell, the
example is a “program” in which “process” is a
language statement and the inputs and outputs are
control blocks. I ‘ , I 2

The program is compiled to produce object code,
the machine language representation (not shown in

IBM SYSTEMS JOURNAL, VOL 26, NO 3, 1987

Figure 6 Sample detailed description (out-of-context perspective) Data column

DBDG E N – SAMPLE STATEMENTS
DBD

NAME=STDCDBP,
ACCESS=HDAM,
RMNAME=(DLZHDClO,
3,
100,
600)

DD1 =STDCDBC,
DEVlCE=3340,

DATASET

BLOCK=(2048),
SCAN=2

NAME= STSCCST,
PARENT= 0

SEGM

BYTES=106,
POINTER =TWIN

FIELD
NAME = (STQCCNO,SEQ, U),
BYTES = 6,
START= 1,
TYPE=C

ETC.

DATA BASE DESCRIPTION NAME X
HIERARCHICAL DIRECT X
RANDOMIZING ROUTINE PHASENAME X
ROOT ANCHOR POINTS PER BLOCK X
ROOT ADDR. AREA HI RELATIVE BLK X
INSERT BYTES LIMIT FOR RAA X

FILE NAME X
DISK DEVICE X
VSAM CONTROL INTERVAL SIZE X
# CYLINDERS SCAN FOR ISRT SPACE X

SEGMENT NAME FOR EMP NAME/ADDR X
IT IS A ROOT SEGMENT X
DATA LENGTH X
PHYSICAL TWIN FWD ONLY X

UNIQUE KEY FIELD (EMP #) X
FIELD LENGTH X
WHERE IT STARTS IN SEGMENT X
ALPHAMERIC DATA X

Figure 2) which, in turn, is assembled to produce
running instructions for the actual, physical system.

Again, it is clear that examples can be found for
every descriptive representation for the process de-
scription column, as well as for the data description
column.

Architectural representation describing the
network

The descriptive model for the network set of archi-
tectural representations in the network description
column of Figure 2 is “node-line-node.”

From the scope description (ballpark) perspective,
what could be expected is a list of locations in which
the business operates. Therefore, “node” would
mean business location, likely at a high level of

aggregation, that is, showing little detail about the
“contents” of the location. The locations might even
be arranged on a map, a geographical construct. If
lines were shown, they would probably merely indi-
cate where there are communications or logistics
connections between the locations. The purpose
served, once again, is the strategy/resource invest-
ment decision in which the main decision is to select
the subset of locations in which to actually locate
technology (hardware/software).

The owner, in describing the business, that is, pro-
ducing the model of the business as related to the
network (or the connectivity characteristics of the
business), would perceive the “nodes” to be business
units, an aggregation of business resources (people,
facilities, responsibilities, etc.) at some geographical
location. The lines would represent logistics connec-
tions or flows, probably including communications

IBM SYSTEMS JOURNAL, VOL Z , NO 3, 1987

linkages, but even more basically would represent
the distribution structure or logistics network along
which communications take place.

In the model of the information system (the design-
er’s perspective) for the network description, the
information system designer would perceive the
node to be some 11s function, like a processor, storage
unit, or access point. This would be a conceptual
representation, independent of specific technology

Technology constraints would be
introduced in the technology model.

which would be introduced in the builder’s cell. The
line, from a designer’s standpoint, would be a com-
munication line at the conceptual level, such as a
leased line, dial-up service, U S . mail, etc. This cell
would serve the purpose of making the “distributed
systems” decisions, that is, specifying where the 11s
facilities would be installed, which of them would be
connected, and by what type of connection.

The technology constraints would be introduced in
the technology model (the builder’s perspective).
This cell would depict physical hardware and soft-
ware, for example, an IBM 3090 processor, 3270
display device, Personal Computer, Multiple Virtual
Storage ( MVS) operating system, Advanced Com-
munications Function/Network Control Program
(ACFINCP), etc. at the nodes and Synchronous Data
Link Control (SDLC), bisynchronous communica-
tions, 4800 baud, etc. for the lines.

In the detailed description (out-of-context) cell, the
nodes would be addresses, and the lines would be
protocol^.’^

In summary, although actual pictures have not been
included in the paper, examples could be presented
to illustrate every hypothetical architectural repre-
sentation postulated by the relationship among the
various architectural perspectives and the different
types of descriptions.

IEM SYSTEMS JOURNAL, VOL 26 NO 3, 1987

Table 6 lflthen table depicting different architectural
representations used within different data
processing functions

If you are: Then you probably think
architecture is:

A programmer

The database

An analyst

A planner

administrator

The communications
manager

An operations manager

A network administrator

A program support
representative

A computer designer

The president

A structure chart

Data design

A data flow diagram

Some combination of entity/
relationship diagrams and/
or functional flow diagrams

The business logistics
infrastructure and/or the
distributed systems
architecture

The system architecture

The network architecture

Detailed data and program
descriptions

Machine language (not
represented on the
summary chart, Figure 2)

Entity classes, process classes
and/or a map

Conclusions

When the question is asked, “What is information
systems architecture?” the answer is, “There is not
an information systems architecture, but a set of
them!” Architecture is relative. What you think ar-
chitecture is depends on what you are doing. For an
example, see Table 6.

We are having difficulties communicating with one
another about information systems architecture, be-
cause a set of architectural representations exists,
instead of a single architecture. One is not right and
another wrong. The architectures are different. They
are additive and complementary. There are reasons
for electing to expend the resources for developing
each architectural representation. And there are risks
associated with not developing any one of the archi-
tectural representations.

Research is being done to create more explicit defi-
nitions for each of the architectural representations
in this framework, to understand the design issues,
the reasons for developing each representation, the
risks associated with not developing any one, and
the “tool” implications of each cell.

Summary
Yourdon Press, Inc., New York (1978).

In summary, by studying fields of endeavor external
to the information systems community, specifically ysis, Yourdon Press, Inc., New York (1984).
those professions involved in producing complex lo. Design A i d an

185 I , IBM Corporation; i

tion, manufacturing, etc.), it is possible to hypoth- Programming, Prentice-Hall, Inc., Englewood Cliffs, NJ
esize by analogy a set of architectural representations (1977).

12. H. D. Leeds and G. M.
Fundamentals. McGraw-mi1 BOOK LO., inc., I Y ~ W r orK
(1961).

Manual GC30-3073, IB
IBM branch offices.

8. T. DeMarco, Structured Analyses and System Specifications,

9. S . M. McMenamin and J. F. Palmer, Essential Systems Anal- I
I
I

engineering products (e-g*, architecture/constmc- 1 1 . J. K. Hughes and J. I. 1 .._.._____, _ _ ________.I_ – –

for information systems.

The resultant “framework for information systems
architecture” could prove quite valuable for

Improving professional communications within

Understanding the reasons for and risks of not
~ ’ ’ ’ > ~ ~ ~ ~ o , u ~ ’ – – – – – ‘ ’ – ’

developing any one architectural representation. the Business Systems Plannin
Placing a wide variety Of tools and/or methodol- Mr. Zachman joined IBM in

Developing improved approaches (including ing One as Account

13, systems Network Archjte-+.,-” Tnnl…;mr A.,n-.;n.r, r.,rtn-r

I the information systems community. . – – –
ogies in relation to one another.

architectural representations, as well as possibly

related positions in Chicago, New York, and Los Angeles, includ- I
pany. He has bec- :-..-‘..-_I

method
tion in 1973. H~
information systems planning, and has written-a number of articles
on the subject. His current responsibilities include working both

dressing planning approacher
mation systems. I“- 7n,.h-.

number of years i
Commander in

Reprint Order No. G321-5298.

methodologies and tools) to produce each of the

rethinking the nature of the classic “application
development process” as we know it today.

_ .

Cited references

I . G. D. Larson, private communication, Gaede and Larson,
Architects International Association, Pasadena, CA (1985).

2. Business Systems Planning-Information Systems Planning
Guide, Application Manual GE20-0627, IBM Corporation;
available through IBM branch offices.

3. Business Systems Planning, class material, IBM Corporation,
Information Systems Management Institute, Los Angeles, CA.

4. D. S. Appleton, ‘‘Business rules: The missing link,” Datama-
tion 30, No. 16, 145-150 (October 15, 1984).

5. C. J. Date, An Introduction to Database Systems, Addison-
Wesley Publishing Co., Reading, MA (1981).

Aeronautical Labs, Air Force Systems Command, Wright-
Patterson Air Force Base, OH 45433 (June 1981).

7. P. P. Chen, Entity-Relationship Approach to Systems Analysis
and Design, University of California at Los Angeles, Los
Angeles, CA (December 1979).

Appendix A: Possible characterization of additional types of descriptions

I Orientation People Time Purpose
I Focus Responsibility Dynamics Motivation
I Description WHO is doing what WHEN the events take place WHY choices are made

Example Organization chart Production schedule Objectives hierarchy

Descriptive Organization-reporting- Event-cycle-event
model organization

Objective-precedent-
objective

292 ZACHMAN IBM SYSTEMS JOURNAL, VOL 26. NO 3, 1987