Department of DefenseEnterprise Architecture Federation Strategy

spongereasonInternet and Web Development

Nov 12, 2013 (3 years and 7 months ago)

189 views

DRAFT

spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

DRAFT


1


2

Department of Defense

3

Enterprise Architecture Federation Strategy

4


5


6


7


8


9


10


11


12


13


14

Draft Version 1.01

15

04 December 2006

16


17


18

Prepared by the DoD CIO

19

20

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

ii

DRAFT

TABLE OF CONTENTS

21


22

1.

Introduction

................................
................................
................................
............

1

23

1.1.

Intended Audience

................................
................................
..........................

2

24

1.2.

Background

................................
................................
................................
.....

2

25

1.3.

Related Guidance

................................
................................
............................

4

26

2.

Purpose

................................
................................
................................
...................

4

27

3.

Vision

................................
................................
................................
......................

4

28

4.

Goals

................................
................................
................................
.......................

4

29

5.

Objectives

................................
................................
................................
...............

4

30

6.

Benefits

................................
................................
................................
...................

5

31

6.1.

Benefits to DoD Decision Makers

................................
................................
..

5

32

6.2.

Benefits to DoD Architects

................................
................................
.............

6

33

6.3.

Benefits to Architectural Governance Bodies

................................
..............

7

34

7.

Guiding Princip
les

................................
................................
................................
.

7

35

8.

Scope

................................
................................
................................
......................

8

36

9.

Federated EA Defined

................................
................................
............................

8

37

10.

EA Federation Con
cepts

................................
................................
....................

9

38

10.1.

The EA Federation

................................
................................
.......................

9

39

10.2.

Tiered Accountability

................................
................................
..................

9

40

10.3.

High
-
level Taxonomies

................................
................................
.............

10

41

10.4.

Architecture Categorization

................................
................................
.....

10

42

10.5.

Context

................................
................................
................................
.......

11

43

10.6.

Boundaries for Tiers

................................
................................
.................

11

44

10.7.

Semantic Alignment

................................
................................
..................

11

45

11.

EA Services


Making the EA Visible, Accessib
le, and Understandable

...

12

46

11.1.

Metadata

................................
................................
................................
.....

12

47

11.2.

Registration

................................
................................
...............................

13

48

11.3.

Discovery

................................
................................
................................
...

13

49

12.

Governance

................................
................................
................................
.......

14

50

12.1.

EA Federation Roles and Responsibilities

................................
..............

15

51

12.2.

Information Assurance

................................
................................
.............

16

52

13.

Implementing the Federated EA

................................
................................
......

17

53

13.1.

Pilot Efforts

................................
................................
................................

17

54

14.

Critical Success Factors

................................
................................
..................

18

55

15.

The Way Ahead

................................
................................
................................
.

18

56

APPENDIX A: ACRONYM LI
ST

................................
................................
....................

1

57

APPENDIX B: DEFINITIONS

................................
................................
........................

1

58

APPENDIX C: REFERENCE DOCUMENTS

................................
................................
.

1

59

APPENDIX D: RELATED GUIDANCE

................................
................................
..........

1

60

APPENDIX E: ARCHITECTURE CATEGORIZATION, STRUCTURE (TAXONOMY)

..

1

61

APPENDIX F: DOD FEDERATED E
A GOVERNANCE DOCUMENT

...........................

1

62

APPENDIX G: A DETAILED LIST OF CRITICAL SUCCESS FACTORS (CSF) BY
63

CSF CATEGORY

................................
................................
................................
............

1

64

APPENDIX H: ACTIVITY
-
B
ASED EA FEDERATION ALIGNMENT

.............................

1

65


66


67

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

iii

DRAFT

LIST OF FIGURES

68


69

F
IGURE
1:

A
RCHITECTURE
L
EVELS FOR
T
IERED
A
CCOUNTABILITY
…………………………...10

70

F
IGURE
2
:

M
AKING
A
RCHITECTUR
E
A
CCESSIBLE

................................
..............................

14

71

F
IGURE
E
-
1:

F
EDERATED
D
O
D

EA

T
AXONOMY

................................
................................
E
-
1

72

F
IGURE
H
-
1.

F
EDERATION
R
ELATIONSHIPS
A
MONG
A
CTIVITIES

................................
........

H
-
1

73


74


75

LIST OF TABLES

76


77

T
ABLE
1:

R
OLES AND
R
ESPONSIBILITIES FOR
I
NDIVIDUAL
L
EVELS OF
F
EDERATION

.............

15

78

T
ABLE
E
-
1:

F
EDERATED
D
O
D

AND
MA

T
AXONOMY
CM

A
UTHORITY

................................
.
E
-
1

79

80

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

1

DRAFT

1.

Introduction

81

The Department of Defense (DoD) Federated Enterprise Architecture (EA) represents the
82

“next generation” Global Information Grid (GIG) Architecture.

83


84

The current GIG Architecture, along with the

Net
-
Centric Operations and Warfare
85

Reference Model (NCOW RM) is an overarching architecture description of the GIG.
1

86

However, the DoD is too large and complex to be described within a single integrated
87

architecture. Additionally, Enterprise architecture
s have an inherent problem. To fully describe
88

an enterprise, architects must either abstract the content into simple constructs that don’t lend
89

themselves to supporting a broad range of decisions, or they must compile massive amounts of
90

data that make com
prehension difficult at best. One of the primary objectives of enterprise
91

architectures is to describe the enterprise so that decision makers can make informed decisions
92

based on or within a common context. It will result in the development of a cohesive

EA
93

supporting the alignment and integration of architecture efforts in support of DoD business and
94

warfighter strategic goals. Therefore, architects must constantly balance complexity with utility.
95

The DoD GIG Architecture is no different.

96


97

What is req
uired is a rethinking of the GIG architecture concept to effectively leverage
98

current architecture efforts and maintain comprehension while, at the same time, providing DoD
99

decision makers with the information they need. Federating existing architectures
of DoD
100

elements that describe the various echelons (or tiers) is one way to achieve this goal. Federation
101

techniques allow disparate architectures (based on a variety of established frameworks) to be
102

meaningfully related and permit acceleration of new arc
hitecture efforts across the DoD
103

community to support DoD decision makers who require more detailed content that is not
104

reasonable for the department level.

105


106

To date, there have been advancements in both the architecture and stakeholder
107

communities that us
e architecture information. Architecture products, however, are presently not
108

as sufficiently discoverable and accessible as needed to support decision making. Today’s
109

architectures are built for specific purposes and viewpoints; they do not normally refe
r to or
110

relate to each other as they should to gain maximum value from the architecture investment.

111


112

As a remedy, the Department has chosen architecture federation
2

as a new GIG architecture
113

paradigm. The next generation GIG architecture will be construct
ed by federating the separate
114

architecture artifacts throughout the DoD and employ a set of EA Services for registering,
115




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 20
15. 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 o
f the
Enterprise Architecture as defined by OMB for Clinger
-
Cohen comp
l
iance.


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.

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

2

DRAFT

discovering, and utilizing architecture data to support key DoD decision processes by
116

implementing concepts from the DoD Net
-
Centric St
rategies.

117

1.1.

Intended Audience

118

The primary audience for the DoD Federated Enterprise Architecture Strategy Document
119

includes two distinct classes


first, those responsible for implementation of the Federated EA,
120

and second, producers and consumers of archite
cture information, e.g., decision makers, program
121

managers, analysts, operators, architects, and engineers within DoD and external partners in the
122

extended enterprise.

123

1.2.

Background

124

The Director, Office of the Assistant Secretary of Defense for Networks and I
nformation
125

Integration, Architecture & Interoperability (OASD[NII/A&I]) has worked with the Services
126

Chief Architects to define the federated approach. The federated approach will guide the
127

building of the next generation GIG Architecture. This approach
recognizes the need for
128

autonomy but requires linkages and alignment of architectures from the Program level up to the
129

Federal Enterprise level. OASD(NII) will introduce requirements in phases to achieve enterprise
-
130

wide GIG descriptions that move the Depar
tment toward a shared Net
-
Centric Vision and
131

Transition Plan. These requirements are being identified and met through systems engineering
132

processes that leverage architecture descriptions as blueprints. The use of shared architecture
133

descriptions in Test

& Evaluation processes within the federated approach will provide the
134

ability to verify that capabilities are being fielded in accordance with (IAW) the GIG
135

Architecture.

136


137

There are challenges related to institutionalizing architecture into DoD core proce
sses.

138


139

Challenge 1: There is no comprehensive architectural description of the DoD Enterprise
140

and its relationship between and among the entities that make up the enterprise that can be used
141

to support department
-
level decision making.

142


143

Challenge 2: Arch
itectures are currently developed independently by many organizations
144

across DoD conforming to multiple frameworks. They are maintained in independent
145

repositories, and we assume this mode of operation will continue. This situation, however, raises
146

severa
l concerns for architects and architecture end
-
users, specifically that there is no:

147



Capability to globally search, vertically or horizontally, for architectures
148

and/or artifacts
3

that may be relevant for analysis, reference, or reuse

149



Consistent set of
standards for architecture configuration management that
150

would enable users to determine the development status, quality, and authority
151

of data in various architectures and/or artifacts

152



Standard methodology for specifying linkages between architectures
153

d
eveloped using different tools and maintained in independent repositories
154

required to provide enterprise
-
wide context and understanding

155




3

See Appendix B for a definition of “artifact.” Examples include: graphical models, structured models, tabular data,
and structured or unstructured narratives. Individ
ual artifacts may be aggregated.

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

3

DRAFT



Architecture alignment through linking will require standardization of
156

vocabularies and taxonomies. The lack of these
standards will impede the
157

level to which an individual architecture artifact may be federated. This work
158

is currently being addressed with such efforts as Consolidated Operational
159

Activities List (COAL), and Consolidated Systems Function List (CSFL) and
160

Joint Command, Control, and Consultation Information Exchange Data Model
161

(JC3IEDM).

162


163

Based on these challenges, DoD needs to provide an enterprise wide architecture
164

environment that will:

165

1.

Improve the users’ ability to share information on architecture cont
ent.

166

2.

Enable rapid access to actionable information to support strategic decisions;
167

and

168

3.

Increase agility to address unforeseen requirements supporting warfighting
169

needs.

170


171

In the March 2005
National Defense Strategy
, the DoD restated its commitment to
172

ma
king operations net
-
centric. The foundation for net
-
centric operations is to give users the
173

ability to access the information and applications where and when needed. The key enabler of
174

this ability is the DoD GIG. To move the GIG from Net
-
Centric concep
t to Net
-
Centric reality,
175

the OASD(NII)/DoD Chief Information Officer (CIO) has established the following goals:

176



Make information available on a network that people depend on and trust.

177



Populate the network with new, dynamic sources of information to defe
at the
178

enemy.

179


180

The
DoD Net
-
Centric Data Strategy
, May 2003, addressed the challenges of finding and
181

using information on the GIG. The
Data Strategy

defined a vision in which information is easily
182

made visible, accessible, and understandable.
The draft
GI
G Enterprise Services Strategy
183

espouses a dual path approach to achieving these goals. It advocates that DoD Components

184

Combatant Commands, Services, and Agencies (C/S/As)

continue to provide and consume
185

services and embrace service
-
oriented architecture
(SOA) principles (see Appendix B). In
186

parallel, the
GIG Enterprise Services Strategy

drives the enterprise to identify and adopt the
187

necessary services, standards, policies, and processes to federate C/S/As services and SOAs for
188

the benefit of the Depart
ment and its partners.


189


190

This
DoD EA Federation Strategy
and associated EA Services apply the net
-
centric
191

concept, Data Strategy, and GIG Enterprise Services Strategy to the DoD Enterprise architecture.
192

A net
-
centric approach to Federated EA ensures that
the Department has an accessible Enterprise
193

Architecture with content derived from multiple sources. The intent of this Strategy is to enable
194

cross
-
departmental discovery and use of architecture artifacts to support the Department’s
195

decision makers in evo
lving and maintaining the enterprise information technology (IT)
196

infrastructure in accordance with law and policy while maintaining autonomy for the owners of
197

the architecture artifacts.

198

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

4

DRAFT

1.3.

Related Guidance

199

Architecture requirements are solidly grounded in La
w; the Clinger
-
Cohen Act assigned
200

CIOs the responsibility for “developing, maintaining, and facilitating the implementation of a
201

sound and integrated information technology architecture.” Additional details are provided in
202

the Office of Management and Bud
get Circular A
-
130 and are expanded upon in guidance from
203

the DoD and the Joint Staff (JS) regarding the development and use of architectures and their
204

relationship to net
-
centric operations. Full details are provided in Appendix D of this
Strategy.


205

2.

Pur
pose

206

The purpose of this Strategy is to present an agreed upon method and strategy to achieve a
207

DoD Federated EA that would support decision makers in the DoD at the department level as
208

well as the
DOD Component
s and Programs.

209


210

After months of study, OAS
D, with participation from the JS and
DoD Components
, has
211

determined that the best way to address the challenges presented above is to federate disparate
212

architectures into a DoD
-
wide Federated EA. The DoD Federated EA would be constructed
213

using a set of
federation standards and Core Enterprise EA Services (registration, discovery, and
214

translation services).

215

3.

Vision

216

The Federated EA vision is to provide DoD decision makers and their staffs’ access to a
217

broader and deeper architecture data set that is avai
lable, accessible, understandable, trustworthy,
218

and able to be tailored for decision support at the department and
DoD Component

levels.

219

4.

Goals

220

The challenges identified in the
Background

paragraph serve as the drivers for this
221

Strategy. Their resolution c
an be found in the following goals necessary to achieve EA
222

Federation:

223

1)

An environment to support the decision makers and their staffs with access to a
224

set of common architecture artifacts enabling common understanding of the
225

DoD Enterprise that can be used

to support DoD decision making at the
226

enterprise and
DoD Component

levels

227

2)

A means to identify internal and external interfaces to the DoD Enterprise

228

3)

Improved EA information sharing of architectural content, ensuring that users,
229

including unintended users,

can find and use the right information

230

4)

Increased agility that leverages existing architecture and/or artifacts to swiftly
231

adjust or expand their capabilities through architecture reuse and integration to
232

meet their changing mission and business needs

233

5.

Obje
ctives

234

The following five objectives provide the focus for achieving the
Goals

identified above.
235

Achievement of all is critical for success.

236

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

5

DRAFT

A.

Provide a structure

for federating architectures to achieve the DoD EA and to
237

establish a means for autonomous d
evelopment of
DoD Component’
s EA to support
238

tiered accountability. Related Goals:
1, 2, 3

239

B.

Provide guidance

for federating architectures to achieve the DoD Federated EA and
240

to establish a means to allow each
DoD Component

to build its Architecture within

241

the guidance given by the Enterprise to support tiered accountability. Related Goals:
242

1, 2, 4

243

C.

Align
DoD Component

EA within a common framework of semantic
244

understanding .
This common

framework is based on the use of taxonomies from the
245

C/S/As and align
ed with the Department level taxonomies to ensure that the
DoD
246

Component
s can achieve standardization and semantic understanding with
DoD
247

Component’
s EAs. Related Goal: 1

248

D.

Leverage Core Enterprise EA Services to provide Architecture Registration and
249

Disc
overy Services

that are available, accessible, and usable by consumers within the
250

enterprise to share architecture information both

vertically and horizontally
251

throughout and achieve information visibility in a coherent manner.


Related Goals:
252

1,3,4

253

E.

Prov
ide a foundation to support emerging capabilities through Federated EA
254

services

as a way of making the underlying business, mission, or transaction function
255

in a system or application available to a broad set of consumers. These services can
256

be easily reus
ed and repurposed to provide building blocks for new capabilities. An
257

example of these services would be to provide specific analytic capabilities
258

leveraging EA holdings to support logistics, blue force tracking, and mission
259

planning. Related Goal: 3, 4


260

6.

Benefits

261

There are many benefits to be realized from implementing a Federated EA. The
262

implementation of the Federated EA is intended to provide useful analytical information to
263

various stakeholders within the DoD. Multiple benefits accrue as the DoD GI
G is federated and
264

progressively populated with widely sharable information and capabilities, which significantly
265

boost operational efficiency and effectiveness. This section will identify many of the reasons and
266

benefits and give a simple description or e
xample of how they are used. These benefits are
267

dependent on the degree and nature of the content provided by program and
DoD Component

268

architectures.

269

6.1.

Benefits to DoD Decision Makers

270


271

Enables Rapid Access to Information for Strategic Decisions
:


272

Access to

actionable, relevant, decision quality, architecture information will accelerate the
273

leaders’ ability to make better decisions that impact the enterprise (e.g., human resource
274

capabilities; condition, status, and location of assets; and how funds are inve
sted for the
275

warfighting mission). The ability of the Federated EA to support these types of decisions is
276

content dependent.

277


278

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

6

DRAFT

Improves Information Sharing of Architecture Content
:


279

Populating the GIG with federated architecture products and leveraging Co
re Enterprise
280

Services to provide EA discovery and search services ensures that architecture information can
281

be accessed throughout the enterprise. Any user who has access to the GIG will be able to find
282

and use information from any Web
-
enabled device.

283


284

Understanding of Interactions and Interdependencies
:

285

One of the primary uses of federation is to allow an Enterprise to understand the
286

interactions and interdependencies among its component parts. DoD needs to understand the
287

interactions among its major

elements, the
DoD Component
s, with the means to govern and
288

manage the Department “cross
-
functionally” to realize a cost
-
effective, Net
-
Centric GIG. The
289

Department recognizes that the exchanges among the domains are vital to modernizing the
290

enterprise. B
y understanding the minimum set of exchanges required, the enterprise can reduce
291

or eliminate unnecessary processes and the resources required to support those unnecessary
292

processes.

293


294

Supports Portfolio Management of Technology Options
:

295

The Federated EA
depicts the supporting technology and implementation as defined by the
296

program and
DoD Component’
s architectures, for each activity within the enterprise. By
297

evaluating the set of technologies across the Federated EA, the analyst or portfolio manager can
298

gain an understanding of multiple uses of the same technology and multiple technologies applied
299

to support the same type of activities.

300


301

Supports the Joint Warfighting Capability of the DoD
:

302

Joint military requirements are driving the need for greater comm
onality and integration of
303

mission operations across the Department. The Department’s infrastructure must enable rapid
304

response to the warfighting community and be compatible with the global, networked military it
305

supports.

306


307

Reduced Cost of Defense Operati
ons
:

308

Streamlining operations using Operational Architecture View data will enable decision
309

makers to deal with growing pressures on resources and ensure every Defense dollar is optimally
310

applied for long
-
term mission effectiveness.

311

6.2.

Benefits to DoD Architec
ts

312


313

Promotes Distributed Configuration Management
:

314

Once the enterprise has federated its architecture, configuration management is reduced to
315

two efforts: maintenance of the federation and configuration of enterprise artifacts. As part of
316

the centralize
d control and decentralized execution of developing the enterprise architecture, the
317

enterprise can very tightly manage the high
-
level taxonomies, the relationships with the
DoD
318

Component’
s activities, and the enterprise list of instances for each.

319


320

Provi
des Clear “stopping” rules for Enterprise Architecture Development
:

321

When developing enterprise architectures, the greatest mistake comes from overstepping
322

the scope of the department level description. No architect should ever develop details that are
323

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

7

DRAFT

c
learly in the purview of a lower
-
level tier. For example, the department level does not have the
324

authority or expertise to develop the details as well as the
DoD Component
s. Once the
325

relationship is established between high
-
level taxonomies and a
DoD Com
ponent’
s architecture
326

artifact, the department level should then cease its examination of details and point to the
DoD
327

Component
s. The
DoD Component

maintains the responsibility and authority to detail the
328

artifact and define how the enterprise achieves t
he goal.

329


330

Increases Agility
:

331

This benefit is the natural result of the use of Web
-
based services for registration and
332

discovery, which are modular, reusable, interoperable building blocks. Users can search the
333

Federated EA Registry and find existing archi
tecture content, significantly reducing the time and
334

cost for new architecture development, fielding of a new capability, and gaining improved
335

interoperability “out of the box.” By using these building blocks, warfighters can swiftly adjust
336

their architec
tures to meet changing business and mission needs.

337

6.3.

Benefits to Architectural Governance Bodies

338


339

Sets Enterprise Boundaries
:


340

A Federated EA with activity
-
based alignment shows each
DoD Component’
s activities
341

and how they relate to achieving the enterprise
’s goals. The relationships among the activities
342

identify the activities that are “owned” or performed uniquely and those that are shared by one or
343

more of the
DoD Component
s. Once all the activities of the Enterprise are related to the
344

activities of the

DoD Component
s, then the collection of all activities owned by a single
DoD
345

Component
sets boundaries throughout the Enterprise. Boundaries are vertical and horizontal
346

start and stop points for accountability in the roles and responsibilities for Federat
ed EA’s.

347


348

Promotes Autonomy or Self
-
Governance
:

349

A federated architecture supports a governance structure that defines the responsibility and
350

authority among Components to achieve and support enterprise
-
wide goals. Once a
DoD
351

Component

accepts its defin
ed boundary, as depicted within the federated architecture, it enjoys
352

autonomous control of the development and analysis of its architecture. The
DoD Component
s
353

determine the breadth and depth of detail relating to their individual architecture, and produ
ce
354

and archive the artifacts, as required, to meet or support the goals of the enterprise.

355

7.

Guiding Principles

356

In an effort to gain the most re
-
use out of existing architecture artifacts, and to minimize
357

the need for additional architecture development, th
e development of the DoD EA Federation is
358

guided by the principles below.

The Federated EA will:

359



Respect the diverse requirements of individual
DoD Component

while focusing
360

on the associations that cut across organizational boundaries IAW statutory
361

roles a
nd responsibilities for the
DoD Component
s.

362



Focus on federating existing disparate architecture artifacts regardless of
363

structure and format


not re
-
building architectures.

364



Maximize the reuse of existing architectures at all tiers.

365

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

8

DRAFT



Evolve from a product
-
c
entric approach (focused on DoDAF and other work
366

products produced by architecture developers) towards a data
-
centric
367

architecture approach focusing on common semantics.

368



Support DoD’s net
-
centricity objectives (e.g., make information and services
369

visible,
accessible, and understandable) and vision.

370

8.

Scope

371

This Strategy encompasses DoD architectures at all levels of detail and classification. It
372

defines or references interfaces to architectures outside the Department under the Federal
373

Enterprise Architecture

Framework (FEAF) and the Federal Enterprise Architecture Reference
374

Models.
4

The GIG, a Federated EA, will not be isolated to IT but will have relevance for
375

Doctrine, Organization, Training, Material, Leadership and education, Personnel, and Facilities
376

(D
OTMLPF), as the use and utility of architecture expand in those areas.

377


378

This Strategy is a
pplicable to all DoD Mission Areas and addresses the relationships among
379

all levels of enterprise details from the program/initiative level up to the Department lev
el. T
his
380

Strategy will:

381



Define architecture federation and integration concepts.

382



Define architecture alignment (linking and mapping) processes.

383



Define EA Services for registering and discovery of architecture holdings and
384

associated metadata.

385


386

This

Str
ategy will accommodate the range of architecture formats, methodologies, toolsets,
387

and levels of abstraction, and will be applicable to multiple decision processes.

388


389

As part of this Strategy, Policy, Governance, and Implementation Planning documents will

390

need to be defined and developed to support the vision and goals of this strategy.

391

9.

Federated EA Defined

392

We use the term Federated Architecture to represent the concept that architecture artifacts
393

are related in a meaningful way.

Federated Architectures c
onform to common or shared
394

architecture standards across autonomous
P
rogram,
DoD Component, M
ission

Area

enabling
395

developing/owning entities to maintain diversity and uniqueness, while providing opportunity for
396

implementing interoperability.
5

397




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 t
he 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

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

9

DRAFT


398

A Federated
Enterprise Architecture shows how a
DoD Component

aligns activities,
399

services, systems, and infrastructure with federation standard taxonomies, providing context.
400

Initially, EA federation will be based on
semantic

alignment of each
P
rogram
, DoD Component,

401

Mission Area,

architecture’s top
-
level activity with the Enterprise’s top
-
level taxonomy of
402

activities called the “
High
-
level Taxonomy
.” An example of “
High
-
level Taxonomy
” is the
403

implementation of the
BEA

activity model

which
serves as

the Business Miss
ion Area’s
404

(BMA’s) “
High
-
level Taxonomy

for DoD
Component

alignment
.

Semantic

Alignment

will be
405

based on the context
6

of the architectures and the individual activities being related


for DoDAF
406

architectures this is normally identified in the (OV
-
5). S
emantic alignment of other architectural
407

elements will be pursued, as needed, to support key decision processes and as other federation
408

high
-
level taxonomies are developed.

409


410

Federated Architecture shows the allocation of responsibility across the Enterpri
se. In
411

contrast, Integrated Architecture shows the interaction of multiple activities to achieve a mission
412

or goal across the Enterprise.

413


414

Federation is a way to organize an enterprise’s body of knowledge (architecture) about its
415

activities (processes), p
eople, and things within a defined context and current/future
416

environment. Federation provides the architect
-
analyst additional means to examine aspects of
417

the DOTMLPF concepts across organizational boundaries.

418

10.

EA Federation Concepts

419

10.1.

The EA Federation

420

Th
is section identifies key concepts that define the Federated Enterprise Architecture
421

elements. These concepts are important to understanding Federation and how it is most useful in
422

supporting decision making and Tiered Accountability. These concepts enab
le Department
-
wide
423

producers and consumers to achieve the Goals and Objectives of a Federated EA.

424

10.2.

Tiered Accountability

425

Tiered accountability is distribution of authority and responsibility of an element of the
426

enterprise architecture to an organization.
Through the policy of Tiered Accountability (TA),
427

DoD addresses the responsibility for producing these EA architecture artifacts. Under TA, DoD
428

is currently defining and building enterprise
-
wide capabilities that include data standards,
429

business rules, en
abling systems, and an associated layer of interfaces for Enterprise, Mission
430

Area,
DoD Component
s, and Programs. Each tier of the enterprise


Department, Mission Area,
431

DoD Component
s, and Program


has specific goals, as well as responsibilities to the t
iers above
432

or below them.

433


434

Each tier has full authority and responsibility to develop their portion of the EA.
435

Unfortunately, data between tiers are often unavailable via an accurate, timely, and reliable
436




6

See definition on page 10.

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

10

DRAFT

method. In order to navigate through these tiers
in a coherent way, and achieve information
437

visibility, accessibility, and responsiveness, an organizing structure is needed.

438

10.3.

High
-
level Taxonomies

439

In the context of the Federated EA, a high
-
level taxonomy is a structure or model that
440

spans the enterprise.

At the highest level of the enterprise, the DoD
Activity High
-
level

441

Taxonomy
7

sets the context for the alignment of the Mission Areas’ activities and associated
442

reference models. At the
DoD Component

level, it is used to categorize and organize the
DoD
443

C
omponent
’s architectures to depict boundaries and provide context for federation. For the
444

Federated EA, the
Activity High
-
level Taxonomy

will be the
first High
-
level taxonomy

445

produced.

446

10.4.

Architecture Categorization

447

DoD EA
DoD Component’
s architectures nee
d to be categorized to facilitate alignment
448

(mapping and linking), cataloging, navigating and searching disparate architecture in a DoD
449

registry of holdings, and providing a framework for aligning architectures. This Strategy
450

identifies four major levels
of echelon and taxonomies to be used for categorization

Figure x
:

451



Department (OSD, JCS, etc)

452



DoD Mission Area (Warfighting, Business, DIMA, and EIE Mission Areas)

453



DoD Component

(Army, JFCOM, DLA, etc)

454



Program (NECC, FCS, etc)

455


456


457

Component
Program
Mission Area
Department
Component
Program
Mission Area
Department

458


459

Figure 1 Architecture Lev
els for Tiered Accountability

460


461

Where possible, this should include identifying a common reference language
8

or
462

model applicable to the mission areas that can be used by all participating architectures.
These
463




7

The Business Reference Model (BRM) is the high
-
level Federated EA
Activity
Taxonomy.

8

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 co
nducting
DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

11

DRAFT

top level taxonomies should be complemented by o
ther architecture categorization schemes
464

including Joint Capability Areas (JCAs), Joint Mission Areas (JMAs), Missions, Universal Joint
465

Task List (UJTL), DoDAF product type, functional area, acquisition program, transformation
466

architecture, and others, as
appropriate. A full description of a proposed categorization scheme
467

is in Appendix E.

468

10.5.

Context

469

Context defines the environment of the enterprise architecture. Five basic questions
470

make up the Context and help to fully define the external environment of
the enterprise
.

471


472

1)

What is the purpose of the architecture effort and what are the questions to
473

be addressed by this architecture effort?

474

2)

What is the boundary of the enterprise? What is considered inside the
475

enterprise versus external?

476

3)

What is the scope o
f the architecture effort, what are the echelons or
477

organizational levels involved, and what level of detail will be required in
478

the descriptions?

479

4)

What is the viewpoint of the architecture? From who’s perspective do we
480

examine the enterprise and write th
e descriptions (external customer,
481

supplier, or casual observer; internal role player; or process owner)?

482

5)


What echelons are represented by the architecture?

483

The Context should be defined before the architecture effort is begun and articulated
484

within the A
V
-
1. The context is part of the architecture’s metadata, which can be used for
485

discovery, semantic alignment, and contextual comparison with other architecture efforts.

486

10.6.

Boundaries for Tiers

487

Each enterprise tier


Department, Mission Area,
DoD Component
, a
nd Program


has
488

specific goals, as well as responsibilities to the tiers above or below them that are used to
489

determine the level of detail (or abstraction) necessary for their architecture.

490

10.7.

Semantic Alignment

491


492

A key goal of net
-
centricity is to enable se
mantic understanding of data so that
493

interoperability can be achieved between any applications that have the ability to access and
494

interpret the structural and semantic rules associated with data.

495


496

The Federated EA will be based on the semantic alignment

of tier level architecture
497

elements with elements of federation high
-
level taxonomies. Semantic alignment refers to the
498

relationship specified between the meanings of taxonomy elements. The semantic relationships
499

specified between activities will typic
ally include “is equivalent to,” “is part of,” or “is similar
500

to.” These relationships provide the alignment between the elements of
DoD Component
’s
501






materiel management activities to satisfy customer requirements developed collaboratively with the support
providers.”


DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

12

DRAFT

C/S/As architectures and the
high
-
level

reference taxonomies that specify the interface points in
502

the fede
ration for tiered accountability of the Federated EA content.

503


504

Through Tiered Accountability, Stakeholders and the
DoD Component
s will retain the
505

authority to manage their own internal Architecture holdings, consistent with federation
506

standards or method
ologies. However, the federated EA governance body at the appropriate tier
507

will have responsibility for capturing semantic consistency out of the separate
DoD Component
s
508

and communities of interest/practice, defining the semantic (meaning) and syntactical

(structure)
509

standards that will provide for consistent usage and meaning. Where possible, external and
510

industry standards will be considered for incorporation. Specifics on how semantic alignment
511

can be achieved will be included in the
Federated EA Imple
mentation Plan
.

512

11.

EA Services


Making the EA Visible, Accessible, and
513

Understandable

514

In order to make the EA visible, accessible, and understandable
9
, EA Services will be
515

implemented using Web Services, in which specific content and/or functionality is prov
ided by
516

one user for others, many of whom may be unanticipated by the provider (see Figure 1). The
517

return on investment in the Federated EA will result from DoD providers continually populating
518

the Federated EA with architecture data and products that sati
sfy a variety of anticipated and
519

unanticipated consumer needs. This will require the following development of standards and
520

services:

521



A set of standard metadata will be maintained for all architectures in
522

confederating repositories and Web service specif
ications (Web service
523

definition language [WSDL]) for discovery and registration.

524



A registration service will enable cataloging and linking of architectures in
525

federated repositories.

526



A discovery service will enable users to execute a federated search
for
527

architecture holdings meeting specified search parameters.

528


529

The following paragraphs elaborate on those concepts.

530

11.1.

Metadata

531

To implement a Federated EA search service, metadata elements must be defined to
532

capture attributes of artifacts required to supp
ort search parameters based on user needs. The
533

DoD Discovery Metadata Specification (DDMS) V1.3

provides a baseline specification for
534

architecture discovery metadata. The architecture conceptual model (currently the CADM)
535

provides additional AV
-
1 discove
ry metadata specifications. Several new metadata elements,
536

defined as “DDMS Plus” metadata, enable configuration management, architecture registration,
537

and cataloging.

538

Data may be stored in any format using relational, object oriented, or hybrid
539

technol
ogies based on any kind of data model. These principles do, however, require that
540




9

Visible, Accessible, and Understandable are key Net
-
Centric concepts from the NCOW RM v1.1 as integrated
from the Net
-
Centric

Strategies.

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

13

DRAFT

agreements be reached within the DoD EA Community of Interest (COI) or Community of
541

Practice (COP) on the structure and semantics of data elements used for data asset discov
ery,
542

linking, exchange, and integration. Metadata elements needed to support the EA user services
543

described herein are defined and proposed for DoD EA COI/COP acceptance as the standard for
544

net
-
centric federated EA services.

545

11.2.

Registration

546

Federation reposi
tories will capture all architecture metadata for architectures
547

developed in local environments. Federation
repository owners

will be responsible for
548

implementing mechanisms to collect metadata

specifics on the implementation of Registration,
549

including sp
ecific metadata requirements, which will be contained in the
Federated EA Services
550

Implementation Plan
.

551

11.3.

Discovery

552

The Federated EA will include a federated metadata discovery capability. The intent is
553

to provide a user
-
friendly service that enables disco
very of architecture metadata available from
554

federated repositories. Federated repositories are achieved when sources of similar content can
555

be searched via enterprise services. It will also enable the user to follow links to the source
556

architectures in t
he federated repositories. Specifics on the implementation of this tool will be
557

contained in the
Federated EA Services Implementation Guidance Document
.

558

The following sections address the two primary modes of discovery, registry browsing
559

and searching.

560


561

Registry Browsing
:

562

Users may browse a catalog of holdings for Federated EA repositories to find artifacts of
563

interest. Cataloging of repository holdings should enable users to search for artifacts by
564

navigating categorization taxonomies similar to browsin
g item categorizations in online
565

shopping Web sites. Multiple categorizations may apply to any single architecture. Catalog
566

navigation trees should use standardized category names from “approved” enterprise
567

taxonomies, when available, and may be extended

by domain extensions where needed.
568

Navigation trees should provide links to detailed metadata on architecture holdings to enable
569

users to determine potential interest value and include links to the products in source repositories
570

to enable user access to

selected products.

571


572

Searching
:


573

An architecture search capability
must
enable a user to specify a set of criteria for
574

architecture artifacts of interest. A single search interface using that set of search criteria needs
575

to be able to reach all architectu
re data repositories and present a consolidated response to the
576

user. The consolidated response, at a minimum, should:

577



Provide sufficient metadata on holdings, so that users can ascertain their
578

relevance.

579



Provide links to the results,
taking the user to
the source repository consistent
580

with the user’s role
-
based access privileges.

581

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

14

DRAFT



Include all available architecture metadata, including metadata not specified as
582

search parameters.

583

Figure
2

illustrates the concept for the proposed Core Enterprise EA Servic
es/DARS
584

implementation for the DoD Federated EA Services. It illustrates metadata registration and
585

discovery of architecture content within the federated repositories required to make the enterprise
586

architecture data visible, accessible, and understandabl
e for the DoD community.

587


588


589

Figure
2
: Making Architecture Accessible

590

12.

Governance

591

Since the Federated EA is not a unitary architecture, it will require a governance structure
592

to provide direction and oversight within the framework

of TA and the existing DoD and
DoD
593

Component

governance structures. The DoD CIO, or the CIO’s delegate, will serve as the
594

ultimate chairperson for management of the Federated EA. However, due to the complex
595

relationships between the architecture produce
rs/developers at various levels, the governance
596

roles within the Federated EA will vary according to roles within Tiered Accountability.

597

1)

At the Enterprise or OASD/JS
-
level, governance will address DoD
-
wide
598

Authority, Direction, Guidance, Monitoring, and

Affirmation/Remediation.

599

2)

At the Mission Area
-
level, governance will address Implementation,
600

Monitoring, and Affirmation/Remediation in response to DoD
-
wide guidance as
601

well as Mission Area unique Authority, Direction, and Guidance.

602

3)

Similarly, the
Do
D Component
-
level, governance will address Implementation,
603

Monitoring, and Affirmation/Remediation in response to DoD
-
wide guidance
604

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

15

DRAFT

and

Mission Area input, as well as individual
DoD Component

requirements for
605

Authority, Direction, and Guidance.

606


607

The detail
s for governance will be provided in a separate document, the planned DoD
608

Federated EA Governance Document. It will address areas such as:

609


610


611



Charter Development/Approval



Services



Roles and Responsibilities



Quality



Organizational Framework



Compliance



Re
source Requirements and Responsibilities



Maturity Models



Policies



Synchronization



Metrics



Repositories



Incentives



Security/Access



Data Management



Accreditation



Standards



External Relationships

A tentative outline for Governance is provided in Appendi
x F.

612

12.1.

EA Federation Roles and Responsibilities

613

This Federation Strategy is in accordance with DoD 8320.2
-
G,
DoD Guidance for
614

Implementing Net
-
Centric Data Sharing

by enforcing Tiered Accountability, whereby each tier,
615

or level, of the federation is responsi
ble for managing its own architectures and data while also
616

making those architectures and data visible, accessible, and understandable to other members of
617

the federation. The Federation
Strategy

seeks to operationalize Tiered Accountability.

618

Each Tier h
as both internal and external roles and responsibilities that it must perform
619

to make the Federated EA function as intended. These are presented in
Table 1,

where external
620

roles and responsibilities are denoted with a star (*) and internal roles and respo
nsibilities are
621

denoted with a square (■).

622


623

Table 1: Roles and Responsibilities for Individual Levels of Federation

624

Department



Impose constraints on federated Mission Areas,
DoD Component
s, 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 Component
s 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 Registrat
ion 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.

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

16

DRAFT

Program architectur
es can align in a
meaningful way.

Mission Area



Impose constraints on the
DoD Component
s
and Programs in order

to achieve Mission Area
(MA) goals and support interoperability
between mission areas.



Develop and maintain MA enterprise
architectures and mapping results.



Provide configuration management (CM) to
DoD Component
s’ taxonomies by MA.



Provide content to tax
onomies and
categorization schemes utilized for the DoD
Federated EA.



Report changes in content for DoD EA
Federation, as necessary.


625

DoD Component
s and Enterprise Programs



Impose constraints on
DoD Component
s’

Programs in order to achieve the
DoD
Compo
nent
s’ 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 the
DoD Component
s’
enterprise a
rchitectures.



Extend high
-
level taxonomies.



Implement the discovery services within the
DoD Component
s’ 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 Component
s’ 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 Component
s’ Program
architectures and mapping res
ults are visible,
accessible, and understandable.



Support metadata development.

DoD Component

Program’s



Maintain Program architecture element names
and definitions.



Propose modifications to the DoD EA to
increase/improve alignment between tiers.



Develop

and maintain the Programs’
architecture and mapping results.



Extend high
-
level taxonomies.




Map to the taxonomies and categorization
schemes provided by the
DoD Component
s
as appropriate.



Make the Programs’ architecture and mapping
results visible, access
ible, and understandable.



Adhere to the standards for data sharing
established by the Enterprise, MAs, and
DoD
Component
s.


626

Additional roles and responsibilities will be identified, as required, within the Governance
627

Document. Detailed roles and responsi
bilities specific to each level will be outlined in the DoD
628

EA Federation Implementation Plan.

629

12.2.

Information Assurance

630

This Strategy will embrace information assurance concepts and principles
and other
631

DoD guidance, as appropriate
. This is to ensure the int
egrity of the information across the
632

Federated EA that’s required to support the goals of visibility, accessibility, understandability,
633

and trustability (through metadata tagging of artifacts).

634

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

17

DRAFT

13.

Implementing the Federated EA

635

As an integral part of this Str
ategy, a detailed
Implementation Plan

will be provided as a
636

separate document.

637

13.1.

Pilot Efforts

638

There are two primary areas of interest for Proof
-
of
-
Concept (PoC) Pilot efforts. One is
639

to build and analyze a Federated EA using the
DoD High
-
level
Activity
Tax
onomy
, a Mission
640

Area Taxonomy, and
DoD Component
s


architecture. The other is to build and demonstrate EA
641

Services with an initial focusing on Registration and Discovery Services.

642

Enterprise Federation


Federated EA Pilot

643

The first pilot will build and a
nalyze a Federated EA using the
DoD High
-
level
Activity
644

Taxonomy
, Mission Area Taxonomy, and
DoD Component
s


architecture. OASD(NII) and the
645

EA Summit are currently evaluating candidates for this pilot.

646

EA Services


The DARS Pilot for Registration and Di
scovery

647

For the second pilot


registration and discovery capabilities


EA Registration and
648

Discovery Services will be implemented initially as Core Enterprise EA Services in DARS and a
649

selected set of federated repositories. These capabilities will then

be federated to other
DoD
650

Component
s


repositories, resulting in a more robust department
-
level capability. Using this
651

federated capability, a search request on one repository, e.g., DARS, will result in a returned set
652

of records matching the search crit
eria and will contain as much of the architecture metadata as is
653

available from each of the federated repositories having holdings that match the search criteria.
654

URLs in the reply metadata set will provide links to the source architectures in the federat
ed
655

repositories.

656

An architecture search capability should enable a user to specify a set of criteria for
657

architecture artifacts of interest. Users should be able to specify specific search criteria in a
658

search GUI using methods such as pick lists for the
allowable values for each of the criteria.
659

That set of search criteria needs to be propagated to all architecture data repositories. The user
660

then needs to receive a single consolidated response that:

661



Provides consistent metadata from all sources

662



Provid
es sufficient metadata to enable the user to ascertain their relevance

663



Provides links to the sources

664

Once a user determines which architecture artifacts are of interest, a link associated with
665

each result will take the user to the source repository. Depe
nding on the security policy of the
666

source repository, the link may either provide direct access to the selected artifact in the native
667

repository format or visualization environment, or, in future versions; it may direct the user to a
668

role subscription se
rvice on the native repository for requesting access to the product. User
669

credentials may also be passed by the search service to the source repository for authentication to
670

enable automated access based on access roles/privileges associated with the user

in the source
671

repository
.


672

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

18

DRAFT

14.

Critical Success Factors

673

A review of the business and warfighting mission drivers/needs (with respect to their
674

information

needs), at an enterprise, i.e., joint level, reveals the high degree of cooperation and
675

participation nee
ded for federating the disparate architectures across the entire DoD, including
676

alignment of external organizations and agencies in support of strategic, joint decision making.

677

Following is a list of broad categories of candidate Critical Success Factors (
CSF) related
678

to the
institutionalizing

of a DoD Federated Architecture environment. The broad CSF
679

categories are:

680



Required commitment by OSD, JS, and DoD
DoD Component
s

for participation
681

in the FJAWG,

682



Adoption and implementation by OSD, JS, and DoD
DoD C
omponent
s

for
683

architecture governance, registration, high
-
level taxonomies, federation levels,
684

roles and responsibilities, federation methodologies, etc.

685



Selection and successful implementation of a PoC Pilot in order to validate EA
686

Federation concepts, go
vernance, methods, tools, high
-
level taxonomies, etc.

687



Linking Business and Warfighting mission drivers/needs.

688



Commitment of resources at OSD, JS, and DoD
DoD Component
s

to support
689

federation development and implementation.

690



Adoption of DARS as the Federated

EA Registry.

691


692

Appendix G contains a detailed list of CSFs within each category.

693

15.

The Way Ahead

694

To begin implementation of this
Strategy:

695



OSD Leadership, working with the
DoD Component
s

and other stakeholders,
696

will articulate details required for implementa
tion.

697



Registry and repository owners will work with the registry pilot lead on
698

federating discovery services.

699



FJAWG as the EA Summit arm will complete the development of the
high
-
level
700

activity
taxonomies
.

701



The community will define how linkages are managed

between the Tiers in the
702

Federation.

703



DARS will implement the linkages between the Tiers in accordance with the
704

community requirements as a community extension to Core Enterprise EA
705

Services for EA.

706



Mission Area Leads will define their high
-
level taxonomie
s for inclusion in the
707

DoD EA Reference Models.

708

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

A
-
1

DRAFT

APPENDIX A: ACRONYM LIST

709


710

ACAT

Acquisition Category

ACCB

Architecture Configuration Control Board

BEA

Business Enterprise Architecture

BMA

Business Mission Area

BRM

Business Reference Model

BTA

Busines
s Transformation Area

C/S/A

Command/Service/Agency

CADM

Core Architecture Data Model

CCB

Configuration Control Board

CIO

Chief Information Officer

CJCS

Chairman of the Joint Chiefs of Staff

CJCSI

CJCS Instruction

CM

Configuration Management

COAL

C
onsolidated Operational Activities List

COI

Community of Interest

COP

Community of Practice

COTS

Commercial Off The Shelf

C/S/As

Combatant Commands, Services, and Agencies

CSF

Critical Success Factors

CSFL

Consolidated Systems Function List

DARS

DoD

Architecture Registry System

DDMS

DoD Discovery Metadata Specification

DIA

Defense Intelligence Agency

DoD

Department of Defense

DODD

DoD Directive

DODI

DoD Instruction

DOTMLPF

Doctrine, Organization, Training, Material, Leadership and
education, Pe
rsonnel, and Facilities

DRM

Data Reference Model

EA

Enterprise Architecture

EIE

Enterprise Information Environment

FCB

Functional Control Board

FEAF

Federal Enterprise Architecture Framework

FJAWG

Federated Joint Architecture Working Group

GIG

Globa
l Information Grid

GOTS

Government Off The Shelf

IT

Information Technology

JCA

Joint Capability Area

JC3IEDM

Joint Consultation Command and Control Information
Exchange Data Model

JCS

Joint Chiefs of Staff

JMA

Joint Mission Area

JS

Joint Staff

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

A
-
2

DRAFT

MA

M
ission Area

NCOW

Net Centric Operations and Warfare

OASD

Office of the Assistant Secretary of Defense

PoC

Proof of Concept

PRM

Performance Reference Model

RM

Reference Model

SFIS


SOA

Service Oriented Architecture

SRM

System Reference Model

TA

Tie
red Accountability

TRM

Technical Reference Model

UJTL

Universal Joint Task List

WSDL

Web Service Definition Language




711

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

B
-
1

DRAFT

APPENDIX B: DEFINITIONS

712


713

Architecture
:

714

Architecture is the structure of
components
, their interrelationships, and the principles a
nd
715

guidelines governing their design and evolution over time.
[CIO Council, A Practical Guide to Federal
716

Enterprise Architecture, February 2001]

717


718

Architecture Integration
:

719

Architecture Integration is the process of consolidating the content of disparate ar
chitectures to
720

support analyses of a broader scope than that possible with any single disparate architecture.
721

Architecture integration includes the mapping or standardization of terms and definitions across
722

disparate architectures and the integration resu
lts in a set of data and products that support Joint
723

operations and development efforts.
[DoD Federated Joint Architecture Working Group (FJAWG)
724

recommendation, Dec 2005]

725


726

Artifact:

727

An abstract representation of some aspect of an existing or to
-
be
-
built sy
stem, component, or
728

view. Examples of individual artifacts are a graphical model, structured model, tabular data, and
729

structured or unstructured narrative. Individual artifacts may be aggregated.
[US Department of
730

Agriculture Office of the CIO, http://www
.ocio.usda.gov/e_arch/glossary.html]

731


732

High
-
level (Adj.)
:

733

For purposes of this Strategy, the phrase “high
-
level” is used as an adjective representing the
734

highest
-
level structure within an enterprise, mission area, or
DoD Component
s

providing context
735

and gui
dance for all lower levels. It is used primarily as a modifier to another term “taxonomy”
736

to represent highest
-
level structure within an echelon shown above.

737


738

Core Enterprise EA Services
:

739

Core Enterprise Services are IT services that provide the foundati
on for DoD service and data
740

providers by delivering and managing the underlying capabilities from which communities build
741

and receive the services they need to meet their business and information processing needs.
For

742

EA
,

the initial
IT services that suppo
rt the registration and discovery of architectural artifacts,
743

architectures, or products

will be developed. Additional anticipated services include

translation
744

services that
ensure
artifacts, architectures, or products are understandable between DARS and
745

other architectural repositories.

746


747

Discovery
:

748

The act of locating a machine
-
processable description of a
Web service
-
related resource that may
749

have been previously unknown and
that meets certain functional criteria. It involves matching a
750

set of functional and other criteria with a set of resource descriptions. The goal is to find an
751

appropriate Web service
-
related resource.
[Web Services Glossary, W3C Working Group Note 11 Febr
uary
752

2004]

753


754

Discovery

Service
:

755

A discovery service is a
service

that enables agents to retrieve
Web ser
vices
-
related resource
756

description.
[Web Services Glossary,W3C Working Group Note 11 February 200
4]

757

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

B
-
2

DRAFT


758

Enterprise
:

759

Enterprise is an organization (or cross
-
organizational entity) supporting a defined business scope
760

and mission. An enterprise includes interde
pendent resources (people, organizations, and
761

technology) that must coordinate their functions and share information in support of a common
762

mission (or set of related missions).
[CIO Council, A Practical Guide to Federal Enterprise Architecture,
763

February 2
001]

764


765

Federated Architecture:

766

Federated architectures define common or shared architecture standards across autonomous
767

program areas, enabling state government entities to maintain diversity and uniqueness, while
768

providing interoperability.
[New York State

Office for Technology
http://www.oft.state.ny.us/arcPolicy/policy/

769

glossary.htm]

770


771

An Architecture Federation is a framework for enterprise architecture development, maintenance
772

and use that lin
ks, locates, and aggregates disparate architectures and architecture information.
773

A federated architecture approach recognizes the uniqueness and specific purpose of disparate
774

architectures, and allows for their autonomy and local governance, while enabli
ng the enterprise
775

to benefit from their content.
[DoD FJAWG recommendation, Dec 2005]

776


777

Federated Architectures: Separate, Distinct, Individual Architectures
:

778

Separate architectures were built under different contexts but may be aligned within an
779

overarchi
ng scope and boundary, viewed from a common point of view, for a common purpose,
780

and a specified set of questions to be addressed by the resulting federated architecture.
[DoD
781

FJAWG recommendation, Dec 2005]

782


783

Services:

784

A mechanism to enable access to one o
r more capabilities, where the access is provided using a
785

prescribed interface and is exercised consistent with constraints and policies as specified by the
786

service description.
[From the GIG Enterprise Services Strategy, Oct 2006]

787


788

Service
-
Oriented Archit
ecture and SOA Principles:

789


790

SOA is a paradigm for organizing and utilizing distributed capabilities that may be under the
791

control of different ownership domains. It represents a collection of services on a network that
792

communicate with one another. It is
any architecture that can be decomposed, on a logical level,
793

into three categories of components: a service, a provider of the service, and a consumer of the
794

service.
SOA addresses three roles and three operations. The three roles are the service producer

795

(provider), the service consumer (requester), and the service registry The objects acted upon are
796

the service and the service description, and the operations performed on these objects are
797

publish, find, and bind. Within industry and DoD the concept and s
ervice principles are evolving
798

as we gain experience with SOA. Some general service
-
oriented principals are:
discoverable,
799

accessible, and dynamically bound; enable interoperability; are loosely coupled; have a network
800

addressable interface; are location t
ransparent; and are not bound to specific systems.
[NCOW RM
801

v1.2 (draft)]

802


803


804

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

B
-
3

DRAFT

Service Registry or Registry Service:

805

Is a platform neutral, network based directory that stores information about services and is
806

searchable based on the descriptive metadata defi
ned in the service specification.
[DoDAF Version
807

1.5 Vol 2 Oct 2006]

808


809


810


811

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

C
-
1

DRAFT

APPENDIX C: REFERENCE DOCUMENTS

812


813


814

A Practical Guide to Federal Enterprise Architecture
, CIO Council, February 2001.

815


816

BMA


Federation Strategy and Roadmap [Working Draft]
, Business T
ransformation Agency,
817

28 August 2006.

818


819

Concepts of Enterprise Architecture: Federating Components of an Enterprise Architecture
,
820

Draft MITRE Corporation Paper for SAF/XCXA, 6 September 2006.

821


822

Department of Defense Chief Information Officer Memorandum, "
Do
D Net
-
Centric Data
823

Strategy
," May 9, 2003.

824

DoD Architecture Framework
, Version 1.0, 9 February 2004.

825


826

DoD Directive 8100.1, "
Global Information Grid (GIG) Overarching Policy
," September 19,
827

2002.

828

DoD Federated Joint Architecture Working Group (FJAWG) Inter
nal Working Papers,
829

December 2005
-
Present.

830


831

DoD Net Centric Spectrum Management Strategy
, OASD (NII), 25 April 2005.

832


833

Federated Architectures
, Enterprise Integration Inc., 2005.

834


835

Global Information Grid Enterprise Services Strategy
, Working Draft,
OASD(NII
) CIO, Oct
836

2006.

837


838

http://www.ocio.usda.gov/e_arch/glossary.html
, U.S. Department of Agriculture Office of the
839

CIO.

840


841

http
://www.oft.state.ny.us/arcPolicy/policy/glossary.htm
, New York State Office for
842

Technology.

843


844

National Defense Strategy of the United States of America
, March 2005.

845


846

The
“Net
-
Centric Operations and Warfare Reference Model, OASD (NII)”,

17 Nov 2005.

847


848

“Join
t Concept of Operations for Global Information Grid NETOPS version 2.0”
,
849

USSTRATCOM, 10 Aug 2005

850


851

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

D
-
1

DRAFT

APPENDIX D: RELATED GUIDANCE

852


853

Architecture requirements are solidly grounded in Law; the Clinger
-
Cohen Act assigned
854

Chief Information Officers the responsib
ility for “developing, maintaining, and facilitating the
855

implementation of a sound and integrated information technology architecture.” Additional
856

details are provided in Office of Management and Budget Circular A
-
130. The Circular
857

establishes an Enterpr
ise Architecture (replacing the term “information technology architecture”)
858

as consisting of the following elements: business processes, information flows, data
859

descriptions, applications, technology infrastructure, and standards. The Circular also estab
lishes
860

the requirement for the EA to be incorporated in the Executive Agency’s Capital Planning and
861

Investment Control Process.

862


863

DoD prescribes the DoDAF version 1.0 (DoDAF) as the basis for DoD developing
864

architecture descriptions. DoDAF
-
based architectu
re descriptions are required in many of the
865

Department’s major processes; these descriptions are also required to be consistent with the GIG
866

Architecture and NCOW RM. The following policies require the development of architecture
867

descriptions:

868



CJCSI 3170.
01E, Joint Capabilities Integration and Development System

869



CJCSI 6212.01D, Interoperability and Supportability of Information
870

Technology and National Security Systems

871



DoDD 5000.1, The Defense Acquisition System

872



DoDI 5000.2,

Operation of the Defense Acquisi
tion System

873



DoDD 4630.5,
Interoperability and Supportability of Information Technology
874

and National Security Systems

875



DoDI 4630.8,
Procedures for Interoperability and Supportability of Information
876

Technology and National Security Systems

877



DoDD 8000.1, Manag
ement of DoD Information Resources and Information
878

Technology

879



DoDD 8115.1, Information Technology Portfolio Management

880


881

These policies are enforced through processes that include assessments of compliance with
882

applicable architectures. DoDI 5000.2, for ex
ample, includes requirements for Clinger
-
Cohen
883

Compliance. One of the compliance criteria requires that acquisitions are “consistent with the
884

Global Information Grid policies and architecture, to include relevant standards.” The DoD CIO
885

as well as the
Do
D Component

CIO’s assess lower Acquisition Category (ACAT) programs.

886

The

development of a DoD Federated EA will be conducted in accordance with both DoD
887

and Federal policy on the development and use of Enterprise Architectures. The approach to
888

federation
described herein shall closely follow DoD policy and directives on net
-
centric data
889

management. The following net
-
centric references are applicable:

890



DoD CIO Memorandum,
DoD Net
-
Centric Data Strategies:

891



Net
-
Centric Data

892



Shared Services

893



Information A
ssurance

894

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

D
-
2

DRAFT



Spectrum

895



Networking

896



Computing Infrastructure

897



DoD Directive 8320.2, Data Sharing in a Net
-
Centric Department of Defense


898



Federal Enterprise Architecture Program, EA Assessment Framework 2.0

899



Federal Enterprise Architecture Program, Data Refer
ence Model 2.0

900

Key net
-
centric principles that must be adhered to are that data assets must be made visible,
901

accessible, understandable, and trusted (when referring to IA), and they must be
enabled to
902

support interoperability. These principles do not assu
me or prescribe any requirements for
903

physical data storage. Data may be stored in any format using relational, object oriented, or
904

hybrid technologies based on any kind of data model. These principles do, however, require that
905

agreements be reached withi
n the DoD EA Community of Interest (COI) or Community of
906

Practice (COP) on the structure and semantics of data elements used for data asset discovery,
907

linking, exchange, and integration. Metadata elements needed to support the EA user services
908

described h
erein are defined and proposed for DoD EA COI/COP acceptance as the standard for
909

net
-
centric federated EA services.

910

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

E
-
1

DRAFT

APPENDIX E: ARCHITECTURE CATEGORIZATION,
911

STRUCTURE (TAXONOMY)

912


913

The top level of the DoD Federated EA taxonomy will initially consist of t
he four DoD
914

Business Reference Model (BRM) Mission Areas (MAs) [see
Figure E
-
1
] and be coordinated by
915

a federated DoD EA control board.

916


917


918

Figure E
-
1: Federated DoD EA Taxonomy

919

Table E
-
1

identifies MA Taxonomy Configuration Ma
nagement (CM) Authorities that will
920

have autonomy for defining and managing a core set of taxonomy elements for each MA.
921

Mission area taxonomies should be derived from MA activity decomposition and synchronized
922

with the DoD BRM.

923

Table E
-
1: Federated Do
D and MA Taxonomy CM Authority

924

BRM Mission Area

Taxonomy Content
CM Authority

Decomposition Basis

Warfighting

JS

FCBs/JCAs

Business

BTA

BEA (TBD)

Intelligence

DIA

DoD BRM for Intel

Enterprise Information Environment

DoD CIO

DoD BRM for EIE

The number
of
High
-
level taxonomy tiers defined and managed, as a core set will depend
925

on the degree to which the MA Taxonomy CM Authority wishes to exercise CM control over the
926

taxonomy structure. Decomposition levels below the MA core structure will be defined by
DoD
927

Component
s, as authorized by the MA Taxonomy CM Authority. Each EA
DoD Component
s


928

Service

Agency

COCOM

Warfighter

MA

Business

MA

Intel

MA

EIE MA

Managed by

MA Authority

Subordinate architectures

mapped to MA

-

level by Components

Federa
ted

DoD

EA Control Board

Service

Agency

COCOM

Warfighter

MA

Business

MA

Intel

MA

EIE


MA

Managed by

MA Authority

Subordinate architectures

mapped to MA

-

level by Components

Federated

DoD

EA Control Board

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

E
-
2

DRAFT

architecture developer will classify its architectures in the DoD Architecture Registry System
929

(DARS) by associating
DoD Component
s


architectures with nodes of the MA
core or authorized
930

DoD Component

extensions to the core by registering Taxonomy Node and Association Type
931

metadata.

932

The Federated Joint Architecture Working Group (FJAWG) has already developed several
933

assessments and recommendations in regard to taxonomy,
which are provided here for reference,
934

pending establishment of the formal structure for their implementation:

935

1.

Mission Area Taxonomy CM Authorities must accept responsibility for defining
936

and managing MA core upper tier taxonomy nodes. Therefore, the EA su
mmit
937

should adopt and promulgate the recommended EA
High
-
level

Taxonomy
938

strategy.

939

2.

DoD Component
s will have autonomy in developing domain taxonomies.
940

However, domain architecture mappings and extensions to the MA core must be
941

regulated to minimize categori
zation redundancies. Therefore:

942

a.

MA authorities should provide guidance on developing and mapping
943

domain extensions to the MA core, to include approval and mapping of
944

“authoritative” extensions.

945

b.

The FJAWG should recommend guidance to MA authorities on re
gulating
946

DoD Component

domain extensions and mappings to the MA core.

947

3.

MA core taxonomies need to be coordinated to maximize uniqueness of top
-
948

level nodes and minimize potential categorization

redundancy; and business
949

analysis needs may drive requirements f
or additional taxonomies to be
950

incorporated into the MA
high
-
level

taxonomy in the future. Therefore, a
951

Federated EA
high
-
level

taxonomy configuration control function and
952

governance should be established above the individual MAs for regulating the
953

high
-
l
evel

taxonomy structure and coordinating/de
-
conflicting the MA
-
954

taxonomy top
-
level nodes. Governance authority should be assigned to the
955

DoD Architecture Configuration Control Board (ACCB). Execution
956

responsibility should be assigned to the FJAWG as the t
echnical advisor to the
957

ACCB.

958

Changes in the MA core taxonomies will impact alignments
in

the registry and should be
959

managed. Therefore, MA Authorities should develop and implement a core taxonomy CM
960

process subject to ACCB approval.

961

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a262
00519.doc

F
-
1

DRAFT

APPENDIX F: DOD FE
DERATED EA GOVERNANCE
962

DOCUMENT

963


964

Draft Governance Outline

965

Scope

966

Governance Framework

967

OASD/JS Level

968



Authority

969

o

Charter Development/Approval

970

o

Organizational Framework

971



Governance Bodies

972



Voting Members

973



Stakeholder Participation

974

o

Roles and Responsibilities

975

o

Resour
ce Requirements and Responsibilities

976



Guidance

977

o

Policies

978

o

Synchronization

979

o

Security/Access

980



Accreditation of content

981



Accreditation of members

982



Access control and privileges

983

o

External Relationships

984



Direction

985

o

Standards

986



Tools

987



Metadata

988

o

Quality

989

o

Maturity Models

990

o

Reposit
ories

991

o

Registries

992

o

Data Management

993

o

Services

994

o

Configuration Management

995



Monitoring

996

o

Metrics

997

o

Compliance

998



Affirmation/Remediation

999

Mission Area and
DoD Component

Levels

1000



Implementation Responsibilities

1001



Monitoring Responsibilities

1002



Affirmation/Remediation Responsibilit
ies

1003


1004

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

G
-
1

DRAFT

APPENDIX G: A DETAILED LIST OF CRITICAL SUCCESS
1005

FACTORS (CSF) BY CSF CATEGORY

1006


1007



Commitment by
DoD
DoD Component
s

to
:

1008

o

Actively participate in FJAWG effort

1009

o

Maintain
DoD Component
s

-
level architecture metadata

1010

o

Be willing to participate in and support
EA Federation PoC Pilot efforts

1011

o

Organizations external to DoD that need to assist or provide access to information for
1012

identifying external architecture interface needs

1013


1014



Adoption and implementation by DoD
DoD Component
s

of the following
:

1015

o

Federated EA regis
tration and discovery services

1016

o

Architecture federation rules

1017

o

Federated EA metadata standards

1018

o

Recommended Federation structure

1019

o

EA Federation roles and responsibilities

1020

o

Proposed high
-
level taxonomies

1021

o

Standard methodologies for aligning and linking archit
ectures

1022

o

Architecture categorization schemes

1023

o

Architecture federation governance

1024


1025



Proof
-
of
-
Concept Pilot is needed to validate the following
:

1026

o

Applicability & effectiveness of proposed high
-
level taxonomies

1027

o

Architecture configuration management

1028

o

Architecture
discovery capabilities and performance requirements are satisfied

1029

o

Architecture governance at the all levels ensures integrity, visibility, accessibility,
1030

availability, understandability, and usability of architecture data by business/mission
1031

users

1032

o

Architec
ture metadata at
DoD Component
s

level satisfies business/Mission Area
1033

information discovery needs

1034

o

Architecture navigation and discovery provides correct architecture content

1035

o

Architecture registration and discovery capabilities and performance requirements

are
1036

satisfied

1037

o

Capability to discover (and acquire) architecture content via navigation, search, and
1038

browsing services

1039

o

Capability to provide and search on user
-
defined search criteria

1040

o

Categorization schemes are effective in serving business and MA inform
ation
1041

discovery needs

1042

o

Correctness of rules for federating architectures across the DoD

1043

o

Discovery capabilities meet unanticipated user needs

1044

o

Effectiveness and efficiency of architecture navigation schemes

1045

o

Effectiveness and efficiency of registration servic
e

1046

o

Guidance for federation structure

1047

o

Key interface points for linking architectures are the correct ones

1048

o

Linkage to architectures external to the DoD EA Federation

1049

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

G
-
2

DRAFT

o

Linkages are established, on different platforms, with independent repositories within
1050

the fe
deration

1051

o

Viability and effectiveness of implemented EA Federation roles and responsibilities
1052

framework

1053

o

Viability of accommodating various formats and toolsets

1054


1055



Linking Business and Warfighting mission drivers/needs
:

1056

o

Alignment of operational activities

1057

o

Id
entifying a “common scenario” applicable to the business or warfighting missions

1058

o

Supporting IT enablers for the operational activities

1059


1060



Resources at
DoD Component
s

and EA Federation levels must be available to
:

1061

o

Participate in and support the PoC Pilot effo
rts

1062

o

Aid in identifying all architecture formats and toolsets in use

1063

o

Identify interface needs

1064

o

Assist in identifying architecture interface points

1065

o

Develop and governance structure at DoD Enterprise and
DoD Component

levels

1066

o

Develop and update architecture met
adata at
DoD Component

level

1067

o

Develop and update links to architecture content at the
DoD Component

level

1068

o

Map Mission Areas to each other

1069

o

Assist in
DoD Component

repository federation effort

1070


1071



Adoption of DARS as the Federated EA Registry for Architecture
-

DARS must be
:

1072

o

Accessible and available across entire DoD

1073

o

Intuitive, user
-
friendly, fast, responsive, and timely for architecture registration and
1074

discovery

1075


1076



EA Federation Tools performance requirements involve the following
:

1077

o

Automated mapping and linking
of architecture content

1078

o

Applications that must have timely response times

1079

o

Must be user
-
friendly, intuitive, fast online response

1080

o

Interfaces that must be developed to accommodate all architecture formats and
1081

toolsets for architecture registration and disco
very

1082


1083



Knowledge and/or skills in
:

1084

o

Architectures external to the DoD that need to be interfaced with the Federated EA

1085

o

DoD technology infrastructure

1086

o

Existing disparate architectures across the DoD

1087

o

Technologies and tools to provide linking to architecture co
ntent

1088

o

Web technology

1089

o

Metadata standards that need to be implemented

1090

o

Architecture formats, methodologies, and toolsets

1091

o

Prospective current and future types of unanticipated users of Federated EA

1092

o

Types of architecture artifacts needed by unanticipated users

1093

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

H
-
1

DRAFT

APPENDIX H: ACTIVITY
-
BASED EA FEDERATION
1094

ALIGNMENT

1095


1096

Activity
-
Relationship
-
Activity
:

1097


1098

Federating the architecture in an enterprise requires a high
-
level taxonomy (under
1099

development) of the enterprise and an activity model for each
DoD Component
of intere
st in the
1100

enterprise. The activities within the high
-
level taxonomy and
DoD Components’

activity models
1101

will be related in one of the following four ways as illustrated in
Figure H
-
1

below.

1102



Equivalent to

1103



Similar to

1104



Part of

1105



No relationship

1106


1107


Federated Architecture Relationships





High
-
level Activity Taxonomy

FM

IL

AFMC

Is Part of

Is Equivalent to

Is Part of

Is Equivalent to

Is Similar to


1108

Figure H
-
1. Federation Relationships Among Activities

1109

A
DoD Components’

activity is considered “equivalent to” a high
-
level activity if the
1110

descriptions and artifacts of both are identical.

1111

A
DoD Component
s


activity is considered “similar
to” a high
-
level activity if the
1112

descriptions are the same but the primitives differ in some specification between the enterprise
1113

design and the
DoD Component
s

implementation, the activity is done differently by two or more
1114

DoD Component
s
, or two or more
D
oD Component
s

accomplish the same activity with different
1115

primitive specifications.

1116

A
DoD Component
s


activity is considered “part of” a high
-
level activity if the description
1117

of the
DoD Component
s


activity achieves part of the high
-
level activity’s goal,

and another
1118

DRAFT


spongereason_a84852f0
-
4756
-
41c0
-
9786
-
713a26200519.doc

H
-
2

DRAFT

DoD Component
s


activity that also has a “part of” relationship with the same high
-
level activity
1119

completes the goal.

1120

If a
DoD Component
s


activity has no relationship with any of the high
-
level activities,
1121

then no relationship is shown.


1122

Rela
tionships between the high
-
level and
DoD Component
s


activities can occur at any
1123

level of decomposition.

1124


1125