DRAFT
1
2
Department of Defense
Enterprise Architecture Federation Strategy
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Draft Version 1.01
04 December 2006
Prepared by the DoD CIO
81921640
DRAFT
DRAFT
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
TABLE OF CONTENTS
1.
Introduction ............................................................................................................................1
1.1. Intended Audience .........................................................................................................2
1.2. Background ....................................................................................................................2
1.3. Related Guidance ...........................................................................................................4
2. Purpose....................................................................................................................................4
3. Vision.......................................................................................................................................4
4. Goals ........................................................................................................................................4
5. Objectives................................................................................................................................4
6. Benefits ....................................................................................................................................5
6.1. Benefits to DoD Decision Makers .................................................................................5
6.2. Benefits to DoD Architects ............................................................................................6
6.3. Benefits to Architectural Governance Bodies .............................................................7
7. Guiding Principles .................................................................................................................7
8. Scope........................................................................................................................................8
9. Federated EA Defined ...........................................................................................................8
10.
EA Federation Concepts....................................................................................................9
10.1.
The EA Federation .....................................................................................................9
10.2.
Tiered Accountability ................................................................................................9
10.3.
High-level Taxonomies ............................................................................................10
10.4.
Architecture Categorization ...................................................................................10
10.5.
Context ......................................................................................................................11
10.6.
Boundaries for Tiers ................................................................................................11
10.7.
Semantic Alignment .................................................................................................11
11.
EA Services — Making the EA Visible, Accessible, and Understandable ..................12
11.1.
Metadata ...................................................................................................................12
11.2.
Registration ..............................................................................................................13
11.3.
Discovery ...................................................................................................................13
12.
Governance .......................................................................................................................14
12.1.
EA Federation Roles and Responsibilities .............................................................15
12.2.
Information Assurance ............................................................................................16
13.
Implementing the Federated EA ....................................................................................17
13.1.
Pilot Efforts...............................................................................................................17
14.
Critical Success Factors ...................................................................................................18
15.
The Way Ahead ................................................................................................................18
APPENDIX A: ACRONYM LIST ..............................................................................................1
APPENDIX B: DEFINITIONS ...................................................................................................1
APPENDIX C: REFERENCE DOCUMENTS ..........................................................................1
APPENDIX D: RELATED GUIDANCE....................................................................................1
APPENDIX E: ARCHITECTURE CATEGORIZATION, STRUCTURE (TAXONOMY) 1
APPENDIX F: DOD FEDERATED EA GOVERNANCE DOCUMENT ..............................1
APPENDIX G: A DETAILED LIST OF CRITICAL SUCCESS FACTORS (CSF) BY
CSF CATEGORY ..........................................................................................................................1
APPENDIX H: ACTIVITY-BASED EA FEDERATION ALIGNMENT ..............................1
ii
81921640
DRAFT
DRAFT
68
69
70
71
72
73
74
75
76
77
78
79
80
LIST OF FIGURES
FIGURE 1: ARCHITECTURE LEVELS FOR TIERED ACCOUNTABILITY…………………………...10
FIGURE 2: MAKING ARCHITECTURE ACCESSIBLE .............................................................. 14
FIGURE E-1: FEDERATED DOD EA TAXONOMY ................................................................E-1
FIGURE H-1. FEDERATION RELATIONSHIPS AMONG ACTIVITIES ........................................ H-1
LIST OF TABLES
TABLE 1: ROLES AND RESPONSIBILITIES FOR INDIVIDUAL LEVELS OF FEDERATION ............. 15
TABLE E-1: FEDERATED DOD AND MA TAXONOMY CM AUTHORITY .................................E-1
iii
81921640
DRAFT
DRAFT
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
1. Introduction
The Department of Defense (DoD) Federated Enterprise Architecture (EA) represents the
“next generation” Global Information Grid (GIG) Architecture.
The current GIG Architecture, along with the Net-Centric Operations and Warfare
Reference Model (NCOW RM) is an overarching architecture description of the GIG.1
However, the DoD is too large and complex to be described within a single integrated
architecture. Additionally, Enterprise architectures have an inherent problem. To fully describe
an enterprise, architects must either abstract the content into simple constructs that don’t lend
themselves to supporting a broad range of decisions, or they must compile massive amounts of
data that make comprehension difficult at best. One of the primary objectives of enterprise
architectures is to describe the enterprise so that decision makers can make informed decisions
based on or within a common context. It will result in the development of a cohesive EA
supporting the alignment and integration of architecture efforts in support of DoD business and
warfighter strategic goals. Therefore, architects must constantly balance complexity with utility.
The DoD GIG Architecture is no different.
What is required is a rethinking of the GIG architecture concept to effectively leverage
current architecture efforts and maintain comprehension while, at the same time, providing DoD
decision makers with the information they need. Federating existing architectures of DoD
elements that describe the various echelons (or tiers) is one way to achieve this goal. Federation
techniques allow disparate architectures (based on a variety of established frameworks) to be
meaningfully related and permit acceleration of new architecture efforts across the DoD
community to support DoD decision makers who require more detailed content that is not
reasonable for the department level.
To date, there have been advancements in both the architecture and stakeholder
communities that use architecture information. Architecture products, however, are presently not
as sufficiently discoverable and accessible as needed to support decision making. Today’s
architectures are built for specific purposes and viewpoints; they do not normally refer to or
relate to each other as they should to gain maximum value from the architecture investment.
As a remedy, the Department has chosen architecture federation2 as a new GIG architecture
paradigm. The next generation GIG architecture will be constructed by federating the separate
architecture artifacts throughout the DoD and employ a set of EA Services for registering,
1
The current DoD overarching architecture description consists of three Components: GIG Architecture ver 1.0,
GIG Architecture ver 2.0, and the NCOW RM ver 1.1. The GIG Architecture consists of architecture products
describing the DoD Enterprise from the perspective of five different scenarios. Version 1.0 described the “as-is”
enterprise circa 2000; ver 2.0 describes the “to-be” enterprise circa 2015. While the NCOW RM is not an
architecture itself it does establish the strategies and target technical standards for migration to a net-centric
operating environment as the Department moves from the “as-is” to the “to-be”and therefore servs as a part of the
Enterprise Architecture as defined by OMB for Clinger-Cohen compliance.
2
The concept of federation or “federalism” infers both a division of authority, accountability and interdependence
between the Department level and the Commands, Services, and Agencies. See page 8 for full explanations of
Federated EA and Federation Concepts.
1
81921640
DRAFT
DRAFT
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
discovering, and utilizing architecture data to support key DoD decision processes by
implementing concepts from the DoD Net-Centric Strategies.
1.1.
Intended Audience
The primary audience for the DoD Federated Enterprise Architecture Strategy Document
includes two distinct classes — first, those responsible for implementation of the Federated EA,
and second, producers and consumers of architecture information, e.g., decision makers, program
managers, analysts, operators, architects, and engineers within DoD and external partners in the
extended enterprise.
1.2.
Background
The Director, Office of the Assistant Secretary of Defense for Networks and Information
Integration, Architecture & Interoperability (OASD[NII/A&I]) has worked with the Services
Chief Architects to define the federated approach. The federated approach will guide the
building of the next generation GIG Architecture. This approach recognizes the need for
autonomy but requires linkages and alignment of architectures from the Program level up to the
Federal Enterprise level. OASD(NII) will introduce requirements in phases to achieve enterprisewide GIG descriptions that move the Department toward a shared Net-Centric Vision and
Transition Plan. These requirements are being identified and met through systems engineering
processes that leverage architecture descriptions as blueprints. The use of shared architecture
descriptions in Test & Evaluation processes within the federated approach will provide the
ability to verify that capabilities are being fielded in accordance with (IAW) the GIG
Architecture.
There are challenges related to institutionalizing architecture into DoD core processes.
Challenge 1: There is no comprehensive architectural description of the DoD Enterprise
and its relationship between and among the entities that make up the enterprise that can be used
to support department-level decision making.
Challenge 2: Architectures are currently developed independently by many organizations
across DoD conforming to multiple frameworks. They are maintained in independent
repositories, and we assume this mode of operation will continue. This situation, however, raises
several concerns for architects and architecture end-users, specifically that there is no:

148
149
150
151
152
153
154
155


Capability to globally search, vertically or horizontally, for architectures
and/or artifacts3 that may be relevant for analysis, reference, or reuse
Consistent set of standards for architecture configuration management that
would enable users to determine the development status, quality, and authority
of data in various architectures and/or artifacts
Standard methodology for specifying linkages between architectures
developed using different tools and maintained in independent repositories
required to provide enterprise-wide context and understanding
See Appendix B for a definition of “artifact.” Examples include: graphical models, structured models, tabular data,
and structured or unstructured narratives. Individual artifacts may be aggregated.
3
2
81921640
DRAFT
DRAFT
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198

Architecture alignment through linking will require standardization of
vocabularies and taxonomies. The lack of these standards will impede the
level to which an individual architecture artifact may be federated. This work
is currently being addressed with such efforts as Consolidated Operational
Activities List (COAL), and Consolidated Systems Function List (CSFL) and
Joint Command, Control, and Consultation Information Exchange Data Model
(JC3IEDM).
Based on these challenges, DoD needs to provide an enterprise wide architecture
environment that will:
1. Improve the users’ ability to share information on architecture content.
2. Enable rapid access to actionable information to support strategic decisions;
and
3. Increase agility to address unforeseen requirements supporting warfighting
needs.
In the March 2005 National Defense Strategy, the DoD restated its commitment to
making operations net-centric. The foundation for net-centric operations is to give users the
ability to access the information and applications where and when needed. The key enabler of
this ability is the DoD GIG. To move the GIG from Net-Centric concept to Net-Centric reality,
the OASD(NII)/DoD Chief Information Officer (CIO) has established the following goals:


Make information available on a network that people depend on and trust.
Populate the network with new, dynamic sources of information to defeat the
enemy.
The DoD Net-Centric Data Strategy, May 2003, addressed the challenges of finding and
using information on the GIG. The Data Strategy defined a vision in which information is easily
made visible, accessible, and understandable. The draft GIG Enterprise Services Strategy
espouses a dual path approach to achieving these goals. It advocates that DoD Components—
Combatant Commands, Services, and Agencies (C/S/As)—continue to provide and consume
services and embrace service-oriented architecture (SOA) principles (see Appendix B). In
parallel, the GIG Enterprise Services Strategy drives the enterprise to identify and adopt the
necessary services, standards, policies, and processes to federate C/S/As services and SOAs for
the benefit of the Department and its partners.
This DoD EA Federation Strategy and associated EA Services apply the net-centric
concept, Data Strategy, and GIG Enterprise Services Strategy to the DoD Enterprise architecture.
A net-centric approach to Federated EA ensures that the Department has an accessible Enterprise
Architecture with content derived from multiple sources. The intent of this Strategy is to enable
cross-departmental discovery and use of architecture artifacts to support the Department’s
decision makers in evolving and maintaining the enterprise information technology (IT)
infrastructure in accordance with law and policy while maintaining autonomy for the owners of
the architecture artifacts.
3
81921640
DRAFT
DRAFT
1.3.
Related Guidance
199
200
201
202
203
204
205
Architecture requirements are solidly grounded in Law; the Clinger-Cohen Act assigned
CIOs the responsibility for “developing, maintaining, and facilitating the implementation of a
sound and integrated information technology architecture.” Additional details are provided in
the Office of Management and Budget Circular A-130 and are expanded upon in guidance from
the DoD and the Joint Staff (JS) regarding the development and use of architectures and their
relationship to net-centric operations. Full details are provided in Appendix D of this Strategy.
206
2. Purpose
207
208
209
210
211
212
213
214
215
The purpose of this Strategy is to present an agreed upon method and strategy to achieve a
DoD Federated EA that would support decision makers in the DoD at the department level as
well as the DOD Components and Programs.
216
217
218
219
3. Vision
220
221
222
223
4. Goals
224
225
226
227
228
229
230
231
232
233
234
235
236
After months of study, OASD, with participation from the JS and DoD Components, has
determined that the best way to address the challenges presented above is to federate disparate
architectures into a DoD-wide Federated EA. The DoD Federated EA would be constructed
using a set of federation standards and Core Enterprise EA Services (registration, discovery, and
translation services).
The Federated EA vision is to provide DoD decision makers and their staffs’ access to a
broader and deeper architecture data set that is available, accessible, understandable, trustworthy,
and able to be tailored for decision support at the department and DoD Component levels.
The challenges identified in the Background paragraph serve as the drivers for this
Strategy. Their resolution can be found in the following goals necessary to achieve EA
Federation:
1) An environment to support the decision makers and their staffs with access to a
set of common architecture artifacts enabling common understanding of the
DoD Enterprise that can be used to support DoD decision making at the
enterprise and DoD Component levels
2) A means to identify internal and external interfaces to the DoD Enterprise
3) Improved EA information sharing of architectural content, ensuring that users,
including unintended users, can find and use the right information
4) Increased agility that leverages existing architecture and/or artifacts to swiftly
adjust or expand their capabilities through architecture reuse and integration to
meet their changing mission and business needs
5. Objectives
The following five objectives provide the focus for achieving the Goals identified above.
Achievement of all is critical for success.
4
81921640
DRAFT
DRAFT
237
238
239
A.
Provide a structure for federating architectures to achieve the DoD EA and to
establish a means for autonomous development of DoD Component’s EA to support
tiered accountability. Related Goals: 1, 2, 3
240
241
242
243
B.
Provide guidance for federating architectures to achieve the DoD Federated EA and
to establish a means to allow each DoD Component to build its Architecture within
the guidance given by the Enterprise to support tiered accountability. Related Goals:
1, 2, 4
244
245
246
247
248
C.
Align DoD Component EA within a common framework of semantic
understanding .This common framework is based on the use of taxonomies from the
C/S/As and aligned with the Department level taxonomies to ensure that the DoD
Components can achieve standardization and semantic understanding with DoD
Component’s EAs. Related Goal: 1
249
250
251
252
253
D.
Leverage Core Enterprise EA Services to provide Architecture Registration and
Discovery Services that are available, accessible, and usable by consumers within the
enterprise to share architecture information both vertically and horizontally
throughout and achieve information visibility in a coherent manner. Related Goals:
1,3,4
254
255
256
257
258
259
260
E.
Provide a foundation to support emerging capabilities through Federated EA
services as a way of making the underlying business, mission, or transaction function
in a system or application available to a broad set of consumers. These services can
be easily reused and repurposed to provide building blocks for new capabilities. An
example of these services would be to provide specific analytic capabilities
leveraging EA holdings to support logistics, blue force tracking, and mission
planning. Related Goal: 3, 4
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
6. Benefits
There are many benefits to be realized from implementing a Federated EA. The
implementation of the Federated EA is intended to provide useful analytical information to
various stakeholders within the DoD. Multiple benefits accrue as the DoD GIG is federated and
progressively populated with widely sharable information and capabilities, which significantly
boost operational efficiency and effectiveness. This section will identify many of the reasons and
benefits and give a simple description or example of how they are used. These benefits are
dependent on the degree and nature of the content provided by program and DoD Component
architectures.
6.1.
Benefits to DoD Decision Makers
Enables Rapid Access to Information for Strategic Decisions:
Access to actionable, relevant, decision quality, architecture information will accelerate the
leaders’ ability to make better decisions that impact the enterprise (e.g., human resource
capabilities; condition, status, and location of assets; and how funds are invested for the
warfighting mission). The ability of the Federated EA to support these types of decisions is
content dependent.
5
81921640
DRAFT
DRAFT
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
Improves Information Sharing of Architecture Content:
Populating the GIG with federated architecture products and leveraging Core Enterprise
Services to provide EA discovery and search services ensures that architecture information can
be accessed throughout the enterprise. Any user who has access to the GIG will be able to find
and use information from any Web-enabled device.
Understanding of Interactions and Interdependencies:
One of the primary uses of federation is to allow an Enterprise to understand the
interactions and interdependencies among its component parts. DoD needs to understand the
interactions among its major elements, the DoD Components, with the means to govern and
manage the Department “cross-functionally” to realize a cost-effective, Net-Centric GIG. The
Department recognizes that the exchanges among the domains are vital to modernizing the
enterprise. By understanding the minimum set of exchanges required, the enterprise can reduce
or eliminate unnecessary processes and the resources required to support those unnecessary
processes.
Supports Portfolio Management of Technology Options:
The Federated EA depicts the supporting technology and implementation as defined by the
program and DoD Component’s architectures, for each activity within the enterprise. By
evaluating the set of technologies across the Federated EA, the analyst or portfolio manager can
gain an understanding of multiple uses of the same technology and multiple technologies applied
to support the same type of activities.
Supports the Joint Warfighting Capability of the DoD:
Joint military requirements are driving the need for greater commonality and integration of
mission operations across the Department. The Department’s infrastructure must enable rapid
response to the warfighting community and be compatible with the global, networked military it
supports.
Reduced Cost of Defense Operations:
Streamlining operations using Operational Architecture View data will enable decision
makers to deal with growing pressures on resources and ensure every Defense dollar is optimally
applied for long-term mission effectiveness.
6.2.
Benefits to DoD Architects
Promotes Distributed Configuration Management:
Once the enterprise has federated its architecture, configuration management is reduced to
two efforts: maintenance of the federation and configuration of enterprise artifacts. As part of
the centralized control and decentralized execution of developing the enterprise architecture, the
enterprise can very tightly manage the high-level taxonomies, the relationships with the DoD
Component’s activities, and the enterprise list of instances for each.
Provides Clear “stopping” rules for Enterprise Architecture Development:
When developing enterprise architectures, the greatest mistake comes from overstepping
the scope of the department level description. No architect should ever develop details that are
6
81921640
DRAFT
DRAFT
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
clearly in the purview of a lower-level tier. For example, the department level does not have the
authority or expertise to develop the details as well as the DoD Components. Once the
relationship is established between high-level taxonomies and a DoD Component’s architecture
artifact, the department level should then cease its examination of details and point to the DoD
Components. The DoD Component maintains the responsibility and authority to detail the
artifact and define how the enterprise achieves the goal.
Increases Agility:
This benefit is the natural result of the use of Web-based services for registration and
discovery, which are modular, reusable, interoperable building blocks. Users can search the
Federated EA Registry and find existing architecture content, significantly reducing the time and
cost for new architecture development, fielding of a new capability, and gaining improved
interoperability “out of the box.” By using these building blocks, warfighters can swiftly adjust
their architectures to meet changing business and mission needs.
6.3.
Benefits to Architectural Governance Bodies
Sets Enterprise Boundaries:
A Federated EA with activity-based alignment shows each DoD Component’s activities
and how they relate to achieving the enterprise’s goals. The relationships among the activities
identify the activities that are “owned” or performed uniquely and those that are shared by one or
more of the DoD Components. Once all the activities of the Enterprise are related to the
activities of the DoD Components, then the collection of all activities owned by a single DoD
Component sets boundaries throughout the Enterprise. Boundaries are vertical and horizontal
start and stop points for accountability in the roles and responsibilities for Federated EA’s.
Promotes Autonomy or Self-Governance:
A federated architecture supports a governance structure that defines the responsibility and
authority among Components to achieve and support enterprise-wide goals. Once a DoD
Component accepts its defined boundary, as depicted within the federated architecture, it enjoys
autonomous control of the development and analysis of its architecture. The DoD Components
determine the breadth and depth of detail relating to their individual architecture, and produce
and archive the artifacts, as required, to meet or support the goals of the enterprise.
7. Guiding Principles
In an effort to gain the most re-use out of existing architecture artifacts, and to minimize
the need for additional architecture development, the development of the DoD EA Federation is
guided by the principles below. The Federated EA will:
360
361
362

Respect the diverse requirements of individual DoD Component while focusing
on the associations that cut across organizational boundaries IAW statutory
roles and responsibilities for the DoD Components.
363
364

Focus on federating existing disparate architecture artifacts regardless of
structure and format – not re-building architectures.
365

Maximize the reuse of existing architectures at all tiers.
7
81921640
DRAFT
DRAFT
366
367
368

Evolve from a product-centric approach (focused on DoDAF and other work
products produced by architecture developers) towards a data-centric
architecture approach focusing on common semantics.
369
370

Support DoD’s net-centricity objectives (e.g., make information and services
visible, accessible, and understandable) and vision.
371
372
373
374
375
376
377
378
379
380
381
8. Scope
This Strategy encompasses DoD architectures at all levels of detail and classification. It
defines or references interfaces to architectures outside the Department under the Federal
Enterprise Architecture Framework (FEAF) and the Federal Enterprise Architecture Reference
Models.4 The GIG, a Federated EA, will not be isolated to IT but will have relevance for
Doctrine, Organization, Training, Material, Leadership and education, Personnel, and Facilities
(DOTMLPF), as the use and utility of architecture expand in those areas.
This Strategy is applicable to all DoD Mission Areas and addresses the relationships among
all levels of enterprise details from the program/initiative level up to the Department level. This
Strategy will:
382

Define architecture federation and integration concepts.
383

Define architecture alignment (linking and mapping) processes.
384
385
386
387
388
389
390
391

Define EA Services for registering and discovery of architecture holdings and
associated metadata.
392
393
394
395
396
397
This Strategy will accommodate the range of architecture formats, methodologies, toolsets,
and levels of abstraction, and will be applicable to multiple decision processes.
As part of this Strategy, Policy, Governance, and Implementation Planning documents will
need to be defined and developed to support the vision and goals of this strategy.
9. Federated EA Defined
We use the term Federated Architecture to represent the concept that architecture artifacts
are related in a meaningful way. Federated Architectures conform to common or shared
architecture standards across autonomous Program, DoD Component, Mission Area enabling
developing/owning entities to maintain diversity and uniqueness, while providing opportunity for
implementing interoperability.5
4
Federal Enterprise Architecture (FEA) Reference Models (RM) - The FEA is a tool used to align the DoD
enterprise Architecture with the rest of the Federal Government’s Components. There are five Reference Models
within the FEA: Performance Reference Model (PRM); Business Reference Model (BRM); System Reference
Model (SRM); Technical Reference Model (TRM); and Data Reference Model (DRM).
PRM – Identifies the performance measures of the enterprise
BRM – Identifies the key activities of the enterprise
SRM – Identifies the primary systems used within the enterprise
TRM – Identifies the approved and emerging standards used within the enterprise
DRM – Identifies the data and information used within the enterprise
5
Adapted from New York State Office for Technology – see definitions
8
81921640
DRAFT
DRAFT
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
A Federated Enterprise Architecture shows how a DoD Component aligns activities,
services, systems, and infrastructure with federation standard taxonomies, providing context.
Initially, EA federation will be based on semantic alignment of each Program, DoD Component,
Mission Area, architecture’s top-level activity with the Enterprise’s top-level taxonomy of
activities called the “High-level Taxonomy.” An example of “High-level Taxonomy” is the
implementation of the BEA activity model which serves as the Business Mission Area’s
(BMA’s) “High-level Taxonomy” for DoD Component alignment. Semantic Alignment will be
based on the context6 of the architectures and the individual activities being related – for DoDAF
architectures this is normally identified in the (OV-5). Semantic alignment of other architectural
elements will be pursued, as needed, to support key decision processes and as other federation
high-level taxonomies are developed.
Federated Architecture shows the allocation of responsibility across the Enterprise. In
contrast, Integrated Architecture shows the interaction of multiple activities to achieve a mission
or goal across the Enterprise.
Federation is a way to organize an enterprise’s body of knowledge (architecture) about its
activities (processes), people, and things within a defined context and current/future
environment. Federation provides the architect-analyst additional means to examine aspects of
the DOTMLPF concepts across organizational boundaries.
419
10. EA Federation Concepts
420
421
422
423
424
10.1. The EA Federation
425
426
427
428
429
430
431
432
433
434
10.2. Tiered Accountability
435
436
Each tier has full authority and responsibility to develop their portion of the EA.
Unfortunately, data between tiers are often unavailable via an accurate, timely, and reliable
This section identifies key concepts that define the Federated Enterprise Architecture
elements. These concepts are important to understanding Federation and how it is most useful in
supporting decision making and Tiered Accountability. These concepts enable Department-wide
producers and consumers to achieve the Goals and Objectives of a Federated EA.
Tiered accountability is distribution of authority and responsibility of an element of the
enterprise architecture to an organization. Through the policy of Tiered Accountability (TA),
DoD addresses the responsibility for producing these EA architecture artifacts. Under TA, DoD
is currently defining and building enterprise-wide capabilities that include data standards,
business rules, enabling systems, and an associated layer of interfaces for Enterprise, Mission
Area, DoD Components, and Programs. Each tier of the enterprise – Department, Mission Area,
DoD Components, and Program – has specific goals, as well as responsibilities to the tiers above
or below them.
6
See definition on page 10.
9
81921640
DRAFT
DRAFT
437
438
method. In order to navigate through these tiers in a coherent way, and achieve information
visibility, accessibility, and responsiveness, an organizing structure is needed.
439
10.3. High-level Taxonomies
440
441
442
443
444
445
446
In the context of the Federated EA, a high-level taxonomy is a structure or model that
spans the enterprise. At the highest level of the enterprise, the DoD Activity High-level
Taxonomy7 sets the context for the alignment of the Mission Areas’ activities and associated
reference models. At the DoD Component level, it is used to categorize and organize the DoD
Component’s architectures to depict boundaries and provide context for federation. For the
Federated EA, the Activity High-level Taxonomy will be the first High-level taxonomy
produced.
447
10.4. Architecture Categorization
448
449
450
451
DoD EA DoD Component’s architectures need to be categorized to facilitate alignment
(mapping and linking), cataloging, navigating and searching disparate architecture in a DoD
registry of holdings, and providing a framework for aligning architectures. This Strategy
identifies four major levels of echelon and taxonomies to be used for categorization Figure x:




452
453
454
455
456
457
Department (OSD, JCS, etc)
DoD Mission Area (Warfighting, Business, DIMA, and EIE Mission Areas)
DoD Component (Army, JFCOM, DLA, etc)
Program (NECC, FCS, etc)
Department
Mission Area
Component
Program
458
459
460
Figure 1 Architecture Levels for Tiered Accountability
461
462
463
Where possible, this should include identifying a common reference language 8 or
model applicable to the mission areas that can be used by all participating architectures. These
7
The Business Reference Model (BRM) is the high-level Federated EA Activity Taxonomy.
As an example, for the BEA Materiel Visibility BEP, the (SFIS) provides a common reference for all DoD
Logistics architectures.
NOTE: This also complies with the guidance in DoD 4140.1-R, Paragraph C1.4.1.1, to use the SCOR processes of
“Plan, Source, Maintain/Make, Deliver, and Return as a framework for developing, improving, and conducting
8
10
81921640
DRAFT
DRAFT
464
465
466
467
468
top level taxonomies should be complemented by other architecture categorization schemes
including Joint Capability Areas (JCAs), Joint Mission Areas (JMAs), Missions, Universal Joint
Task List (UJTL), DoDAF product type, functional area, acquisition program, transformation
architecture, and others, as appropriate. A full description of a proposed categorization scheme
is in Appendix E.
469
10.5. Context
470
471
472
473
474
475
476
477
478
479
480
481
482
483
Context defines the environment of the enterprise architecture. Five basic questions
make up the Context and help to fully define the external environment of the enterprise.
484
485
486
The Context should be defined before the architecture effort is begun and articulated
within the AV-1. The context is part of the architecture’s metadata, which can be used for
discovery, semantic alignment, and contextual comparison with other architecture efforts.
487
10.6. Boundaries for Tiers
488
489
490
Each enterprise tier – Department, Mission Area, DoD Component, and Program – has
specific goals, as well as responsibilities to the tiers above or below them that are used to
determine the level of detail (or abstraction) necessary for their architecture.
491
492
493
494
495
496
497
498
499
500
501
10.7. Semantic Alignment
1) What is the purpose of the architecture effort and what are the questions to
be addressed by this architecture effort?
2) What is the boundary of the enterprise? What is considered inside the
enterprise versus external?
3) What is the scope of the architecture effort, what are the echelons or
organizational levels involved, and what level of detail will be required in
the descriptions?
4) What is the viewpoint of the architecture? From who’s perspective do we
examine the enterprise and write the descriptions (external customer,
supplier, or casual observer; internal role player; or process owner)?
5) What echelons are represented by the architecture?
A key goal of net-centricity is to enable semantic understanding of data so that
interoperability can be achieved between any applications that have the ability to access and
interpret the structural and semantic rules associated with data.
The Federated EA will be based on the semantic alignment of tier level architecture
elements with elements of federation high-level taxonomies. Semantic alignment refers to the
relationship specified between the meanings of taxonomy elements. The semantic relationships
specified between activities will typically include “is equivalent to,” “is part of,” or “is similar
to.” These relationships provide the alignment between the elements of DoD Component’s
materiel management activities to satisfy customer requirements developed collaboratively with the support
providers.”
11
81921640
DRAFT
DRAFT
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
C/S/As architectures and the high-level reference taxonomies that specify the interface points in
the federation for tiered accountability of the Federated EA content.
Through Tiered Accountability, Stakeholders and the DoD Components will retain the
authority to manage their own internal Architecture holdings, consistent with federation
standards or methodologies. However, the federated EA governance body at the appropriate tier
will have responsibility for capturing semantic consistency out of the separate DoD Components
and communities of interest/practice, defining the semantic (meaning) and syntactical (structure)
standards that will provide for consistent usage and meaning. Where possible, external and
industry standards will be considered for incorporation. Specifics on how semantic alignment
can be achieved will be included in the Federated EA Implementation Plan.
11. EA Services — Making the EA Visible, Accessible, and
Understandable
In order to make the EA visible, accessible, and understandable9, EA Services will be
implemented using Web Services, in which specific content and/or functionality is provided by
one user for others, many of whom may be unanticipated by the provider (see Figure 1). The
return on investment in the Federated EA will result from DoD providers continually populating
the Federated EA with architecture data and products that satisfy a variety of anticipated and
unanticipated consumer needs. This will require the following development of standards and
services:
522
523
524

A set of standard metadata will be maintained for all architectures in
confederating repositories and Web service specifications (Web service
definition language [WSDL]) for discovery and registration.
525
526

A registration service will enable cataloging and linking of architectures in
federated repositories.
527
528
529
530

A discovery service will enable users to execute a federated search for
architecture holdings meeting specified search parameters.
The following paragraphs elaborate on those concepts.
531
11.1. Metadata
532
533
534
535
536
537
538
To implement a Federated EA search service, metadata elements must be defined to
capture attributes of artifacts required to support search parameters based on user needs. The
DoD Discovery Metadata Specification (DDMS) V1.3 provides a baseline specification for
architecture discovery metadata. The architecture conceptual model (currently the CADM)
provides additional AV-1 discovery metadata specifications. Several new metadata elements,
defined as “DDMS Plus” metadata, enable configuration management, architecture registration,
and cataloging.
539
540
Data may be stored in any format using relational, object oriented, or hybrid
technologies based on any kind of data model. These principles do, however, require that
9
Visible, Accessible, and Understandable are key Net-Centric concepts from the NCOW RM v1.1 as integrated
from the Net-Centric Strategies.
12
81921640
DRAFT
DRAFT
541
542
543
544
545
agreements be reached within the DoD EA Community of Interest (COI) or Community of
Practice (COP) on the structure and semantics of data elements used for data asset discovery,
linking, exchange, and integration. Metadata elements needed to support the EA user services
described herein are defined and proposed for DoD EA COI/COP acceptance as the standard for
net-centric federated EA services.
546
11.2. Registration
547
548
549
550
551
Federation repositories will capture all architecture metadata for architectures
developed in local environments. Federation repository owners will be responsible for
implementing mechanisms to collect metadata specifics on the implementation of Registration,
including specific metadata requirements, which will be contained in the Federated EA Services
Implementation Plan.
552
11.3. Discovery
553
554
555
556
557
558
The Federated EA will include a federated metadata discovery capability. The intent is
to provide a user-friendly service that enables discovery of architecture metadata available from
federated repositories. Federated repositories are achieved when sources of similar content can
be searched via enterprise services. It will also enable the user to follow links to the source
architectures in the federated repositories. Specifics on the implementation of this tool will be
contained in the Federated EA Services Implementation Guidance Document.
559
560
The following sections address the two primary modes of discovery, registry browsing
and searching.
561
562
Registry Browsing:
563
564
565
566
567
568
569
570
571
Users may browse a catalog of holdings for Federated EA repositories to find artifacts of
interest. Cataloging of repository holdings should enable users to search for artifacts by
navigating categorization taxonomies similar to browsing item categorizations in online
shopping Web sites. Multiple categorizations may apply to any single architecture. Catalog
navigation trees should use standardized category names from “approved” enterprise
taxonomies, when available, and may be extended by domain extensions where needed.
Navigation trees should provide links to detailed metadata on architecture holdings to enable
users to determine potential interest value and include links to the products in source repositories
to enable user access to selected products.
572
573
Searching:
574
575
576
577
An architecture search capability must enable a user to specify a set of criteria for
architecture artifacts of interest. A single search interface using that set of search criteria needs
to be able to reach all architecture data repositories and present a consolidated response to the
user. The consolidated response, at a minimum, should:
578
579
580
581


Provide sufficient metadata on holdings, so that users can ascertain their
relevance.
Provide links to the results, taking the user to the source repository consistent
with the user’s role-based access privileges.
13
81921640
DRAFT
DRAFT
582
583
584
585
586
587
588

Figure 2 illustrates the concept for the proposed Core Enterprise EA Services/DARS
implementation for the DoD Federated EA Services. It illustrates metadata registration and
discovery of architecture content within the federated repositories required to make the enterprise
architecture data visible, accessible, and understandable for the DoD community.
589
590
591
592
593
594
595
596
597
Include all available architecture metadata, including metadata not specified as
search parameters.
Figure 2: Making Architecture Accessible
12. Governance
Since the Federated EA is not a unitary architecture, it will require a governance structure
to provide direction and oversight within the framework of TA and the existing DoD and DoD
Component governance structures. The DoD CIO, or the CIO’s delegate, will serve as the
ultimate chairperson for management of the Federated EA. However, due to the complex
relationships between the architecture producers/developers at various levels, the governance
roles within the Federated EA will vary according to roles within Tiered Accountability.
598
599
1) At the Enterprise or OASD/JS-level, governance will address DoD-wide
Authority, Direction, Guidance, Monitoring, and Affirmation/Remediation.
600
601
602
2) At the Mission Area-level, governance will address Implementation,
Monitoring, and Affirmation/Remediation in response to DoD-wide guidance as
well as Mission Area unique Authority, Direction, and Guidance.
603
604
3) Similarly, the DoD Component-level, governance will address Implementation,
Monitoring, and Affirmation/Remediation in response to DoD-wide guidance
14
81921640
DRAFT
DRAFT
605
606
607
608
609
and Mission Area input, as well as individual DoD Component requirements for
Authority, Direction, and Guidance.
The details for governance will be provided in a separate document, the planned DoD
Federated EA Governance Document. It will address areas such as:
610
611









612









Charter Development/Approval
Roles and Responsibilities
Organizational Framework
Resource Requirements and Responsibilities
Policies
Metrics
Incentives
Data Management
Standards
Services
Quality
Compliance
Maturity Models
Synchronization
Repositories
Security/Access
Accreditation
External Relationships
A tentative outline for Governance is provided in Appendix F.
613
12.1. EA Federation Roles and Responsibilities
614
615
616
617
618
This Federation Strategy is in accordance with DoD 8320.2-G, DoD Guidance for
Implementing Net-Centric Data Sharing by enforcing Tiered Accountability, whereby each tier,
or level, of the federation is responsible for managing its own architectures and data while also
making those architectures and data visible, accessible, and understandable to other members of
the federation. The Federation Strategy seeks to operationalize Tiered Accountability.
619
620
621
622
Each Tier has both internal and external roles and responsibilities that it must perform
to make the Federated EA function as intended. These are presented in Table 1, where external
roles and responsibilities are denoted with a star (*) and internal roles and responsibilities are
denoted with a square (■).
623
Table 1: Roles and Responsibilities for Individual Levels of Federation
624
Department

Impose constraints on federated Mission Areas,
DoD Components, and Programs in order to
achieve cross-federation.
 Add or remove information from the DoD
Federated EA as appropriate via the various
feedback loops outlined in the Implementation
Plan.
 Develop
top-level
taxonomies
and
categorization schemes in order to ensure that
Mission Areas, DoD Components and
 Establish a governance structure for the DoD
EA Federation.
 Develop and maintain the environment in
which the Federated EA is developed and
maintained.
 Create, publish, and administer the high-level
Discovery and Registration Services.
 Store, publish, and maintain federation
mapping “links” to enable traceability through
each tier and across the Department Level.
 Create and manage the DoD EA RMs.
15
81921640
DRAFT
DRAFT
Program architectures
meaningful way.
can
align
in
a
Mission Area

Impose constraints on the DoD Components  Provide configuration management (CM) to
DoD Components’ taxonomies by MA.
and Programs in order to achieve Mission Area

Provide content to taxonomies and
(MA) goals and support interoperability
categorization schemes utilized for the DoD
between mission areas.
Federated EA.
 Develop and maintain MA enterprise
 Report changes in content for DoD EA
architectures and mapping results.
Federation, as necessary.
625
DoD Components and Enterprise Programs

Impose constraints on DoD Components’
Programs in order to achieve the DoD
Components’ goals and support cross-DoD
interoperability.
 Manage its enterprise architecture to support its
mission and vision.
 Propose modifications to the DoD EA to
increase/improve alignment between tiers.
 Develop and maintain theDoD Components’
enterprise architectures.
 Extend high-level taxonomies.
 Implement the discovery services within the
DoD Components’ environments.
 Provide CM to domain taxonomies.
 Use the taxonomies and categorization
schemes provided by the MA levels to map its
architectures to the DoD EA.
 Make the DoD Components’ architecture
and mapping results visible, accessible, and
understandable.
 Adhere to the standards for data sharing
established by the Enterprise and MAs.
 Ensure that the DoD Components’ Program
architectures and mapping results are visible,
accessible, and understandable.
 Support metadata development.
DoD Component Program’s




Maintain Program architecture element names  Map to the taxonomies and categorization
schemes provided by the DoD Components
and definitions.
as appropriate.
Propose modifications to the DoD EA to

Make the Programs’ architecture and mapping
increase/improve alignment between tiers.
results visible, accessible, and understandable.
Develop and maintain the Programs’

Adhere to the standards for data sharing
architecture and mapping results.
established by the Enterprise, MAs, and DoD
Extend high-level taxonomies.
Components.
626
627
628
629
Additional roles and responsibilities will be identified, as required, within the Governance
Document. Detailed roles and responsibilities specific to each level will be outlined in the DoD
EA Federation Implementation Plan.
630
12.2. Information Assurance
631
632
633
634
This Strategy will embrace information assurance concepts and principles and other
DoD guidance, as appropriate. This is to ensure the integrity of the information across the
Federated EA that’s required to support the goals of visibility, accessibility, understandability,
and trustability (through metadata tagging of artifacts).
16
81921640
DRAFT
DRAFT
635
13. Implementing the Federated EA
636
637
As an integral part of this Strategy, a detailed Implementation Plan will be provided as a
separate document.
638
13.1. Pilot Efforts
639
640
641
642
There are two primary areas of interest for Proof-of-Concept (PoC) Pilot efforts. One is
to build and analyze a Federated EA using the DoD High-level Activity Taxonomy, a Mission
Area Taxonomy, and DoD Components’ architecture. The other is to build and demonstrate EA
Services with an initial focusing on Registration and Discovery Services.
643
Enterprise Federation – Federated EA Pilot
644
645
646
The first pilot will build and analyze a Federated EA using the DoD High-level Activity
Taxonomy, Mission Area Taxonomy, and DoD Components’ architecture. OASD(NII) and the
EA Summit are currently evaluating candidates for this pilot.
647
EA Services — The DARS Pilot for Registration and Discovery
648
649
650
651
652
653
654
655
656
For the second pilot – registration and discovery capabilities – EA Registration and
Discovery Services will be implemented initially as Core Enterprise EA Services in DARS and a
selected set of federated repositories. These capabilities will then be federated to other DoD
Components’ repositories, resulting in a more robust department-level capability. Using this
federated capability, a search request on one repository, e.g., DARS, will result in a returned set
of records matching the search criteria and will contain as much of the architecture metadata as is
available from each of the federated repositories having holdings that match the search criteria.
URLs in the reply metadata set will provide links to the source architectures in the federated
repositories.
657
658
659
660
661
An architecture search capability should enable a user to specify a set of criteria for
architecture artifacts of interest. Users should be able to specify specific search criteria in a
search GUI using methods such as pick lists for the allowable values for each of the criteria.
That set of search criteria needs to be propagated to all architecture data repositories. The user
then needs to receive a single consolidated response that:
662
663
664
665
666
667
668
669
670
671
672



Provides consistent metadata from all sources
Provides sufficient metadata to enable the user to ascertain their relevance
Provides links to the sources
Once a user determines which architecture artifacts are of interest, a link associated with
each result will take the user to the source repository. Depending on the security policy of the
source repository, the link may either provide direct access to the selected artifact in the native
repository format or visualization environment, or, in future versions; it may direct the user to a
role subscription service on the native repository for requesting access to the product. User
credentials may also be passed by the search service to the source repository for authentication to
enable automated access based on access roles/privileges associated with the user in the source
repository.
17
81921640
DRAFT
DRAFT
673
14. Critical Success Factors
674
675
676
677
A review of the business and warfighting mission drivers/needs (with respect to their
information needs), at an enterprise, i.e., joint level, reveals the high degree of cooperation and
participation needed for federating the disparate architectures across the entire DoD, including
alignment of external organizations and agencies in support of strategic, joint decision making.
678
679
680
Following is a list of broad categories of candidate Critical Success Factors (CSF) related
to the institutionalizing of a DoD Federated Architecture environment. The broad CSF
categories are:
681
682

Required commitment by OSD, JS, and DoD DoD Components for participation
in the FJAWG,
683
684
685

Adoption and implementation by OSD, JS, and DoD DoD Components for
architecture governance, registration, high-level taxonomies, federation levels,
roles and responsibilities, federation methodologies, etc.
686
687

Selection and successful implementation of a PoC Pilot in order to validate EA
Federation concepts, governance, methods, tools, high-level taxonomies, etc.
688

Linking Business and Warfighting mission drivers/needs.
689
690

Commitment of resources at OSD, JS, and DoD DoD Components to support
federation development and implementation.
691
692
693

Adoption of DARS as the Federated EA Registry.
694
Appendix G contains a detailed list of CSFs within each category.
15. The Way Ahead
695
To begin implementation of this Strategy:
696
697

OSD Leadership, working with the DoD Components and other stakeholders,
will articulate details required for implementation.
698
699

Registry and repository owners will work with the registry pilot lead on
federating discovery services.
700
701

FJAWG as the EA Summit arm will complete the development of the high-level
activity taxonomies.
702
703

The community will define how linkages are managed between the Tiers in the
Federation.
704
705
706

DARS will implement the linkages between the Tiers in accordance with the
community requirements as a community extension to Core Enterprise EA
Services for EA.
707
708

Mission Area Leads will define their high-level taxonomies for inclusion in the
DoD EA Reference Models.
18
81921640
DRAFT
DRAFT
APPENDIX A: ACRONYM LIST
709
710
ACAT
ACCB
BEA
BMA
BRM
BTA
C/S/A
CADM
CCB
CIO
CJCS
CJCSI
CM
COAL
COI
COP
COTS
C/S/As
CSF
CSFL
DARS
DDMS
DIA
DoD
DODD
DODI
DOTMLPF
DRM
EA
EIE
FCB
FEAF
FJAWG
GIG
GOTS
IT
JCA
JC3IEDM
JCS
JMA
JS
81921640
Acquisition Category
Architecture Configuration Control Board
Business Enterprise Architecture
Business Mission Area
Business Reference Model
Business Transformation Area
Command/Service/Agency
Core Architecture Data Model
Configuration Control Board
Chief Information Officer
Chairman of the Joint Chiefs of Staff
CJCS Instruction
Configuration Management
Consolidated Operational Activities List
Community of Interest
Community of Practice
Commercial Off The Shelf
Combatant Commands, Services, and Agencies
Critical Success Factors
Consolidated Systems Function List
DoD Architecture Registry System
DoD Discovery Metadata Specification
Defense Intelligence Agency
Department of Defense
DoD Directive
DoD Instruction
Doctrine, Organization, Training, Material, Leadership and
education, Personnel, and Facilities
Data Reference Model
Enterprise Architecture
Enterprise Information Environment
Functional Control Board
Federal Enterprise Architecture Framework
Federated Joint Architecture Working Group
Global Information Grid
Government Off The Shelf
Information Technology
Joint Capability Area
Joint Consultation Command and Control Information
Exchange Data Model
Joint Chiefs of Staff
Joint Mission Area
Joint Staff
A-1
DRAFT
DRAFT
MA
NCOW
OASD
PoC
PRM
RM
SFIS
SOA
SRM
TA
TRM
UJTL
WSDL
Mission Area
Net Centric Operations and Warfare
Office of the Assistant Secretary of Defense
Proof of Concept
Performance Reference Model
Reference Model
Service Oriented Architecture
System Reference Model
Tiered Accountability
Technical Reference Model
Universal Joint Task List
Web Service Definition Language
711
81921640
A-2
DRAFT
DRAFT
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
APPENDIX B: DEFINITIONS
Architecture:
Architecture is the structure of components, their interrelationships, and the principles and
guidelines governing their design and evolution over time. [CIO Council, A Practical Guide to Federal
Enterprise Architecture, February 2001]
Architecture Integration:
Architecture Integration is the process of consolidating the content of disparate architectures to
support analyses of a broader scope than that possible with any single disparate architecture.
Architecture integration includes the mapping or standardization of terms and definitions across
disparate architectures and the integration results in a set of data and products that support Joint
operations and development efforts. [DoD Federated Joint Architecture Working Group (FJAWG)
recommendation, Dec 2005]
Artifact:
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. [US Department of
Agriculture Office of the CIO, http://www.ocio.usda.gov/e_arch/glossary.html]
High-level (Adj.):
For purposes of this Strategy, the phrase “high-level” is used as an adjective representing the
highest-level structure within an enterprise, mission area, or DoD Components providing context
and guidance for all lower levels. It is used primarily as a modifier to another term “taxonomy”
to represent highest-level structure within an echelon shown above.
Core Enterprise EA Services:
Core Enterprise Services are IT services that provide the foundation for DoD service and data
providers by delivering and managing the underlying capabilities from which communities build
and receive the services they need to meet their business and information processing needs. For
EA, the initial IT services that support the registration and discovery of architectural artifacts,
architectures, or products will be developed. Additional anticipated services include translation
services that ensure artifacts, architectures, or products are understandable between DARS and
other architectural repositories.
Discovery:
The act of locating a machine-processable description of a Web service-related resource that may
have been previously unknown and that meets certain functional criteria. It involves matching a
set of functional and other criteria with a set of resource descriptions. The goal is to find an
appropriate Web service-related resource. [Web Services Glossary, W3C Working Group Note 11 February
2004]
Discovery Service:
A discovery service is a service that enables agents to retrieve Web services-related resource
description. [Web Services Glossary,W3C Working Group Note 11 February 2004]
81921640
B-1
DRAFT
DRAFT
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
Enterprise:
Enterprise is an organization (or cross-organizational entity) supporting a defined business scope
and mission. An enterprise includes interdependent resources (people, organizations, and
technology) that must coordinate their functions and share information in support of a common
mission (or set of related missions). [CIO Council, A Practical Guide to Federal Enterprise Architecture,
February 2001]
Federated Architecture:
Federated architectures define common or shared architecture standards across autonomous
program areas, enabling state government entities to maintain diversity and uniqueness, while
providing interoperability. [New York State Office for Technology http://www.oft.state.ny.us/arcPolicy/policy/
glossary.htm]
An Architecture Federation is a framework for enterprise architecture development, maintenance
and use that links, locates, and aggregates disparate architectures and architecture information.
A federated architecture approach recognizes the uniqueness and specific purpose of disparate
architectures, and allows for their autonomy and local governance, while enabling the enterprise
to benefit from their content. [DoD FJAWG recommendation, Dec 2005]
Federated Architectures: Separate, Distinct, Individual Architectures:
Separate architectures were built under different contexts but may be aligned within an
overarching scope and boundary, viewed from a common point of view, for a common purpose,
and a specified set of questions to be addressed by the resulting federated architecture. [DoD
FJAWG recommendation, Dec 2005]
Services:
A mechanism to enable access to one or more capabilities, where the access is provided using a
prescribed interface and is exercised consistent with constraints and policies as specified by the
service description. [From the GIG Enterprise Services Strategy, Oct 2006]
Service-Oriented Architecture and SOA Principles:
SOA is a paradigm for organizing and utilizing distributed capabilities that may be under the
control of different ownership domains. It represents a collection of services on a network that
communicate with one another. It is any architecture that can be decomposed, on a logical level,
into three categories of components: a service, a provider of the service, and a consumer of the
service. SOA addresses three roles and three operations. The three roles are the service producer
(provider), the service consumer (requester), and the service registry The objects acted upon are
the service and the service description, and the operations performed on these objects are
publish, find, and bind. Within industry and DoD the concept and service principles are evolving
as we gain experience with SOA. Some general service-oriented principals are: discoverable,
accessible, and dynamically bound; enable interoperability; are loosely coupled; have a network
addressable interface; are location transparent; and are not bound to specific systems. [NCOW RM
v1.2 (draft)]
81921640
B-2
DRAFT
DRAFT
805
806
807
808
809
810
811
Service Registry or Registry Service:
Is a platform neutral, network based directory that stores information about services and is
searchable based on the descriptive metadata defined in the service specification. [DoDAF Version
1.5 Vol 2 Oct 2006]
81921640
B-3
DRAFT
DRAFT
812
813
814
815
816
817
818
819
820
821
822
823
824
APPENDIX C: REFERENCE DOCUMENTS
A Practical Guide to Federal Enterprise Architecture, CIO Council, February 2001.
BMA – Federation Strategy and Roadmap [Working Draft], Business Transformation Agency,
28 August 2006.
Concepts of Enterprise Architecture: Federating Components of an Enterprise Architecture,
Draft MITRE Corporation Paper for SAF/XCXA, 6 September 2006.
Department of Defense Chief Information Officer Memorandum, "DoD Net-Centric Data
Strategy," May 9, 2003.
825
826
827
828
DoD Architecture Framework, Version 1.0, 9 February 2004.
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
DoD Federated Joint Architecture Working Group (FJAWG) Internal Working Papers,
December 2005-Present.
DoD Directive 8100.1, "Global Information Grid (GIG) Overarching Policy," September 19,
2002.
DoD Net Centric Spectrum Management Strategy, OASD (NII), 25 April 2005.
Federated Architectures, Enterprise Integration Inc., 2005.
Global Information Grid Enterprise Services Strategy, Working Draft, OASD(NII) CIO, Oct
2006.
http://www.ocio.usda.gov/e_arch/glossary.html, U.S. Department of Agriculture Office of the
CIO.
http://www.oft.state.ny.us/arcPolicy/policy/glossary.htm,
Technology.
New
York
State
Office
for
National Defense Strategy of the United States of America, March 2005.
The “Net-Centric Operations and Warfare Reference Model, OASD (NII)”, 17 Nov 2005.
“Joint Concept of Operations for Global Information Grid NETOPS version 2.0”,
USSTRATCOM, 10 Aug 2005
81921640
C-1
DRAFT
DRAFT
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
APPENDIX D: RELATED GUIDANCE
Architecture requirements are solidly grounded in Law; the Clinger-Cohen Act assigned
Chief Information Officers the responsibility for “developing, maintaining, and facilitating the
implementation of a sound and integrated information technology architecture.” Additional
details are provided in Office of Management and Budget Circular A-130. The Circular
establishes an Enterprise Architecture (replacing the term “information technology architecture”)
as consisting of the following elements: business processes, information flows, data
descriptions, applications, technology infrastructure, and standards. The Circular also establishes
the requirement for the EA to be incorporated in the Executive Agency’s Capital Planning and
Investment Control Process.
DoD prescribes the DoDAF version 1.0 (DoDAF) as the basis for DoD developing
architecture descriptions. DoDAF-based architecture descriptions are required in many of the
Department’s major processes; these descriptions are also required to be consistent with the GIG
Architecture and NCOW RM. The following policies require the development of architecture
descriptions:


869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
These policies are enforced through processes that include assessments of compliance with
applicable architectures. DoDI 5000.2, for example, includes requirements for Clinger-Cohen
Compliance. One of the compliance criteria requires that acquisitions are “consistent with the
Global Information Grid policies and architecture, to include relevant standards.” The DoD CIO
as well as the DoD Component CIO’s assess lower Acquisition Category (ACAT) programs.
887
888
889
890
The development of a DoD Federated EA will be conducted in accordance with both DoD
and Federal policy on the development and use of Enterprise Architectures. The approach to
federation described herein shall closely follow DoD policy and directives on net-centric data
management. The following net-centric references are applicable:
891







CJCSI 3170.01E, Joint Capabilities Integration and Development System
CJCSI 6212.01D, Interoperability and Supportability of Information
Technology and National Security Systems
DoDD 5000.1, The Defense Acquisition System
DoDI 5000.2, Operation of the Defense Acquisition System
DoDD 4630.5, Interoperability and Supportability of Information Technology
and National Security Systems
DoDI 4630.8, Procedures for Interoperability and Supportability of Information
Technology and National Security Systems
DoDD 8000.1, Management of DoD Information Resources and Information
Technology
DoDD 8115.1, Information Technology Portfolio Management
DoD CIO Memorandum, DoD Net-Centric Data Strategies:
–
–
–
892
893
894
81921640
Net-Centric Data
Shared Services
Information Assurance
D-1
DRAFT
DRAFT
–
–
–
895
896
897
Spectrum
Networking
Computing Infrastructure
898

DoD Directive 8320.2, Data Sharing in a Net-Centric Department of Defense
899

Federal Enterprise Architecture Program, EA Assessment Framework 2.0
900

Federal Enterprise Architecture Program, Data Reference Model 2.0
901
902
903
904
905
906
907
908
909
910
Key net-centric principles that must be adhered to are that data assets must be made visible,
accessible, understandable, and trusted (when referring to IA), and they must be enabled to
support interoperability. These principles do not assume or prescribe any requirements for
physical data storage. Data may be stored in any format using relational, object oriented, or
hybrid technologies based on any kind of data model. These principles do, however, require that
agreements be reached within the DoD EA Community of Interest (COI) or Community of
Practice (COP) on the structure and semantics of data elements used for data asset discovery,
linking, exchange, and integration. Metadata elements needed to support the EA user services
described herein are defined and proposed for DoD EA COI/COP acceptance as the standard for
net-centric federated EA services.
81921640
D-2
DRAFT
DRAFT
APPENDIX E: ARCHITECTURE CATEGORIZATION,
STRUCTURE (TAXONOMY)
911
912
913
914
915
916
The top level of the DoD Federated EA taxonomy will initially consist of the four DoD
Business Reference Model (BRM) Mission Areas (MAs) [see Figure E-1] and be coordinated by
a federated DoD EA control board.
917
Federated DoD EA Control Board
Warfighter
MA
Business
MA
Intel
MA
EIEEIE
MA
MA
Managed by
MA Authority
Service
Agency
COCOM
Subordinate architectures
mapped to MA-level by Components
918
919
Figure E-1: Federated DoD EA Taxonomy
920
921
922
923
Table E-1 identifies MA Taxonomy Configuration Management (CM) Authorities that will
have autonomy for defining and managing a core set of taxonomy elements for each MA.
Mission area taxonomies should be derived from MA activity decomposition and synchronized
with the DoD BRM.
924
Table E-1: Federated DoD and MA Taxonomy CM Authority
Warfighting
Taxonomy Content
CM Authority
JS
FCBs/JCAs
Business
Intelligence
Enterprise Information Environment
BTA
DIA
DoD CIO
BEA (TBD)
DoD BRM for Intel
DoD BRM for EIE
BRM Mission Area
925
926
927
928
Decomposition Basis
The number of High-level taxonomy tiers defined and managed, as a core set will depend
on the degree to which the MA Taxonomy CM Authority wishes to exercise CM control over the
taxonomy structure. Decomposition levels below the MA core structure will be defined by DoD
Components, as authorized by the MA Taxonomy CM Authority. Each EA DoD Components’
81921640
E-1
DRAFT
DRAFT
929
930
931
932
architecture developer will classify its architectures in the DoD Architecture Registry System
(DARS) by associating DoD Components’ architectures with nodes of the MA core or authorized
DoD Component extensions to the core by registering Taxonomy Node and Association Type
metadata.
933
934
935
The Federated Joint Architecture Working Group (FJAWG) has already developed several
assessments and recommendations in regard to taxonomy, which are provided here for reference,
pending establishment of the formal structure for their implementation:
936
937
938
939
1. Mission Area Taxonomy CM Authorities must accept responsibility for defining
and managing MA core upper tier taxonomy nodes. Therefore, the EA summit
should adopt and promulgate the recommended EA High-level Taxonomy
strategy.
940
941
942
943
944
945
946
947
2. DoD Components will have autonomy in developing domain taxonomies.
However, domain architecture mappings and extensions to the MA core must be
regulated to minimize categorization redundancies. Therefore:
a. MA authorities should provide guidance on developing and mapping
domain extensions to the MA core, to include approval and mapping of
“authoritative” extensions.
b. The FJAWG should recommend guidance to MA authorities on regulating
DoD Component domain extensions and mappings to the MA core.
948
949
950
951
952
953
954
955
956
957
958
3. MA core taxonomies need to be coordinated to maximize uniqueness of toplevel nodes and minimize potential categorization redundancy; and business
analysis needs may drive requirements for additional taxonomies to be
incorporated into the MA high-level taxonomy in the future. Therefore, a
Federated EA high-level taxonomy configuration control function and
governance should be established above the individual MAs for regulating the
high-level taxonomy structure and coordinating/de-conflicting the MAtaxonomy top-level nodes. Governance authority should be assigned to the
DoD Architecture Configuration Control Board (ACCB).
Execution
responsibility should be assigned to the FJAWG as the technical advisor to the
ACCB.
959
960
961
Changes in the MA core taxonomies will impact alignments in the registry and should be
managed. Therefore, MA Authorities should develop and implement a core taxonomy CM
process subject to ACCB approval.
81921640
E-2
DRAFT
DRAFT
962
963
APPENDIX F: DOD FEDERATED EA GOVERNANCE
DOCUMENT
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
Draft Governance Outline
Scope
Governance Framework
OASD/JS Level
 Authority
o Charter Development/Approval
o Organizational Framework
 Governance Bodies
 Voting Members
 Stakeholder Participation
o Roles and Responsibilities
o Resource Requirements and Responsibilities
 Guidance
o Policies
o Synchronization
o Security/Access
 Accreditation of content
 Accreditation of members
 Access control and privileges
o External Relationships
 Direction
o Standards
 Tools
 Metadata
o Quality
o Maturity Models
o Repositories
o Registries
o Data Management
o Services
o Configuration Management
 Monitoring
o Metrics
o Compliance
 Affirmation/Remediation
Mission Area and DoD Component Levels
 Implementation Responsibilities
 Monitoring Responsibilities
 Affirmation/Remediation Responsibilities
81921640
F-1
DRAFT
DRAFT
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
APPENDIX G: A DETAILED LIST OF CRITICAL SUCCESS
FACTORS (CSF) BY CSF CATEGORY
 Commitment by DoD DoD Components to:
o Actively participate in FJAWG effort
o Maintain DoD Components -level architecture metadata
o Be willing to participate in and support EA Federation PoC Pilot efforts
o Organizations external to DoD that need to assist or provide access to information for
identifying external architecture interface needs
 Adoption and implementation by DoD DoD Components of the following:
o Federated EA registration and discovery services
o Architecture federation rules
o Federated EA metadata standards
o Recommended Federation structure
o EA Federation roles and responsibilities
o Proposed high-level taxonomies
o Standard methodologies for aligning and linking architectures
o Architecture categorization schemes
o Architecture federation governance
 Proof-of-Concept Pilot is needed to validate the following:
o Applicability & effectiveness of proposed high-level taxonomies
o Architecture configuration management
o Architecture discovery capabilities and performance requirements are satisfied
o Architecture governance at the all levels ensures integrity, visibility, accessibility,
availability, understandability, and usability of architecture data by business/mission
users
o Architecture metadata at DoD Components level satisfies business/Mission Area
information discovery needs
o Architecture navigation and discovery provides correct architecture content
o Architecture registration and discovery capabilities and performance requirements are
satisfied
o Capability to discover (and acquire) architecture content via navigation, search, and
browsing services
o Capability to provide and search on user-defined search criteria
o Categorization schemes are effective in serving business and MA information
discovery needs
o Correctness of rules for federating architectures across the DoD
o Discovery capabilities meet unanticipated user needs
o Effectiveness and efficiency of architecture navigation schemes
o Effectiveness and efficiency of registration service
o Guidance for federation structure
o Key interface points for linking architectures are the correct ones
o Linkage to architectures external to the DoD EA Federation
81921640
G-1
DRAFT
DRAFT
o Linkages are established, on different platforms, with independent repositories within
the federation
o Viability and effectiveness of implemented EA Federation roles and responsibilities
framework
o Viability of accommodating various formats and toolsets
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093

Linking Business and Warfighting mission drivers/needs:
o Alignment of operational activities
o Identifying a “common scenario” applicable to the business or warfighting missions
o Supporting IT enablers for the operational activities
 Resources at DoD Components and EA Federation levels must be available to:
o Participate in and support the PoC Pilot efforts
o Aid in identifying all architecture formats and toolsets in use
o Identify interface needs
o Assist in identifying architecture interface points
o Develop and governance structure at DoD Enterprise and DoD Component levels
o Develop and update architecture metadata at DoD Component level
o Develop and update links to architecture content at the DoD Component level
o Map Mission Areas to each other
o Assist in DoD Component repository federation effort
 Adoption of DARS as the Federated EA Registry for Architecture - DARS must be:
o Accessible and available across entire DoD
o Intuitive, user-friendly, fast, responsive, and timely for architecture registration and
discovery
 EA Federation Tools performance requirements involve the following:
o Automated mapping and linking of architecture content
o Applications that must have timely response times
o Must be user-friendly, intuitive, fast online response
o Interfaces that must be developed to accommodate all architecture formats and
toolsets for architecture registration and discovery
 Knowledge and/or skills in:
o Architectures external to the DoD that need to be interfaced with the Federated EA
o DoD technology infrastructure
o Existing disparate architectures across the DoD
o Technologies and tools to provide linking to architecture content
o Web technology
o Metadata standards that need to be implemented
o Architecture formats, methodologies, and toolsets
o Prospective current and future types of unanticipated users of Federated EA
o Types of architecture artifacts needed by unanticipated users
81921640
G-2
DRAFT
DRAFT
APPENDIX H: ACTIVITY-BASED EA FEDERATION
ALIGNMENT
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
Activity-Relationship-Activity:
Federating the architecture in an enterprise requires a high-level taxonomy (under
development) of the enterprise and an activity model for each DoD Componentof interest in the
enterprise. The activities within the high-level taxonomy and DoD Components’ activity models
will be related in one of the following four ways as illustrated in Figure H-1 below.




Equivalent to
Similar to
Part of
No relationship
Federated Architecture Relationships
High-level Activity Taxonomy
…
…
FM
IL
Is Equivalent to
AFMC
Is Equivalent
Is Similar toto
Is Part of
1108
1109
Figure H-1. Federation Relationships Among Activities
1110
1111
A DoD Components’ activity is considered “equivalent to” a high-level activity if the
descriptions and artifacts of both are identical.
1112
1113
1114
1115
1116
A DoD Components’ activity is considered “similar to” a high-level activity if the
descriptions are the same but the primitives differ in some specification between the enterprise
design and the DoD Components implementation, the activity is done differently by two or more
DoD Components, or two or more DoD Components accomplish the same activity with different
primitive specifications.
1117
1118
A DoD Components’ activity is considered “part of” a high-level activity if the description
of the DoD Components’ activity achieves part of the high-level activity’s goal, and another
81921640
H-1
DRAFT
DRAFT
1119
1120
DoD Components’ activity that also has a “part of” relationship with the same high-level activity
completes the goal.
1121
1122
If a DoD Components’ activity has no relationship with any of the high-level activities,
then no relationship is shown.
1123
1124
1125
Relationships between the high-level and DoD Components’ activities can occur at any
level of decomposition.
81921640
H-2
DRAFT