DoD Architecture Framework

Content is Pre-Decisional Material 24 Dec 08 Spiral 4

i DRAFT

Content is Pre-Decisional Material

1

Text

starswreath

2 3

4

5

6

7

DoD Architecture Framework 8

Version 2.0 9

Draft 10

11 12

13

14

15

16

Volume 1: Introduction, Overview, and Concepts 17

18

Management Volume 19

20

24 December 2008 21

22

23

This content is pre-decisional material. No part of this publication maybe released, transmitted, or copied without prior permission of Deputy CIO (EA&S)


ii DRAFT


24

25

26


iii DRAFT


TABLE OF CONTENTS 27

TABLE OF CONTENTS ............................................................................................................ iii 28

TABLE OF FIGURES................................................................................................................ vii 29

To be provided............................................................................................................................. vii 30

DOD ARCHITECTURE FRAMEWORK VERSION 2.0 ........................................................ 1 31

EXECUTIVE SUMMARY .......................................................................................................... 1 32

VOLUME 1 – INTRODUCTION, OVERVIEW, AND CONCEPTS ..................................... 6 33

1. INTRODUCTION............................................................................................................. 6 34

1.1 Vision for DoDAF 2.0 ............................................................................................................. 7 35

1.2 DoDAF 2.0 Organization and Intended Audience ............................................................... 7 36

1.3 Purpose and Scope ............................................................................................................ 9 37

1.3.1 Developing Architectures. .......................................................................................... 10 38

1.3.2 Maintaining and Managing Architectures ............................................................... 11 39

1.3.3 Using Architectures .................................................................................................... 11 40

1.3.4 DoDAF Conformance ........................................................................................................ 12 41

1.4 What’s New in Volume 1. ..................................................................................................... 12 42

1.5 What Managers and Executives Need to Know about DoDAF. ...................................... 13 43

2. SCOPING ARCHITECTURES TO BE “FIT FOR PURPOSE” .............................. 15 44

3. DoDAF VOLUMES AND JOURNAL OVERVIEW .................................................. 18 45

3.1 DoDAF Overview............................................................................................................ 18 46

3.2 DoDAF Background ....................................................................................................... 19 47

3.2.1 Authority: Law, Policy, and Historic Perspective.................................................... 19 48

3.2.2 Historical Evolution of DoDAF......................................................................................... 20 49

3.2.3 DoDAF Version 2.0 – The Need for Change............................................................. 21 50

3.2.3.1 Architecture Focus...................................................................................................... 22 51

3.2.3.2 Shifting from Product-Centric to Data-Centric Focus............................................ 22 52

3.3 Assumptions..................................................................................................................... 22 53

3.4 DoDAF Structure and Views ............................................................................................... 23 54

3.5 DoDAF Development Guidelines................................................................................... 26 55

3.5.2 Multiple Techniques and Toolsets, including Structured and Object Oriented 56

Analysis. 28 57

3.6 Architecture Resources .................................................................................................. 28 58

4. ENTERPRISE ARCHITECTURE ............................................................................... 32 59

4.1 Introduction and Overview............................................................................................ 32 60

4.2 Transition Planning ........................................................................................................ 34 61

4.3 Federated Approach to DoD Architecture Management............................................ 35 62

4.4 Tiered Accountability. .................................................................................................... 35 63

4.5 DoD Architecture Enterprise Services.......................................................................... 36 64

4.6 Alignment to the Federal Enterprise Architecture (FEA) .......................................... 37 65

4.7 Addressing Security Issues in DoDAF-conformant Architecture Development............. 40 66

5. ARCHITECTURE PLANNING ................................................................................... 40 67

5.1 Defining the Enterprise .................................................................................................. 40 68

5.2 The Enterprise-level Architecture....................................................................................... 40 69

5.3 The Solution-Level Architecture ......................................................................................... 41 70

5.4 Architecture Management ............................................................................................. 41 71


iv DRAFT


5.4.1 Architecture Development ......................................................................................... 41 72

5.4.2 Architecture Utilization.............................................................................................. 41 73

5.4.3 Architecture Maintenance.......................................................................................... 42 74

5.4.4 Architecture Utilization.............................................................................................. 42 75

5.4.5 Architecture Compliance Reviews ................................................................................. 42 76

5.4.5.1 OMB Architecture Assessment.............................................................................. 43 77

5.4.5.2 GAO Architecture Assessment .................................................................................. 43 78

5.4.6 User Support................................................................................................................ 44 79

5.4.7 Training ....................................................................................................................... 44 80

5.4.8 Communications Planning ......................................................................................... 44 81

5.4.9 Quality Planning ......................................................................................................... 45 82

5.4.10 Risk Management ....................................................................................................... 45 83

6. CUSTOMER REQUIREMENTS.................................................................................. 46 84

6.1 Tailoring Architecture to Customers’ Needs ............................................................... 46 85

6.2 Key Decision Support Processes .................................................................................... 47 86

6.2.1 Joint Capability Integration and Development System .......................................... 47 87

6.2.2 Defense Acquisition System ....................................................................................... 47 88

6.2.3 Systems Engineering (SE) .......................................................................................... 48 89

6.2.4 Planning, Programming, Budgeting, and Execution (PPBE) ................................. 49 90

6.2.5 Portfolio Management ................................................................................................ 49 91

6.2.6 Operations ................................................................................................................... 49 92

6.3 Information Sharing ............................................................................................................. 50 93

7. METHODOLOGIES...................................................................................................... 51 94

7.1 Methodology Based Approach to Architecture............................................................ 51 95

7.1.1 6-Step Architecture Development Process................................................................ 52 96

7.1.1.1 Step 1: Determine Intended Use of Architecture ..................................................... 53 97

7.1.1.2 Step 2: Determine Scope of Architecture.................................................................. 53 98

7.1.1.3 Step 3: Determine Data Required to Support Architecture Development............ 54 99

7.1.1.4 Step 4: Collect, Organize, Correlate, and Store Architecture Data................... 55 100

7.1.1.5 Step 5: Conduct analyses in support of architecture objectives ............................. 56 101

7.1.1.6 Step 6: Document Results in Accordance with Architecture Framework............. 56 102

7.1.2 Accommodating Multiple Methods for Implementation......................................... 57 103

7.1.3 Architecture Life Cycle & Architecture Governance..................................................... 57 104

7.1.4 Planning for Architecture Development................................................................... 58 105

7.1.5 Approaches to Architecture Development................................................................ 59 106

7.1.5.1 Structured Technique Overview ............................................................................... 59 107

7.1.5.1.1 Process Data Flow................................................................................................... 59 108

7.1.5.1.2 Process Task-Dependency Diagram...................................................................... 60 109

7.1.5.1.3 Entity-Relation Model ............................................................................................ 60 110

7.1.5.2 Object-Oriented Technique Overview...................................................................... 60 111

7.1.5.2.1 Process – Activity Diagram, Object-Sequence Diagram..................................... 60 112

7.1.5.2.2 Data – Object Class Diagram................................................................................. 61 113

7.2 System (Component, Package, Deployment) Diagram................................................ 61 114

7.2.1 Component Model and Package Diagram................................................................ 61 115

7.2.2 Deployment/Operational Model ................................................................................ 61 116


v DRAFT


8. ARCHITECTURE PRESENTATION TECHNIQUES.............................................. 63 117

8.1 Overview ................................................................................................................................ 63 118

8.2 Choosing an Appropriate Presentation Technique ........................................................... 65 119

8.3 Composite Views ............................................................................................................. 67 120

8.3.1 Purpose and Audience ................................................................................................ 67 121

8.3.2 Examples............................................................................................................................. 67 122

8.4 Dashboard Views ............................................................................................................ 68 123


8.4.2 Examples............................................................................................................................. 69 125

8.5 Fusion Views.......................................................................................................................... 71 126

8.5.1 Purpose and Audience ....................................................................................................... 71 127

8.5.2 Examples............................................................................................................................. 71 128

8.6 Graphics Views...................................................................................................................... 73 129


8.6.2 Examples............................................................................................................................. 74 131


8.7.2 Examples...................................................................................................................... 76 133

9. DODAF META-MODEL............................................................................................... 79 134

a. 9.1 The DoDAF Conceptual Data Model ...................................................................... 79 135

10. ARCHITECTURE-BASED ANALYTICS................................................................... 82 136

10.1 Analytics Context ............................................................................................................ 82 137

10.2 Architecture Analytics.................................................................................................... 83 138

10.3 Types of Architecture Analysis...................................................................................... 83 139

10.4 Examples of Analytics..................................................................................................... 84 140

10.5 Principles of Architecture Analytics ............................................................................. 84 141

10.5.1 Information Consistency ............................................................................................ 84 142

10.5.2 Data Completeness...................................................................................................... 85 143

10.5.3 Transformation ........................................................................................................... 85 144

10.5.4 Iteration ....................................................................................................................... 85 145

10.5.5 Lack of Ambiguity ...................................................................................................... 85 146

11. CONFIGURATION MANAGEMENT OF THE DODAF ARCHITECTURE 147

FRAMEWORK........................................................................................................................... 86 148

11.1 Configuration Management Authority ......................................................................... 86 149

11.2 Configuration Management Guidance for Program Managers................................. 86 150

11.2.1 Configuration Management Implementation........................................................... 87 151

11.2.3 The DARS Registration Process ................................................................................ 88 152

11.3 Configuration Control Board (CCB................................................................................. 88 153

11.4 Technical Working Groups (TWGs)................................................................................ 88 154

12. RELATIONSHIPS TO OTHER ARCHITECTURE FRAMEWORKS/ 155

REFERENCE DOCUMENTS................................................................................................... 89 156

12.1 Frameworks......................................................................................................................... 89 157

12.1.1 Federal Enterprise Architecture (FEA) Program ................................................... 89 158

12.1.2 The Zachman Framework ......................................................................................... 89 159

12.1.3 The Open Group Architecture Framework (TOGAF) ........................................... 89 160

12.1.4 The Ministry of Defense Architecture Framework (MODAF)............................... 90 161


vi DRAFT


12.1.5 NATO Architecture Framework (NAF) ................................................................... 90 162

12.2 Other Reference Documents ............................................................................................. 90 163

APPENDIX A ACRONYMS ...................................................................................................... 1 164


vii DRAFT


TABLE OF FIGURES 165

166

167

To be provided 168


1 DRAFT


DOD ARCHITECTURE FRAMEWORK VERSION 2.0 169

170

EXECUTIVE SUMMARY 171 172

The DoD Architecture Framework (DoDAF), Version 2.0 serves as the overarching, 173

comprehensive framework and conceptual model enabling DoD managers at all levels to make 174

key decisions more effectively through organized information sharing across Department, Joint 175

Capability Areas (JCAs), Mission, Components and Program boundaries. DoDAF serves as one 176

of the pillars that support the responsibilities of the Department of Defense Chief Information 177

Officer (DoD CIO) in development and maintenance of architectures required under the Clinger-178

Cohen Act. It also reflects guidance from OMB Circular A-130, and other Departmental 179

directives and instructions. This version of the Framework provides extensive guidance on 180

development of architectures supporting the adoption and execution of Net-centric services 181

within the Department. 182

183

DoD managers, as process owners, specify the requirements, and control the development of 184

architectures, as described in this volume, within their areas of authority and responsibility. In 185

that role, they select an architect, and an architecture development team to create the architecture 186

in accordance with the requirements defined by the manager (process owner). As described in 187

Volume 1, architecture concentrates on those data that correspond to architecture requirements. 188

189

The duties of the architect, and the architecture team that create the architecture, are further 190

described in Volume 2 of DoDAF. The architect supervises development of the architecture, and 191

ensures that the requirements and visual representations of the architecture meet process owner 192

requirements. 193

194

DoDAF 2.0 focuses on architecture data, rather than on developing individual products. Data 195

can be collected, organized, and stored by a wide range of architecture tools developed by 196

commercial sources and organized using the DoDAF Meta-model (DM2)... A 'Data Capture 197

Method' for each data group of the DM2 is provided in Volume 2 to guide architects in collecting 198

and organizing the necessary architecture data. 199

200 201


2 DRAFT


202 The framework enables architecture content to be built that is “Fit for Purpose”, defined and 203

described in Volume 1 as architecture, which is consistent with specific project or mission 204

objectives. Because architecture can be applied at myriad levels of an enterprise, the purpose or 205

use of architecture at each level will be different in content, structure, and level of detail. In 206

order to ensure that architecture meets program and mission objectives, the approach to 207

architecture development must be tailored to address a specific, well-articulated, and understood 208

purpose. This will help to ensure that necessary data collection, to an appropriate level of detail, 209

is undertaken, completed, and supportive of specific decisions or objectives. 210

211

DoDAF also serves as the principal guide for development of integrated architectures as defined 212

in DoD Instruction 4630.81, which defines an integrated architecture as “An architecture 213

consisting of multiples views or perspectives facilitating integration and promoting 214

interoperability across capabilities and among integrated architectures”. The term integrated 215

means that data required in more than one instance in architectural views is commonly 216

understood across those views. 217

218

The DoDAF Meta-model provides information needed to collect, organize, and store data in an 219

easily understandable way, and the presentation description of various types of views in Volumes 220

1 & 2 provide the guidance on how to develop graphical representations of that data that will be 221

useful in defining acquisition requirements under the DOD Instruction 5000-series. 222

1 Department of Defense Instruction 4630.8, Procedures for Interoperability and Supportability of Information Technology (IT)

and National Security Systems (NSS) 30 June 2004. Office of the Assistant Secretary of Defense (Networks & Information

Integration) (NII)/ DoD Chief Information Officer (DoD CIO). The current version is found at: www.dtic.mil/whs/directives/corres/pdf/463008p.pdf

DoDAF conformance is achieved when:

- The data in a described architecture is defined according to the DoDAF Meta-model

concepts, associations, and attributes. Appendix B, "DoDAF View Support"

- Architecture Data is registered in the DoD Metadata Registry (DMR);

The Architecture Overview and Summary Information Document (AV-1) is registered in

DARS, and

- The architecture data capable of transfer in accordance with the PES.

-The mapping of the DoDAF Meta-model Concepts, Associations, and Attributes to each

DoDAF View is listed in Table B-2, " DM2 Concepts (Classes, Aliases, and Composite

Terms) Mapping to DoDAF Views" in Volume 2,


3 DRAFT


223 DoDAF 2.0 is a marked change from earlier versions of either C4ISR or DoDAF, in that 224

architects now have the freedom to create enterprise architectures to meet the demands of their 225

customer requirements. The central core of DoDAF v2.0 is a data-centric approach where the 226

creation of architectures to support decision-making is secondary to the collection, storage, and 227

maintenance of data needed for efficient and effective decisions. The architect and stakeholders 228

select views to ensure that architectures will explain current and future states of the process or 229

activity under review. Selecting architecture views carefully ensures that the views adequately 230

explain the requirement and proposed solution in ways that will enhance audience understanding. 231

DoDAF 2.0 provides two types of views. DoDAF-described Views are created from the subset 232

of data for a particular purpose and are fully explained in DoDAF. These views are useful as 233

examples for presentation purposes, and can be used as described or modified as needed. Fit-234

for-Purpose Views are user-defined views of a subset of architecture data created for some 235

specific purpose. While these views are not described or defined in DoDAF, they can be created, 236

as needed, to ensure that presentation of architecture data is easily understood within an agency. 237

This enables agencies to use their own established presentation preferences in their deliberations. 238

239

240

241 DoDAF 2.0 provides, but does not require, a particular methodology in architecture 242

development. Volume 1 contains numerous examples of how to utilize the DoDAF methodology 243

either alone, or in conjunction with other methods. Volume 1 provides guidance and suggestions 244

on how to ensure that other proposed methods can be adapted as needed to meet the DoD 245

requirements for data collection and storage. Similarly, the views presented in DoDAF are 246

examples, intended to serve as a possible visualization of a particular view. DoDAF 2.0 also 247

continues to provide support for views (i.e. ‘products’) developed in previous versions of the 248

Framework. These views do not require any particular graphical design by toolset vendors. 249

250

The DoDAF Meta-model (DM2) replaces the Core Architecture Data Model (CADM)

which supported previous versions of the DoDAF. DM2 is a data construct that

facilitates reader understanding of the use of data within an architecture document.

CADM can continue to be used in support of architectures created in previous

versions of DODAF.

The Views described in DoDAF, including those that are legacy views from previous

versions of the Framework, are provided as pre-defined examples that can be used

when developing presentations of architecture data. DoDAF does not prescribe any

particular views, but instead concentrates on data as the necessary ingredient for

architecture development. However, other regulations and instructions from both

DoD and CJCS have particular presentation view requirements. These views are

supported by DoDAF 2.0, and should be consulted for specific view requirements.


4 DRAFT


DoDAF 2.0 is composed of three volumes, along with an electronic DoDAF Journal hosted on 251

Defense Knowledge Online, https://www.us.army.mil/suite/page/454707. Together, these 252

volumes provide a resource that enables users to access the DoD’s entire body of knowledge 253

associated with architecture. 254

255

• Volume 1 provides general guidance for development, use, and management of DoD 256

architectures. This volume is designed to help non-technical users understand the role of 257

architecture in support of major decision support processes. Volume 1 provides a six-258

step methodology (Section 7) that can be used to develop architectures at all levels of the 259

Department, and a Conceptual Data Model (CDM) (Section 9) for organizing data 260

collected by an architecture effort. 261

• Volume 2 describes the construct of architectures, data descriptions, data exchange 262

requirements, and examples of their use in developing architectural views in technical 263

detail, to include the development and use of service-oriented architectures in support of 264

Net-centric operations. Volume 2 provides a Logical Data Model (LDM), based on the 265

CDM, which describes and defines architecture data; further describes the methods used 266

to populate architecture views, and describes how to use the architecture data in DoDAF-267

described views, or in developing Fit-for-purpose Views that support decision-making. 268

269

• Volume 3 relates the CDM structure with the LDM relationships, associations, along 270

business rules described in Volume 2 to introduce a Physical Exchange Specification 271

(PES), which provides the constructs needed to enable exchange of data among users 272

and COIs. NOTE: DoDAF 2.0 does NOT prescribe a Physical Data Model (PDM), 273

leaving that task to software developers who will implement the principles and practices 274

of DoDAF in their own software offerings. 275

276

• The DoDAF Journal, https://www.us.army.mil/suite/page/454707, is the electronic 277

interface for DoDAF support. The DoDAF Journal provides a place for submitting future 278

change requests to DoDAF or the DM2 (Section 9); provides examples referenced in the 279

various DoDAF volumes, and includes descriptions of other best practices, lessons 280

learned, and reference documents that supplement the information contained in the three 281

volumes of DoDAF V2.0, including: 282

283

• DoDAF Architecture Development Process for the Models 284

• DoDAF Product Development Questionnaire Analysis Report 285

• DoDAF V2.0 Meta-model Data Dictionary 286

287

288

In DoDAF 2.0, examples provided lean heavily on the major areas of change within the 289

Department, including the Joint Capabilities Integration and Development System (JCIDS), the 290

Defense Acquisition System (DAS), Systems Engineering (SE), the Planning Programming, 291

Budgeting, and Execution (PPBE) Process, and Portfolio Management (PfM). These major 292

processes produce far-reaching change across all Military Departments, Agencies, The Joint 293

Staff, and other Departmental functions. Architectures developed utilizing the guidance in 294


5 DRAFT


DoDAF demonstrate how change is documented and executed through an architecturally based 295

approach that: 296

297

• Establishes and documents scope and boundaries. 298

• Documents best practices. 299

• Defines and describes generic performance metrics. 300

• Documents and describes potential solutions for management review and approval. 301

302

DoDAF 2.0 is organized to facilitate the organization, and maintenance of data collected in an 303

architectural development effort. This approach responds to Departmental programs, such as 304

BTA, JCIDS, and other major functions with significant impact throughout the Department that 305

have developed requirements for multiple, custom views beyond the customary operational, 306

systems, and technical views contained in previous versions of DoDAF, and is also consistent 307

with DODI 4630.8 requirements for integrated architectures. These customized views, and the 308

models that utilize the data, enable the architecture information to be communicated to, and 309

understood by, stakeholders in diverse functional organizations. Products developed under 310

previous versions of DoDAF continue to be supported, as described in Volume 2. 311

312

313

DoDAF data can be collected, organized, and stored by a wide range of architecture tools

developed by commercial sources. Visualization of views in DoDAF 2.0 is for illustration

purposes only. There may be multiple techniques that can be employed create

architectural models in differing views.


6 DRAFT


VOLUME 1 – INTRODUCTION, OVERVIEW, AND CONCEPTS 314

315

316

1. INTRODUCTION 317 318

DoDAF Version 2.0 is the overarching, comprehensive framework and conceptual model 319

enabling DoD managers at all levels to make key decisions more effectively through organized 320

information sharing across Department, Joint Capability Areas (JCAs), Components and 321

Program boundaries. DoDAF 2.0 focuses on architecture data as information required by key 322

DoD decision makers, rather than on developing individual products. The framework also 323

enables architecture content to be built that is 'Fit for Purpose', as defined and described in 324

Section 1.4. DoDAF is one of the pillars that support the responsibilities of the Department of 325

Defense Chief Information Officer (DoD CIO) in development and maintenance of architectures 326

required under the Clinger-Cohen Act. it also includes guidance from OMB Circular A-130, and 327

appropriate Departmental directives and instructions; This version of the Framework also 328

provides guidance on the development of architectures supporting the development of Net-329

centric services within the Department. 330

331

DoDAF also serves as the principal guide for development of integrated architectures, as defined 332

in DoD Instruction 4630.82, which states: “An architecture consisting of multiples views or 333

perspectives facilitating integration and promoting interoperability across capabilities and 334

among integrated architectures”. The term integrated means that data utilized in more than one 335

instance in the architectural views is commonly understood across those views. 336

337

The Office of Management and Budget (OMB) annually evaluates agency efforts to improve 338

performance in strengthening the quality and usefulness of information technology investments 339

requested by agencies through well-organized strategic decisions relating to investments and 340

portfolio management. This process evaluates the use of enterprise and segment architectures, 341

discussed in Section 3 of this document, as a principal means of ensuring that mission 342

requirements are met, while savings and cost avoidance goals are achieved. Each agency is 343

required to adopt an architecture framework—either existing or created within the agency for 344

that purpose. DoDAF is the designated architecture framework with the DoD for architecture 345

development. 346

347

The DoDAF Meta-model (DM2) is a data model that provides information needed to collect, 348

organize, and store data or derived information in an easily understandable way. The 349

descriptions of DoDAF-described Views in Volumes 1 & 2 provide guidance on how to develop 350

graphical representations of that data and derived information that will be useful in defining 351

acquisition requirements under the DoD Instruction 5000-X series. 352

353

2 Department of Defense Instruction 4630.8, Procedures for Interoperability and Supportability of Information Technology (IT)

and National Security Systems (NSS) 30 June 2004. Office of the Assistant Secretary of Defense (Networks & Information

Integration) (NII)/ DoD Chief Information Officer (DoD CIO). The current version is found at: www.dtic.mil/whs/directives/corres/pdf/463008p.pdf


7 DRAFT


354

DoD managers, as process owners and/or decision-makers, specify the requirements, and control 355

the development of architectures, as described in this volume, within their areas of authority and 356

responsibility. In that role, they select an architect, and an architecture development team to 357

create the architecture in accordance with the requirements defined by the manager (process 358

owner). As described in Volume 1, the architecture concentrates on those data that correspond to 359

architecture requirements. 360

361

The duties of the architect and the architecture team that create the architecture are supported 362

through Volume 2 of DoDAF. The architect supervises development of the architecture, and 363

ensures that the requirements and visual representations of the architecture meet process owner 364

requirements. 365

366

367

1.1 Vision for DoDAF 2.0. The vision for utilization of DoDAF is to: 368

• 369

• Provide an overarching set of architecture concepts, guidance, best practices, and 370

methods to enable and facilitate architecture development in support of major decision 371

support processes across all major Departmental programs, Military components, and 372

Capability areas that is consistent and complementary to Federal Enterprise Architecture 373

Guidance, as provide by OMB.. 374

375

• Support the DoD CIO in defining and institutionalizing the Net-Centric Strategy of the 376

Department, to include the definition, description, development, and execution of Net-377

Centric Directory Services (NCDS) and Net-Centric Support Services (NCSS) through 378

introduction of Service-oriented Architecture Development. 379

380

• Focus on architecture data as information required for making critical decisions rather 381

than emphasizing individual architecture products. Enable architects to provide 382

visualizations of the derived information through combinations of DoDAF-described 383

Views, and Fit-for-purpose Views commonly used by decision-makers, enabling 384

flexibility to develop those views consistent with the culture and preferences of the 385

organization. 386

387

• Provide methods and suggest techniques through which information architects and other 388

developers can create architectures responsive to and supporting Departmental 389

management practices. 390

391

1.2 DoDAF 2.0 Organization and Intended Audience 392 393

DoDAF 2.0 is presented in three volumes, along with an electronic DoDAF Journal, 394

https://www.us.army.mil/suite/page/454707. Together, these volumes provide a resource that 395

enables users to understand and access DoD’s entire body of knowledge associated with 396

architecture. 397

398


8 DRAFT


DoDAF Volume 1 – Introduction, Overview, and Concepts. [Primary audience: 399

Executives, Project Directors, & Managers] Volume 1 introduces DoD architecture concepts 400

and provides general guidance for development, use, and management of DoD architectures. 401

This volume is intended to help non-technical users understand the role of architecture in support 402

of major decision support processes. Volume 1 provides a six-step methodology (Section 7) that 403

can be used to develop architectures at all levels of the Department, and a Conceptual Data 404

Model (CDM) (Section 9) for organizing data and derived information collected by an 405

architecture effort. 406

Volume 1 contains the following resources: 407

• An Overview and Vision for DoDAF (Section 1) 408

• Defining ‘Fit for Purpose” Architectures (Section 2) 409

• An overview of the Framework, DoDAF-based architecture development guidelines, and 410

the historical background for DoDAF (Section 3) 411

• An Introduction to Enterprise Architecture, Federated Architecting, and Architecture 412

enterprise Services, and an introduction to the Federal Enterprise Architecture published 413

by the Office of Management and Budget (OMB) (Section 4) 414

• An overview for architecture planning (Section 5) 415

• Addressing Customer requirements in architecture development (Section 6) 416

• Methodology for architecture development (Section 7) 417

• Presentation methods and graphical views (Section 8) 418

• The DoDAF Meta-model Conceptual View (Section 9) 419

• Analytics in support of architecture-based management analysis (Section 10) 420

• Guidance on configuration management of architectures, and the CM process for DoDAF 421

(Section 11) 422

• Inter-relationships among DODAF and other architecture frameworks (Section 12) 423

424

DoDAF Volume 2 – Architecture Data & Views. [Primary Audience: architects, program 425

managers, portfolio managers, and other technically oriented architecture users] Volume 2 426

describes the Meta-model data groups, and their associated views, introduced in Volume 1, from 427

a technical viewpoint. 428

429

Volume 2 is organized as follows: 430

• Introduction (Section 1) 431

• Meta-model Data Groups (Section 2). Twelve data groups are described in Volume 2, 432

and each is defined by the following attributes: 433

434

o Associated Data 435

o Data Collection Method 436

o Use 437

• DoD Architecture Framework Viewpoints and Views (Section 3) 438

439


9 DRAFT


Appendices contain acronyms, DoDAF Model Support, and references. Volume 2 references the 440

DoDAF Journal for the “DoDAF V2.0 Meta-model Data Dictionary” which describes the 441

DoDAF Logical Data Model (LDM), and the “DoDAF Architecture Development Process for 442

the Models”. The LDM provided introduces the relationships and associations needed by data 443

modelers and technical designers. 444

445

DoDAF Volume 3 – DoDAF Meta-model Physical Exchange Specification. Volume 3 relates 446

the CDM structure, LDM relationships, associations, and business rules as described in Volume 447

2 to introduce a Physical Exchange Specification (PES), which provides the constructs needed 448

to enable exchange of data and derived information among users and COIs. 449

450

451 DoDAF Journal. The DoDAF Journal, https://www.us.army.mil/suite/page/454707, is the 452

electronic interface for DoDAF support, provides a place for submitting future change requests 453

to DoDAF or the DoDAF Meta-model, and provides the examples referenced in the various 454

DoDAF volumes. The Journal also includes descriptions of other best practices, lessons 455

learned, and reference documents that supplement the information contained in the three 456

volumes of DoDAF 2.0. The Journal has two parts: 457

458

• Part 1 describes the DoDAF Configuration Management Process, and provides the 459

means to submit, review, and comment on the adjudication of formal changes to DoDAF. 460

This part is intended to apply to all audiences who would like to propose changes to and 461

keep up to date with the details of the DoDAF. 462

463

• Part 2 is a reference of best practices, examples, and templates, which can be used in 464

projects where DoDAF is used to develop and execute process change through 465

architecture development. This part is geared to architects, developers, program 466

managers, and portfolio managers. Part 2 is organized in the same structure as the 467

Volumes of DoDAF. 468

469

A quick reference guide and tutorial on the use of DoDAF and the DoDAF Journal is also under 470

development. 471

472

1.3 Purpose and Scope 473 The DoDAF provides the guidance needed to establish a common vocabulary for architecture 474

development, for the exchange of architecture information, and for facilitating interoperability 475

between architecture descriptions.” Architectures are created for a number of reasons. From a 476

compliance perspective, DoD development of architectures is compelled by law and policy (i.e., 477

Clinger-Cohen Act, Office of Management, and Budget (OMB) Circular A-130). From a 478

practical perspective, the management of large organizations employing sophisticated systems, 479

technologies, and services in pursuit of often complex joint missions demands a structured, 480

NOTE: DoDAF 2.0 does NOT prescribe a Physical Data Model (PDM), leaving that

task to the software developers who will implement the principles and practices of

DoDAF in their own software offerings.


10 DRAFT


repeatable method for evaluating investments and investment alternatives, as well as the ability 481

to implement organizational change effectively, create new systems, deploy new technologies, 482

and offer services which add value to management decisions and practices. 483

484 Guidance provided by DoDAF 2.0 applies to all architectures developed, maintained, and used 485

within the DoD. The DoDAF also provides the foundational constructs to support the concept of 486

architecture federation at each tier, and enables the sharing of all pertinent architecture 487

information. This in turn permits creation of the federated version of the DoD Enterprise 488

Architecture. DoDAF 2.0 provides guidance in all areas of architecture lifecycle, consistent with 489

both DoD and OMB Guidance (i.e. Development, Maintenance, and Use of Architectures)3. 490

491

DoDAF 2.0 also supports the concept of Service-oriented Architecture (SOA) development. 492

Volume 1 provides management guidance on development of architecture views, based on 493

service requirements. Volume 2 provides technical information needed, data views, and other 494

supporting resources for development of SOA-based architectures. 495

496

1.3.1 Developing Architectures. Careful scoping and organization of the architecture 497

development effort focuses on areas of change desired by executives and managers in support of 498

their stated goals and objectives. A data-centric, rather than product-centric, architecture 499

framework ensures concordance across architecture views (i.e. architecture integration), enables 500

the federation of all pertinent architecture information, and provides full referential integrity 501

through the underlying data to support a wide variety of analysis tasks. Architecture integration 502

thus becomes a critical ‘property’ of architectures of all types as described more fully below, and 503

must be included in architecture planning and development actions. 504

505

DoDAF 2.0 describes several types of architectures that contribute to the DoD Enterprise 506

Architecture. Each of these architectures serves a specific purpose, as described briefly below, 507

and in more detail in Section 4 of Volume 1. Architecture types correspond to the tiers defined 508

in the DoD Architecture Federation Strategy. 509

510

Department-level Architecture is that type of architecture that describes processes applicable to 511

the Department and Joint Staff as a whole. These architectures include the Global Information 512

grid Architecture (GIG), the DoD Information Enterprise Architecture (DOD IEA). 513

514

Capability Architectures are those types of architectures that define and describe specific 515

capabilities required by the Department for business, procurement, and tactical operations. The 516

capability architecture is considered segment architecture, as defined in OMB Circular A-130. 517

518

Component Architectures are that type of architecture that describe and define the military 519

services and their internal business and operational functions. 520

3 Office of Management and Budget (OMB) Circular-A-130, Management of Federal Information Resources, February 8, 1996.

Executive Office of the President., Office of Management and Budget. The current version can be found at:

http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html#2


11 DRAFT


521

Solutions Architectures are those type of architecture that define a particular project o create, 522

update, revise, or delete established activities in the Department. Solution architecture may 523

transcend one or more of the other architecture types. A Solution Architecture is the most 524

common type of architecture developed in the Department. Solution architectures include those 525

service-oriented architectures (SOA) developed in support of specific data and other services 526

solutions. 527

528

Architecture data and derived information can be collected, organized, and stored by a wide 529

range of tools developed by commercial sources. Creation of various views using these 530

architecture tools is the typical way an enterprise architect initially captures and represents 531

important architecture data. Both DoDAF-described views, and Fit-for-purpose views (e.g. 532

dashboards, composite, or fusion presentations) created as a part of the architecture development 533

process, which visually render the underlying architecture data, act to facilitate management 534

decisions. 535

536

537 1.3.2 Maintaining and Managing Architectures. Embedding the architecture 538

development process in routine planning and decision-making institutionalizes the practice and 539

makes its maintenance more automatic. Architectures are maintained and managed within the 540

Department through tiered accountability. Tiered accountability is the distribution of authority 541

and responsibility for development, maintenance, configuration management, and reporting of 542

architectures, architecture policy, tools, and related architecture artifacts to all four distinct tiers 543

within the DoD. DoDAF 2.0 supports four tiers: Department, Joint Capability Area (JCA), 544

Component, and Solution. These tiers support the federated approach to architecture 545

development and maintenance descried more fully in the DoD Architecture Federation Manual4. 546

547

1.3.3 Using Architectures. Architectures are used to support DoD decision-making 548

processes including JCIDS, DAS, PPBE, SE, and PfM processes. Other major Departmental 549

processes supported are business process reengineering, organizational development, research 550

and development, operations support, and service-oriented solutions. Architecture data and other 551

4 Department of Defense Manual 8210-11-M, DoD Architecture Federation Manual, dated (DRAFT) XX-XX-200X Office of

the Assistant Secretary of Defense (Networks and Information Integration) (NII)/ DoD Chief Information Officer (DoD CIO)..

The Views described in DoDAF, including those that are legacy views from previous

versions of the Framework, are provided as pre-defined examples that can be used

when developing presentations of architecture data. DoDAF does not prescribe any

particular views, but instead concentrates on data as the necessary ingredient for

architecture development. However, other regulations and instructions from both

DoD and CJCS have particular presentation view requirements. These views are

supported by DoDAF 2.0, and should be consulted for specific view requirements.


12 DRAFT


derived information, based on process-owner or stakeholder input and review, provides decision 552

makers with information necessary to support specific decisions in those processes. 553

554

1.3.4 DoDAF Conformance. DoDAF conformance is achieved when the content of a 555

described architecture is defined according to the DM2 Concepts, Associations, and Attributes 556

for the appropriate DoDAF Views. The mapping of the DM2 Concepts, Associations, and 557

Attributes to each DoDAF View is listed in Table B-2, " DM2 Concepts (Classes, Aliases, and 558

Composite Terms) Mapping to DoDAF Views" in Volume 2, Appendix B, "DoDAF View 559

Support" 560 561 562

1.4 What is New in Volume 1. 563 564

The major changes for DoDAF Version 2.0 Volume 1 are: 565

• The major emphasis on architecture development has changed from a product-centric 566

process to an information-centric process designed to provide decision-making data 567

organized as information for the manager 568

• The three major views of architecture described in previous version (e.g. Operational, 569

technical, and System) have been changed to more specific views that relate to the 570

collection of architecture-related data that can be organized as useful information for the 571

manager in decision-making. 572

• ‘Products’ have been replaced by ‘views’ that represent specific types of presentation for 573

architecture data and derived information. 574

• The Department initiatives for Architecture Federation and Tiered Responsibility have 575

been incorporated into Version 2.0. 576

• Requirements for sharing of data and derived information in a Federated environment are 577

described. 578

• Specific tiers of architecture within the Department have been identified and described 579

(e.g. Department, Segment/Capability, Component and Solution) 580

• The DoD Enterprise Architecture is defined and described. 581

• Linkages to the Federal Enterprise Architecture are defined and described. 582

• Architecture constructs originally described in the Ministry of Defense (UK) Architecture 583

Framework (MODAF), the NATO Architecture Framework (NAF), and the Open Group 584

Architecture Framework (TOGAF) are adopted for use within DoDAF. 585

• A New DoDAF Meta-model (DM2), containing a Conceptual Data Model, a Logical 586

Data Model, and a Physical Exchange Specification has been created. 587

• Examples of graphical representations (DoDAF-described Views) have been provided as 588

examples to assist managers in determining how architecture data and other derived 589

information can be utilized in decision-making. Information is also provided on 590

development of Fit-for-purpose Views, which are user-defined views representing 591

specific desired presentations. 592

• Approaches to service-oriented architecture development are described and discussed. 593

594


13 DRAFT


1.5 What DoD Managers and Executives Need to Know about DoDAF. 595

596

Architecture development is a management tool that supports the decision-making process. 597

A Process owner (An executive responsible for a specific process or program) has the direct 598

responsibility for ensuring that a particular process or program works efficiently, in 599

compliance with legal and departmental requirements, and serves the purpose for which it 600

was created. Periodically this means that review and evaluation of the efficiency of the 601

program or process is required. Those requirements for review, to include those detailed 602

in legislation such as the Clinger-Cohen Act and OMB Directive A-130, include the need to 603

create or update an information architecture supporting any budget requests for funding 604

of those projects and processes. 605

606

While a manager or executive may delegate the responsibility for creation of the 607

architecture to an architect with the professional qualifications needed, along with an 608

architecture development team. However, that delegation of authority does not alter the 609 continuing responsibility of the executive or manager As described throughout this volume, 610

the decision-maker needs to be actively involved in the architecture development process and 611

support architecture description development. Active Involvement means that the decision-612

maker: 613

• Identifies the Purpose and Scope for the Architecture. The 6-Step Architecture 614

Development Process (depicted in Section 7.1.1. "6-Step Architecture Development 615

Process") provides a structure for development of scope and purpose. 616

• Transmits to the Architect and Development Team the scope and purpose of the 617

architecture effort, along with those goals and objectives that support the need. 618

• In conjunction with the Architect, identifies the general data categories needed for 619

architecture development; assist in data collection and validation 620

• Determines desired views and presentation methods for the completed architecture 621

• Meets frequently with the Architect and Development Team to ensure that the 622

development effort is on target (i.e. is ‘Fit for Purpose’) and provides new direction, as 623

required to ensure that the development effort meets established requirements. 624

625

626 627

Figure 1.5-1: What the decision-maker needs to do 628

Figure 1.5-1 is a more detailed view of the 6-Step Architecture Process, and depicts the

sub-steps that the decision-maker needs to perform in coordination with the Architect within

the Six-Step Architecture Development Process described in Section 7. In each step, the

'Meta-model Groups' referred to by the step is that data in the Meta-model Groups in DM2

described in this volume, and more technically in Volume 2.


14 DRAFT


629 The detailed steps for the decision-maker are: 630

631

• Step 1: Review the Purpose and Scope with the Architect. In order for the architecture to 632

be “Fit-for-purpose”, the decision-maker needs to provide the list of data needed and the 633

usage of the data (use-cases) to the Architect. The decision-maker, not the Architect, is 634

the subject matter expert for the problem to be solved, the decision to be made, or the 635

information to be captured and analyzed. The architect is the technical expert who 636

translates the decision-maker’s requirements into views representing proposed solutions. 637

Determining the data needed and the use-cases (requirements) to be applied is an 638

important responsibility for the decision-maker and cannot be delegated to the Architect. 639

640

• Step 2: Review the Views, Concepts, Associations, and Attributes the Architect has 641

determined that meets the data requirements and use-cases. The Models, Concepts, 642

Associations, and Attributes required are determined in the Architect’s detailed process 643

(Step 3.2) described in Section 1.6 of Volume 2. 644

Figure 1.5-1: What the DoD manager needs to do


15 DRAFT


645

• Step 3: Assist with data collection, or provide the data needed using the architecture 646

collection method described in the Architect’s detailed process (Step 3.5) found in 647

Section 1.6 of Volume 2 In that step, the Architect determined the appropriate collection 648

methods for the “Fit-for-Purpose” needs. Section 2 of Volume 2 contains a “Method” 649

subsection for each of the Meta-model groups, which provides potential collection 650

methods.. Step 3 includes those actions taken to ensure that data integration occurs 651

across all views created as a part of the architecture development effort. 652

653

• Step 4: Verify that the data collected meets the need described in use-cases to support the 654

analysis that will be performed in Step 5 of the 6-Step Architecture Development Process 655

The Architect has collected the architecture data that will meet the decision-maker’s 656

purpose (“Fit-for-Purpose”) and support the decision review processes. Section 2 of 657

Volume 2 contains a “Use” subsection for each of the Meta-model groups, which 658

provides example uses. . 659

660

• Step 5: Determine the appropriate views for the “Fit-for-Purpose” needs and support to 661

decision deliberations. Volume 2, Section 3 contains a “DoD Architecture Framework 662

Viewpoints & Views” subsection which describes each of the DoDAF-described Views. 663

This step results in presentation creation in Step 6 of the 6-Step Architecture 664

Development Process. 665

666

Working with the Architect and team, the decision-maker has a critical role in ensuring that the 667

architecture not only supports the creation of executable requirements that will achieve the 668

desired outcome, but also that senior executives and managers can view the desired solution in 669

an understandable and logical manner. 670

671

672

2. SCOPING ARCHITECTURES TO BE “FIT FOR PURPOSE” 673 674

Establishing the scope of an architecture is critical to ensuring that its purpose and use are 675

consistent with specific project goals and objectives. The term “Fit for Purpose” is used in 676

DoDAF to describe an architecture (and its views) that is appropriately focused (i.e. responds to 677

the stated goals and objectives of process owner, is useful in the decision-making process, and 678

responds to internal and external stakeholder concerns. Meeting intended objectives means those 679

actions that either directly support customer needs or improve the overall process undergoing 680

change. At each tier of the DoD, goals and objectives, along with corresponding issues that may 681

exist should be addressed according to the established scope and purpose, (e.g. Departmental, 682

Capability, Systems Engineering, and Operational), as shown in the notional diagram in Figure 683

2-1. 684

685


16 DRAFT


DOTMLPF changes

Strategic PlansGIG Arch VisionNC Data Strategy

NC Services StrategyNC IA Strategy

JDF/Planning Guidance

Portfolios,Increments

POM

PPBE

DAS

PlanningPlanning

Requirements,

JCIDS

Requirements,

JCIDS

DoD Decision-MakingActivities

Direction, GuidanceImpact, Results

Joint Ops ConceptsCONOPS

…

Operational Systems

Programs

Str

ate

gic

Op

era

tio

na

l

DepartmentLevel

Capability

Level(supports PfM)

8115CPMsICPs

Systems

Architecting(supports

PEOs/PMs)

Architecture & EngineeringScope and Focus

En

terp

rise

Arc

hit

ec

ture

-E

nte

rpris

e-w

ide

Syste

m E

ng

ine

erin

g

Warfighterand other users

Mission Effectiveness

MissionOperations

and Support

DOTMLPF changes

Strategic PlansGIG Arch VisionNC Data Strategy

NC Services StrategyNC IA Strategy

JDF/Planning Guidance

Portfolios,Increments

POM

PPBE

DAS

PlanningPlanning

Requirements,

JCIDS

Requirements,

JCIDS

DoD Decision-MakingActivities

Direction, GuidanceImpact, Results

Joint Ops ConceptsCONOPS

…

Operational Systems

Programs

Str

ate

gic

Op

era

tio

na

l

DepartmentLevel

Capability

Level(supports PfM)

8115CPMsICPs

Systems

Architecting(supports

PEOs/PMs)

Architecture & EngineeringScope and Focus

En

terp

rise

Arc

hit

ec

ture

-E

nte

rpris

e-w

ide

Syste

m E

ng

ine

erin

g

Warfighterand other users

Mission Effectiveness

MissionOperations

and Support

686 Figure 2-1: Establishing the scope for architecture development 687

688 Establishing a scope for an architecture effort at any tier is similarly critical in determining the 689

architecture boundaries (Purpose and Use expected), along with establishing the data categories 690

needed for analysis and management decision-making. Scope also defines the key players whose 691

input, advice, and consensus is needed to successfully architect and implement change (i.e. 692

Stakeholders, both internal and external). Importantly, scope also determines the goals and 693

objectives of the effort, consistent with both boundaries and stakeholders; since goals and 694

objectives define both the purpose for architecture creation and the level of the architecture. 695

Establishing the scope of an effort also determines the level of complexity for data collection and 696

information presentation. 697

698

Architecture development also requires an understanding of external requirements that may 699

influence architecture creation. An architecture may be developed for an internal agency 700

purpose, and be consistent with and mappable to the DoD EA. To do so, consideration must be 701

given in data collection and graphical presentation to satisfaction of other external requirements, 702

such as upward reporting and submission of architecture data and models for program review, 703

funding approval, or budget review due to the sensitivity or dollar value of the proposed solution. 704

Volume 2 contains guidance on data collection for specific views required by instruction, 705

regulation, or other regulatory guidance (i.e. Exhibit 43/53, or 300 submission; interoperability 706

requirements, etc.). 707

708


17 DRAFT


Architecture scoping must facilitate alignment with, and support the decision-making process 709

and ultimately mission outcomes and objectives (Figure 2-2). Architecture data and supporting 710

views created from organizing raw data into useful information should enable domain experts, 711

program managers, and decision makers to utilize these architectures to locate, identify, and 712

resolve definitions, properties, facts, constraints, inferences, and issues both within and across 713

architectural boundaries that are redundant, conflicting, missing, and/or obsolete. DoDAF 2.0 714

provides the either flexibility to develop Fit-for-Purpose Views (User-developed Views) or 715

DoDAF-described Views to maximize the capability for decision-making at all levels. 716

717

Analysis also uncovers the effect and impact of change (“what if”) when something is redefined, 718

redeployed, deleted, moved, delayed, accelerated, or no longer funded. Having a disciplined 719

process for architecture development in support of analytics will produce quality results, not be 720

prone to misinterpretations, and therefore, be of high value to decision makers and mission 721

outcomes. 722

723

724

725 Figure 2-2: Mission Outcomes Supported by Architectures 726

727

728

729


18 DRAFT


3. DoDAF VOLUMES AND JOURNAL OVERVIEW 730 Section 3 provides an overview of DoDAF 2.0,both the volumes, and the electronic Journal, and 731

describes the primary reasons for developing and publishing a new version, while addressing 732

fundamental principles and guidelines that should be followed when an architecture development 733

effort is initiated. A graphical representation of the breadth and depth of information, users, 734

concepts, and artifacts that can assist in describing an architecture for executives, managers, and 735

other non-technical reviewers and users is also provided. 736

737

3.1 DoDAF Overview 738 739

DoDAF is the structure for organizing architecture concepts, principles, assumptions, and 740

terminology about operations and solutions into meaningful patterns to satisfy specific DoD 741

purposes. DoDAF offers guidance, principles and direction on communicating business, mission 742

needs and capabilities to managers, architects, analysts, and developers who are responsible for 743

developing and building the necessary services, applications and infrastructure to meet 744

stakeholder needs and to manage their expectations. 745

746

Architecture frameworks support change in organizations through building and utilization of 747

architectures that: 748

• Enhance decision making processes by leveraging knowledge and opportunities for reusing 749

existing information assets 750

• Respond to stakeholder, customer, and client needs for effective and efficient processes, 751

systems, services, and resource allocation 752

• Provide mechanisms to manage configuration of the current state of the enterprise and 753

maintain validity of the expected performance 754

• Facilitate the design of future states of the enterprise 755

756

In DoDAF 2.0, examples provided lean heavily on the major areas of change within the 757

Department, including the Joint Capabilities Integration and Development System (JCIDS), the 758

Defense Acquisition System (DAS), Systems Engineering (SE), the Planning Programming, 759

Budgeting, and Execution (PPBE) Process, and Portfolio Management (PfM). These ‘key’ 760

processes produce far-reaching change across all Military Departments, Agencies, The Joint 761

Staff, and other Departmental functions. Architectures developed utilizing the guidance in 762

DoDAF demonstrates how change is documented, and executed through an architecturally based 763

approach that: 764

765

• Establishes and documents scope and boundaries. 766

• Documents best practices. 767

• Defines and describes generic performance metrics. 768

• Documents and describes potential solutions for management review and approval. 769

770

Data, organized as information, is the critical element of architecture development. DoDAF 2.0 771

provides conceptual and logical data models, along with a Physical Exchange Specification for 772

use by data managers, tool vendors, and others to facilitate: 773


19 DRAFT


774

• Establishment of areas of discourse and a shared vocabulary. 775

• Support for data overlap analysis. 776

• Define and encourage the use of shared information. 777

• Provide a target for architecture data integration. 778

779

The framework is consistent with, and supports DoD policy directives that require programs and 780

components (a) to ensure that their architectures meet stated objectives and Departmental 781

requirements, and, (b) provide the information necessary to support defined decisions at higher 782

tiers. These policies also require consistency across horizontal architecture boundaries within a 783

tier. The guidance and information contained in these volumes also ensures that, when followed, 784

architecture development is consistent with OMB Enterprise Architecture Guidance. 785

786

This version of the DoDAF is written to support the Departmental preference for federated 787

architecture development in a tiered environment (Section 4.3). To enable federation and 788

facilitate tiered responsibility and accountability, the framework provides data structures to 789

ensure appropriate touch-points can be compared for consistency across architecture boundaries. 790

Utilization of these data structures ensures that higher tiers have access to data from lower tiers 791

in a form that supports their decision needs. The Framework also includes aids to architects in 792

supporting net-centricity in their architectures and structures that define the management of net-793

centric architectures (Volume 2). 794

795

DoDAF 2.0 also facilitates creation of Service-oriented Architectures (SOA) that define 796

solutions specifically in terms of services that can be discovered, subscribed to, and utilized, as 797

appropriate, in executing departmental or joint functions and requirements. 798

799

3.2 DoDAF Background 800

801 3.2.1 Authority: Law, Policy, and Historic Perspective. The Federal Government has 802

established the importance of using architecture through law, policy, and guidance. Federal law 803

and policies (Table 3.2.1-1), such as the Clinger-Cohen Act of 1996, the E-Government Act of 804

2002, and OMB Circular A-130, along with other guidance, have expressed the need for 805

architectures in support of business decisions. 806

807 Table 3.2.1-1: Federal Law and Policy 808

Policy/Guidance Description

Clinger-Cohen Act of

1996

Recognizes the need for Federal Agencies to improve the way they select

and manage IT resources and states, “information technology architecture,

with respect to an executive agency, means an integrated framework for

evolving or maintaining IT and acquiring new IT to achieve the agency’s

strategic goals and information resources management goals.” Chief

Information Officers are assigned the responsibility for “developing,

maintaining, and facilitating the implementation of a sound and integrated

IT architecture for the executive agency”. E-Government Act of

2002

Calls for the development of Enterprise Architecture to aid in enhancing the

management and promotion of electronic government services and


20 DRAFT


processes.

Office of

Management and

Budget Circular A-130

“Establishes policy for the management of Federal information resources”5

and calls for the use of Enterprise Architectures to support capital planning

and investment control processes. Includes implementation principles and

guidelines for creating and maintaining Enterprise Architectures.

OMB Federal Enterprise

Architecture

Reference Models

(FEA RM)

Facilitates cross-agency analysis and the identification of duplicative

investments, gaps, and opportunities for collaboration within and across

Federal Agencies.6 Alignment with the reference models ensures that

important elements of the FEA are described in a common and consistent

way.7 The DoD Enterprise Architecture Reference Models are aligned with

the FEA RM. OMB Enterprise

Architecture

Assessment

Framework (EAAF)

Serves as the basis for enterprise architecture maturity assessments.

Compliance with the EAAF ensures that enterprise architectures are

advanced and appropriately developed to improve the performance of

information resource management and IT investment decision making.

General Accounting

Office Enterprise

Architecture

Management

Maturity Framework

(EAMMF)

“Outlines the steps toward achieving a stable and mature process for

managing the development, maintenance, and implementation of enterprise

architecture.” Using the EAMMF allows managers to determine what steps

are needed for improving architecture management.

809

3.2.2 Historical Evolution of DoDAF. The Command, Control, Communications, Computers, 810

and Intelligence, Surveillance, and Reconnaissance (C4ISR) Architecture Framework v1.0, dated 811

7 June 1996, was created in response to the passage of the Clinger-Cohen Act. It replaced the 812

Technical Architecture for Information Management (TAFIM) and ensured that a DoD-wide 813

effort to develop a better means and process for ensuring that C4ISR capabilities were 814

interoperable and met the needs of the war-fighter. Version 2.0 of the C4ISR Framework was 815

published on 18 December 1997. 816

817

The DoD Architecture Framework (DoDAF) v1.0 30 August 2003 restructured the C4ISR 818

Framework v2.0 and broadened the applicability of architecture tenets and practices to all Joint 819

Capability Areas (JCAs) rather than just the C4ISR community. DoDAF v1.0 addressed usage, 820

integrated architectures, DoD and Federal policies, value of architectures, architecture metrics, 821

DoD decision support processes, development techniques, analytical techniques, and moved 822

towards a repository-based approach by placing emphasis on architecture data elements that 823

5 Office of Management and Budget (OMB) Circular-A-130, Management of Federal Information Resources, February 8, 1996.

Executive Office of the President., Office of Management and Budget. The current version can be found at:

http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html#2 6 Federal Enterprise Architecture (FEA). Executive Office of the President, Office of Management and Budget E-Gov Initiative. The current version of the FEA, and its associated reference models can be found at: http://www.whitehouse.gov/omb/egov/a-2-EAModelsNEW2.html 7 Federal Enterprise Architecture Consolidated Reference Model Version 2.0. Executive office of the President, Office of

Management and Budget (OMB). A current version can be found at:

http://www.whitehouse.gov/omb/egov/documents/FEA_CRM_v20_Final_June_2006.pdf


21 DRAFT


comprise architecture products. DoDAF v1.0 was supported by a Core Architecture Data Model 824

(CADM) which provided for data organization and sharing. 825

826

DoDAF v1.5, 23 April 2007, was a transitional evolution of the DoDAF v1.0, provided 827

additional guidance on how to reflect net-centric concepts within architecture descriptions, 828

included information on architecture data management and federating architectures through the 829

Department, and incorporated the pre-release CADM v1.5, a simplified model of previous 830

CADM. DoDAF 1.5 provided support for net-centricity concepts within the context of the 831

existing set of architecture views and architecture products. 832

833

DoDAF 2.0 expands the framework to capture architecture information about net-centricity, 834

support Departmental net-centric strategies, and describe service-oriented solutions that facilitate 835

the creation and maintenance of a net-centric environment. DoDAF 2.0 will continue to be 836

updated in the future as it improves its support for the increasing uses of architecture data and its 837

derived information to meet the growing needs of decision makers in a Net-Centric Environment 838

(NCE). 839

840

3.2.3 DoDAF Version 2.0 – The Need for Change. Over time, and as experience with 841

architecture has grown within the Department, it has become obvious that there are two types of 842

architectures. The first and most traditional type is the Program Level Architecture. This 843

architecture has been required, defined, and supported by major Departmental processes for 844

solution evaluation, interoperability, and resource allocation. Enterprise Architecture, the 845

second type of architecture, provides a roadmap for change as well as a context and reference for 846

how and where programs “fit” within a larger ‘enterprise’ picture. Because of the complex 847

structure and function of the DoD, an enterprise can be defined at the Department level, the JCA 848

level, and the Component level. These ‘tiers’ need architecture content at their level to guide and 849

direct their lower level mission requirements. The JCA and Component tiers are critical to 850

address the high-level capabilities and semantics of a specific JCA or Component within the 851

enterprise so that federation of individual architecture data is possible. 852

853

An architecture can represent either a current (i.e. ‘as-is’ or ‘baseline’) viewpoint, or a future, 854

desired (i.e. ‘to-be’) viewpoint. When the architecture is a baseline viewpoint, it should illustrate 855

the enterprise, or a portion of it, as it exists. The future state architecture depicts the changes that 856

are desired (whether operational, system/service-centric, or technology-driven), and the 857

strategies, programs and projects that are employed to achieve the desired transformation8. The 858

future view extends beyond details or summaries of operational and systems solutions, and 859

includes program plans, programmatic status reporting, financial and budget relationships, and 860

risk management assessments, along with a transition plan. 861

862 DoDAF v2.0 supports the development and use of both program and enterprise-wide 863

architectures to illustrate the context for solutions at the capability and component level, and/or 864

the interdependencies among the components. Future updates and revisions to DoDAF will 865

8 Derived from OMB Circular A-130 that an enterprise architecture consists of a baseline architecture, a target

architecture, and a transition strategy.


22 DRAFT


extend beyond the solution space to provide standard mechanisms for communicating program 866

plans, financial information, and project status. These future updates will more fully support the 867

ability of managers and executives to evaluate and direct their programs. Without such 868

standards, interdependent programs and projects will continue to be evaluated separately, and 869

managed as individual budgets and consequently as stovepipe solutions. Such an advance in 870

enterprise architecture would facilitate portfolio management as a whole, help ensure that 871

program direction is coordinated and accountable, and address impact and alternative analysis 872

across programmatic boundaries. 873

874 3.2.3.1 Architecture Focus. DoDAF 2.0 focuses on the use of architecture throughout the 875

various tiers of the department as they relate to operational and transformational decision-making 876

processes. Working directly with process owners, through a set of comprehensive workshops, to 877

validate and extend architecture data content, and provide meaningful and useful architecture 878

views for their decision-making, DoDAF 2.0 provides better harmonization of architecture 879

content and process requirements. Additionally, these tailored architectures can be shared and 880

provide insight into best practices that benefit programs, architects, and process owners. 881

Architecture data content also includes data defining generic performance metrics, capabilities, 882

and the relevant portfolio management data, all of which are analytically useful to process 883

owners and systems engineers. 884

885 3.2.3.2 Shifting from Product-Centric to Data-Centric Focus. Both the C4ISR and earlier 886

DoD versions of the Architecture Framework have emphasized reusable and interoperable data. 887

DoDAF 2.0 places maximum emphasis on utilizing architecture data to support analysis and 888

decision-making. With appropriate architecture data, it is possible to support innovative and 889

flexible presentation of the architecture data in a meaningful, useful, and understandable manner 890

through the views described in Volumes 1 and 2. 891

892

893

3.3 Assumptions. Development of DoDAF 2.0 is guided by several assumptions. These are: 894

• The DoDAF will continue to evolve to meet the growing needs of decision makers in a Net-895

Centric Environment (NCE). 896

• As capability development continues, and Infrastructure continues to mature, architectures 897

will increasingly be a factor in evaluating investments, development, and performance at the 898

various portfolio levels. 899

• As the DoD increases its use of architecture data and its derived information for decision-900

making processes, architects will need to understand how to aggregate the data as useful 901

information for presentation purposes at the enterprise level. 902

• The DoDAF plays a critical role in the development and federation of architectures. It will 903

continue to improve its support for the increasing uses of semantically linked and aligned 904

architecture data. 905

• Architecture data described in DoDAF is not all-inclusive. Architectures may require 906

additional data, and it is expected that architecture developers at all levels will extend the set 907

of architecture data as necessary. 908


23 DRAFT


• Prescription of required architect data sets or views to be included in an architecture is a 909

decision made by process owners based on the purpose of the architecture. Some specific 910

minimum architecture data will be described in DoDAF for the exchange of architecture data 911

in the federated environment, and will be included in the architect data set supporting 912

products required by the process owners. 913

914

3.4 DoDAF Structure and Views 915

916 DoDAF 2.0 is organized around data and views. This approach responds to Departmental 917

programs, such as Business Transformation (BT), JCIDS, and other major functions with 918

significant impact throughout the Department that have developed requirements for multiple, 919

custom views. These views use information based on authoritative data, beyond the operational, 920

systems, and technical views of previous versions of DoDAF, and is consistent with DoD 921

Instruction (DODI) 4630.8 requirements for integrated architectures. These customized views 922

enable the information contained in an architecture to be communicated to, and understood by, 923

stakeholders in diverse functional organizations. The products developed under previous 924

versions of DoDAF continue to be supported, as described in Volume 2. 925

926

A view is a representation of a related set of information. A viewpoint describes data drawn 927

from one or more perspectives and organized in a particular way useful to management 928

decision-making. More specifically, a viewpoint definition includes the information that should 929

appear in individual views; how to construct and use the views (by means of an appropriate 930

schema or template); the modeling techniques for expressing and analyzing the information; and 931

a rationale for these choices (e.g., by describing the purpose and intended audience of the 932

view).9 933

934

3.4.1 Architecture Data. Architecture data provides for more efficient and flexible use and 935

reuse of the architecture, enabling broader utility for decision makers and process owners. This 936

version of DoDAF emphasizes the collection, organization, and maintenance of architecture data 937

and derived information, as opposed to development of products in previous versions. A 938

technical description of the underlying data can be found in DoDAF Volume 2. 939

940

9 The Open Group Architecture Framework (TOGAF), Version 8.11 The current version can be found at:

http://www.opengroup.org/architecture/togaf/


24 DRAFT


941 942

3.4.2 Architecture Viewpoints. An architecture viewpoint is composed of a selected set of 943

architecture data that has been organized to facilitate visualization in an understandable way. An 944

architecture can be visualized in a number of formats, such as dashboard, fusion, textual, 945

composite, or graphics, which present data and derived information collected in the course of 946

architecture development. A viewpoint is only a presentation of a portion of the architecture 947

data, in the sense that a photograph provides only one view of the object within the picture, not 948

the entire representation of that object. Figure 2.5-1 provides a graphical representation of the 949

architecture viewpoints in DoDAF 2.0. 950

951

NOTE: DoDAF data can be collected, organized and stored by a wide range of

architecture tools developed by commercial sources. Visualization of views, as shown in

DoDAF 2.0 is for example purposes only. It should be understood, however, that the

creation of a limited set of models, using a range of architecture tools developed by

commercial sources, is the typical way an enterprise architect initially captures and collects

important architecture data. These models are commonly produced by architects.

Development of architecture views is accomplished by collecting and organizing

architecture data that must be clearly mapped to the underlying DoDAF Conceptual and

Logical Data Models in a standard and consistent way, in order to capture interoperable

architecture data, and to achieve the goal of a federated approach to architecture

management.

There is no single, correct way to visualize any view, although the examples present those

that are commonly used in the DoD communities. The critical factor in ‘conforming’ to

DoDAF practice is that the data represented by the graphical representation is consistent

with, or mappable to the DoDAF Conceptual and Logical Data models, and the Physical

Exchange Specification described in these volumes.

A View, as described in DoDAF 2.0, is a representation of data in any understandable

format. Formats can include any of the presentation styles (such as dashboards,

spreadsheets, diagrams, data models, etc) that convey the meaning of data.


25 DRAFT


952 Figure 3.4.2-1: Architecture Viewpoints in DoDAF 2.0 953

954

955 3.4.2.1 ALL Viewpoint (AV). Some overarching aspects of an architecture relate to all the 956

views. The AV products provide information pertinent to the entire architecture, such as the 957

scope and context of the architecture. The scope includes the subject area and time frame for the 958

architecture. The setting in which the architecture exists comprises the interrelated conditions 959

that compose the context for the architecture. These conditions include doctrine; tactics, 960

techniques, and procedures; relevant goals and vision statements; concepts of operations 961

(CONOPS); scenarios; and environmental conditions. 962

963

964

3.4.2.2 The Capability Viewpoint (CV). The CV captures the enterprise goals associated 965

with the overall vision for executing a specified course of action, or the ability to achieve a 966

desired effect under specific standards and conditions through combinations of means and ways 967

to perform a set of tasks. It provides a strategic context for the capabilities described by an 968

architecture, and an accompanying high-level scope, more general than the scenario-based scope 969

defined in an operational concept diagram. The views are high-level and describe capabilities 970

using terminology, which is easily understood by decision makers and used for communicating a 971

strategic vision regarding capability evolution. 972

973 3.4.2.3 The Data and Information Viewpoint (DIV). The DIV captures the business 974

information requirements and structural business process rules of the architecture. It describes 975


26 DRAFT


the information that is associated with the information exchanges of the architecture, such as 976

attributes, characteristics, and inter-relationships. Data is described fully in Volume 2. 977

978 3.4.2.4 The Operational Viewpoint (OV). The OV captures the organizations, tasks, or 979

activities performed, and information that must be exchanged between them to accomplish DoD 980

missions. It conveys the types of information exchanged the frequency of exchange, which tasks 981

and activities are supported by the information exchanges, and the nature of information 982

exchanges. 983

984 3.4.2.5 The Project Viewpoint (PV). The PV captures how programs are grouped in 985

organizational terms as a coherent portfolio of acquisition programs. It provides a way of 986

describing the organizational relationships between multiple acquisition programs, each of which 987

are responsible for delivering individual systems or capabilities. 988

989 3.4.2.6 The Services Viewpoint (SvcV). The SvcV captures system, service, and 990

interconnection functionality providing for, or supporting, operational activities. DoD processes 991

include warfighting, business, intelligence, and infrastructure functions. The SvcV functions and 992

service resources and components may be linked to the architecture artifacts in the OV. These 993

system functions and service resources support the operational activities and facilitate the 994

exchange of information. 995

996 3.4.2.7 The Standards Viewpoint (StdV). The TV is the minimal set of rules governing the 997

arrangement, interaction, and interdependence of system parts or elements. Its purpose is to 998

ensure that a system satisfies a specified set of operational requirements. The StdV provides the 999

technical systems implementation guidelines upon which engineering specifications are based, 1000

common building blocks established, and product lines developed. It includes a collection of the 1001

technical standards, implementation conventions, standards options, rules, and criteria that can 1002

be organized into profile(s) that govern systems and system or service elements for a given 1003

architecture. 1004

1005

3.4.2.8 The Systems Viewpoint (SV). SV captures the information on supporting automated 1006

systems, interconnectivity, and other systems functionality in support of operating activities 1007

1008

3.5 DoDAF Development Guidelines 1009 DoDAF 2.0 provides comprehensive and practical guidance for the creation of architectures that 1010

provide added value for decision-making at whatever level of the DoD they are produced. To 1011

this end, the framework offers guiding principles in the development of architectures that 1012

transcend the tier, level, or purpose of the architecture development, and a logical method for 1013

executing architecture development for supporting critical decisions within key DoD 1014

management and change management processes. The Framework also offers flexibility in 1015

approach, toolset utilization, and techniques (such as structured analysis, object-oriented, and 1016

service-oriented). 1017

1018

3.5.1 Guiding Principles. Guiding principles are high-level concepts, which provide a general 1019

roadmap for success in architecture development under DoDAF 2.0. The principles are: 1020


27 DRAFT


1021

• Architectures should clearly support the stated objective(s) (“Fit for Purpose”). The 1022

framework offers general direction in the development of architectures so that they can 1023

support critical decisions within key DoD management and change management processes. 1024

While DoDAF 2.0 describes a number of views, based on collected data, diligent scoping of 1025

a project and any guiding regulations, instructions, or standard procedures will determine the 1026

specific visualization requirements for a particular architectural effort. 1027

• Architectures should be simple and straightforward, but still achieve their stated 1028 purpose. Architectures should reflect the level of complexity defined by the purpose for 1029

their creation. Scoping of a project, as described in Section 7.0 Methodologies, will ensure 1030

that the resulting architecture data and derived information, and the views created are 1031

consistent with their original purpose. 1032

• Architectures should facilitate, not impede communications in decision processes and 1033 execution. Architecture creation is meant to support decision processes and facilitate 1034

improvement of procedures and/or technology in the enterprise. Collection of architecture 1035

data and creation of views supports the decision-making process, and provide a record to 1036

explain critical choices to technical and non-technical managerial staff. 1037

• Architectures should be relatable, comparable, and capable of facilitating cross-1038 architecture analysis. Most architectures, except perhaps those at the highest levels of DoD 1039

or an organization, relate on their boundaries to other external processes and operations. 1040

When several processes and/or operations are evaluated, compared, or cross-referenced, it 1041

should be clear how, where and why data passes among them in similar form. 1042

• Architecture should articulate how data interoperability is achieved among federated 1043 architectures. To enable federation, the framework will provide structures to ensure that 1044

horizontal touch-points can be compared for consistency across architecture boundaries. 1045

Other mechanisms will ensure that higher tiers have access to data from lower tiers in a form 1046

that supports their decision needs. DoDAF utilizes the DoDAF Meta-model, and particularly 1047

the Physical Exchange Specification described in Volume 3, as a resource for 1048

interoperability. A key element in ensuring interoperability is the effort taken to plan for 1049

integration of data across views, architecture boundaries, and is consistent between tiers. 1050

• Architectures should be data centric and tool-agnostic. The framework assists in the 1051

design of structures that meet specific needs depending on the priorities of individual 1052

organizations. In particular, the framework calls for the development of integrated, 1053

searchable, structured architecture data sets that support analysis targeted to critical 1054

decisions. 1055

• Architecture data should be organized, reusable, and decomposed sufficiently for use 1056 by architecture development teams. Collecting and organizing architecture data for use in 1057

decision processes should not be ‘over done’, that is the depth and breadth of data collected 1058

should be sufficient to capture the major processes actions, and not be so broad that the 1059

original intent of the architecture project becomes clouded. Whenever possible, data 1060

common to other architectures should be used. New data should be created utilizing the 1061

structures described in Volume 2 and Volume 3 so that, when stored in the DoD Metadata 1062

Registry, it becomes available to others with similar requirements. 1063


28 DRAFT


• Architecture development should be guided by the principles and practices of net-1064

centricity to facilitate and support the Net-Centric Strategy of the Department. 1065 1066

Architectural guiding principles enable and facilitate validation and verification activities that 1067

will determine the success of the project, and the ability of the resulting architecture to serve the 1068

purpose for which it was created. Guiding principles support the more specific goals and 1069

objectives of a project as a roadmap. 1070

1071

3.5.2 Multiple Techniques and Toolsets, including Structured and Object Oriented 1072

Analysis. 1073 The framework allows architects to select techniques and toolsets to meet specific needs. While 1074

the framework provides examples of the application of both Structured Analysis and Design 1075

(SADT) and Object-Oriented Analysis & Design (OOAD) techniques, it mandates neither. The 1076

framework explicitly permits any technique that meets the needs of the organization, provides 1077

the appropriate architecture data, adheres to the architecture data requirements of parent tiers 1078

described further in Section 3, and is capable of producing data that can be shared in a federated 1079

environment. A brief section on essential toolset attributes desirable for creation of architectures 1080

utilizing DoDAF are contained below in Section 3.5.3. 1081

1082

3.5.3 Essential Toolset Attributes 1083

While DoDAF is toolset agnostic, allowing architects, and architecture development teams to 1084

utilize any toolset they desire to create architectures, there are some basis attributes of a toolset 1085

needed to ensure that architectures, once registered, are discoverable, sharable, and their data 1086

useful to others with similar or derived needs in their own architecture development. These 1087

attributes are: 1088

• Capable of utilizing the Physical Exchange Data Specification described in Volume 3 to 1089

collect, organize, store, and share architecture data 1090

• Capable of XML data transfer to/from the DoD Metadata Registry (DMR), and other 1091

resources, such as the DoD Architecture Registry System (DARS) for registering 1092

architecture data 1093

1094

1095

3.6 Architecture Resources 1096 1097

A number of architecture resources exist which serve as sources for guidelines that must be 1098

consulted while building architecture products. Some of these architecture resources are briefly 1099

described below with their architectural uses, and their URLs. Additional information is 1100

contained in the individual URLs.. Some architecture resources may require SIPRNET access.1101


29 DRAFT


1102

1103

1104

Architecture Resources Resource Description Architecture Use URL Department of

Defense Information

Enterprise

Architecture (DoD

IEA)

Defines the key principles, rules,

constraints and best practices to which

applicable DoD programs, regardless of

Component or portfolio, must adhere in

order to enable agile, collaborative net-

centric operations.

The DoD IEA provides the guidelines and rules that

the architect must keep in mind in the architecture

development effort.

http://www.defenselink.mil/

cio-nii/cio/diea/

DoD Architecture

Registry System

(DARS)

DARS is the DoD registry and repository

of segment and solution architectures

comprising the federated DoD enterprise

architecture

To discover architectures that exist, or may be in

development. Depending on the purpose and scope,

an architect may search and discover Architectures

that overlap the scope and purpose of the

architecture effort.

To register metadata about architectures that are

being developed, or currently exist.

https://dars1.army.mil

DoD Information

Technology Portfolio

Repository (DITPR)

The official unclassified DoD data source

for FISMA, E-Authentication, Portfolio

Management, Privacy Impact Assessments,

the inventory of MC/ME/MS systems, and

the

registry for systems under DODI 5000.2

The Systems metadata from the Architecture can be

used to populate DITPR with new or updated

information. DITPR can also populate the

architecture’s Systems metadata, particularly on

systems that interface with systems described in the

architecture, but are not part of the scope of the

architecture.

https://www.dadms.navy.mi

l/

DoD Information

Technology Standards

and Profile Registry

(DISR)

Online repository for a minimal set of

primarily commercial IT standards

The DISR can be used to populate the Standards

models (StdV-1 and StdV-2) of the Architecture.

Conversely, the Standards Models can identify

additional or new standards that need to be added to

DISR.

https://disronline.disa.mil

Figure 3.6-1 Architecture Resources


30 DRAFT


1105

Architecture Resources Resource Description Architecture Use URL Joint C4I Program

Assessment Tool

(JCPAT)

Formally assess systems and capabilities

documents (Initial Capabilities Document,

Capability Development Document, and

Capability Production Document) for Joint

Staff interoperability requirements

certification and is the ITS/NSS Lifecycle

Repository and the archives

The ICD, CDD, and CPD contain architecture

information. As the architecture development

progresses, the collected architecture information

can be extracted and reported in the ICD, CDD, and

the CPD. In addition, the architecture information

can be exchanged with the E-ISP tool which is part

of JCPAT.

http://jcpat.ncr.disa.smil.mil

/JECOweb.nsf

Joint Common System

Function List

A standard taxonomy for terms of the

system functions based on the Universal

Joint Task List

Use the taxonomy to align or extend system

functions within the architecture being developed

TBD

Knowledge

Management/Decision

Support (KM/DS)

The KM/DS tool will be used by DOD

components to submit documents and

comments for O-6 and flag reviews, search

for historical information, and track the

status of documents.

Supporting the JCIDS approval process, the

documents that are necessary for Milestone

Decisions have architecture information. As the

architecture development progresses, the collected

architecture information can be extracted and

reported in the required documents.

https://jrockmds1.js.smil.mil

/guestjrcz/gbase.guesthome.

Metadata Registry The DoD Metadata Registry and

Clearinghouse provides software

developers access to data technologies to

support DoD mission applications.

Through the Metadata Registry and

Clearinghouse, software developers can

access registered XML data and metadata

components, database segments, and

reference data tables and related metadata

information

The Resource Flows and Physical Schemas from the

Architecture can be used to populate the Metadata

Registry.

http://metadata.dod.mil

Figure 3.6-1 Architecture Resources (Cont.)


31 DRAFT


1106

Architecture Resources Resource Description Architecture Use URL Navy Architecture

Elements Reference

Guide (NAERG)

A standard terms of reference for the Navy

and Marine Corp. The Architecture

Elements represent the critical taxonomies

requiring concurrence and standardization

for an integrated architecture. They

comprise the lexicon for the three views of

the architecture framework, the operational

(OV), system (SV) and technical standards

(TV) views.

The use of the critical taxonomies is a step to

ensuring integration of systems within a system of

systems and alignment of information technology

(IT) functionality to mission and operational needs.

The data contained in each element of the

Architecture list shall be used for overall

architecture framework development, programmatic

research, development, and acquisition activities,

and related integration and interoperability and

capability assessments. It will be updated through

review periods to support DoN Program Objective

Memorandum (POM) efforts and to reflect changes

mandated by DoD, technology improvements, and

other factors.

https://stalwart.spawar.navy.

mil/naerg/

Service Registry The Service Registry provides enterprise-

wide insight, control and leverage of an

organization's services. It captures service

descriptions and makes them discoverable

from a centrally managed, reliable, and

searchable location.

The Services metadata from the Architecture effort

can be used to populate the Service Registry in the

process of developing the solution.

Universal Joint Task

List

(UJTL)

The Universal Joint Task List (CJCSM

3500.04C) serves as a common language

and common reference system for joint

force commanders, combat support

agencies, operational planners, combat

developers, and trainers to communicate

mission requirements. It is the basic

language for development of a joint

mission essential task list (JMETL) or

agency mission essential task list

(AMETL) that identifies required

capabilities for mission success.

Use the taxonomy to align or extend operational

activities within the architecture being developed

http://www.dtic.mil/doctrine

/jel/cjcsd/cjcsm/m350004c.p

df

Figure 3.6-1 Architecture Resources (Cont.)


32 DRAFT


4. ENTERPRISE ARCHITECTURE 1107 “Today, the encouraging coalescence among leaders is that many enterprise systems have the 1108

same architectural approach—although not all express it in the same way. A similar 1109

convergence addresses the kinds of techniques, pattern, and designs that are independent of 1110

specific application domains, and that enable effective production of responsive, scalable, 1111

flexible, and unifiable enterprise applications.”10

1112

1113

Within DoD, Enterprise Architecture (EA) has been seen for many years as providing product-1114

oriented insight into a wide range of data, programs, and activities, organized through 1115

Communities of Interest (COI). The data-centric approach to DoDAF version 2.0 is designed to 1116

facilitate the reuse and sharing of COI data. Since DoDAF provides the conceptual, logical, and 1117

physical exchange specifications but does not otherwise prescribe the configuration of the 1118

product composition, architects and stakeholders are free to create their views of data that best 1119

serve their needs. 1120

1121

4.1 Introduction and Overview 1122 An architecture is a strategic information asset that describes the current and/or desired 1123

relationships between an organization’s business, mission and management processes, and the 1124

supporting infrastructure. Architectures define a strategy for managing change, along with 1125

transitional processes needed to evolve the state of a business or mission to one that is more 1126

efficient, effective, current, and capable of providing those actions needed to fulfill its goals and 1127

objectives. Architectures may illustrate an organization, or a part of it, as it presently exists; any 1128

changes desired (whether operational or technology-driven); and the strategies and projects 1129

employed to achieve the desired transformation. An architecture also defines principles and 1130

goals and sets direction on issues, such as the promotion of interoperability, intra-, and 1131

interagency information sharing, and improved processes, that facilitate key DoD program 1132

decisions. 1133

1134 Such support extends beyond details or summaries of operational and systems solutions, and 1135

includes program plans, programmatic status reporting, financial and budget relationships, and 1136

risk management. In addition to detailed views of individual solutions, the framework supports 1137

the communication of enterprise-wide views that illustrate the context for those solutions, and 1138

the interdependencies among the components. Beyond the solution space, standard mechanisms 1139

for communicating program plans, financial information, and project status are established so 1140

that executives and managers can evaluate and direct their programs. 1141

1142

Enterprise Architecture (EA) is the architecture described by the DoD Architecture Reference 1143

Models representing the major business areas of the Department, along with the implementing 1144

guidance, standards, and descriptions of Department-wide processes mapped to the Federal 1145

Enterprise Architecture. The DoD EA is shown in Figure 3.1-1. The DoD EA is composed of a 1146

"baseline architecture" describing the ‘segment’ architectures for each major Departmental 1147

business area (Consistent with the Federal EA Architecture described in OMB A-130). It also 1148

10

McGovern, James, Ambler, Scott, Stevens, Michael E., Linn, James, Sharan, Vikas & Jo, Elias K. (2004) A

Practical Guide to Enterprise Architecture. New Jersey: Prentice-Hall. 306pp.


33 DRAFT


includes a "target architecture" that includes proposed changes to the baseline architecture along 1149

with the rules, standards, services and systems life cycle information needed to optimize and 1150

maintain a process, or part of a process that a self-sufficient organization wants to create and 1151

maintain by managing its IT portfolio. EA provides a strategy that enables the organization to 1152

support its current operations while serving as the roadmap for transitioning to its target 1153

environment. Transition processes include an organization's PfM, PPBE, and EA planning 1154

processes, along with services and systems life cycle methodologies. Architectures created by 1155

Military Components, joint activities, agencies, and other organizations, at any level or tier of the 1156

Department are mappable to the DoD EA. 1157

1158

Figure 4.1-111

presents the high-level elements of the DoD EA and the relationship among them. 1159

The DoD Architecture Baseline describes the current DoD environment and the existing 1160

Department of Defense Information Environment (DoD EI) capabilities that support operations 1161

and services in today’s environment. The DoD Transition Strategy includes an enterprise-level 1162

transition plan built from JCAs and DoD Component portfolio transition plans. The JCA 1163

portfolios describe future, required operational, warfighting, business, and Defense intelligence 1164

capabilities, together with the systems and services required. The description of the future DoD 1165

operating environment and associated capability requirements represent the target architecture of 1166

the DoD EA. These are time-phased as determined by functional owners and JCA developers. 1167

11

This figure reflects the use of enterprise architectures as defined in OMB Circular A-130.


34 DRAFT


1168 Figure 4.1-1: Components of the DoD EA 1169

1170

Migration in a net-centric operating environment from the “As-Is” to the “To-Be” requires that 1171

the DoD Information Environment Architecture (DoD IEA) and the Net-Centric strategies act as 1172

uniform references for, and guide the transition sequence. The DoD Architecture Federation 1173

Strategy12

describes the DoD EA structure and its relationship to federated, supporting 1174

architectures. 1175

1176

4.2 Transition Planning 1177

1178 As discussed above, one major impetus for creating and using architectures is to guide 1179

acquisition and development of new enterprises, capabilities and systems or improvements to 1180

existing ones. Earlier versions of DoDAF addressed this need exclusively using “As-Is” and 1181

“To-Be” architectures, along with a Systems and/or Services Technology Forecast. The “As-Is” 1182

and “To-Be” concepts are time-specific snapshots of DoDAF artifacts and products that initially 1183

served as the endpoints of a transition process. However, this transition strategy has several 1184

12

Global Information Grid (GIG) Architecture Federation Strategy, 1 August 2007. Office of the Assistant Secretary of

Defense (Networks & Information Integration) (NII)/DoD Chief Information Officer (DoD CIO).


35 DRAFT


potential pitfalls, to include the difficulty in accurately representing the “As-Is” starting point 1185

where legacy systems are sometimes poorly documented, and processes are largely undefined. 1186

There is also the consideration that long-term goals are often very flexible, resulting in flux in 1187

the “To-Be” version 1188

1189

Since the “As-Is” and “To-Be” architectures are time-specific versions of similar sets of data 1190

with contrasting viewpoints, transition planning is able to chart an evolutionary path from the 1191

“As-Is” to its corresponding “To-Be” architecture given a clear understanding of the expected 1192

outcomes or objectives through some future (perhaps undefined) future point. It is expected that 1193

the ‘To-be’ architecture will change over time as Departmental priorities shift and realign. More 1194

comprehensive discussions of the ‘As-is’ and ‘To-be’ architecture, including transition 1195

requirements, are contained in Volume 2, and the DoDAF Journal, 1196

https://www.us.army.mil/suite/page/454707. 1197

1198

4.3 Federated Approach to DoD Architecture Management 1199 The Department has adopted a federated approach to distributed architecture data collection, 1200

organization, and management among the Services, Agencies and COIs as its means of 1201

developing the "DoD Enterprise Architecture", with a virtual rather than physical data set 1202

described through supporting documentation and architecture views. This approach provides 1203

increased flexibility while retaining significant oversight and quality management services at the 1204

Departmental level. Detailed guidance on the DoD Federation Strategy is contained in DOD 1205

8210-11-M, DoD Federation Strategy. 1206

1207 4.4 Tiered Accountability. Tiered Accountability (TA) is the distribution of authority and 1208

responsibility to a DoD organization for an element of the DoD EA. Under TA, DoD is defining 1209

and building enterprise-wide capabilities that include data standards, business rules, enabling 1210

systems, and an associated layer of interfaces for Department, specified segments of the 1211

enterprise (i.e. Joint Capability Areas (JCA), DoD Components), and Programmatic solutions. 1212

Each tier – Enterprise, Capability, Component, and Solution – has specific goals, as well as 1213

responsibilities to the tiers above or below them. The DoD-established JCAs are consistent with 1214

the Segment Architectures defined in the OMB Practice Guidance and the OMB Exhibit 53 and 1215

Exhibit 300 reporting requirements. 1216

DoD Component and Solution architectures are categorized when developed to facilitate 1217

alignment (mapping and linking), cataloging, navigating, and searching disparate architecture 1218

information in a DoD registry of holdings. The TA Strategy, shown in Figure 4.4-1, identifies 1219

the three major levels of the DoD EA, along with a ‘solutions’ tier that provides specific 1220

programmatic solutions for any level of the enterprise. All architectures developed by the tiers 1221

are federated, as described in the DoD Federation Strategy. 1222

1223


36 DRAFT


Component

Solutions

Capabilities/

Segment

DepartmentDoD EADoD ArchitectureFederation

Component

Solutions

Capabilities/

Segment

DepartmentDoD EADoD ArchitectureFederation

1224 Figure 4.4-1: Architecture Levels for Tiered Accountability 1225

1226

1227 Alignment in the tiers is required for the DOD EA to be discoverable, shareable, and 1228

interoperable. Architecture can also support many goals within the tiers, each of which may 1229

imply specific requirements for structure, content, or level of detail. Alignment decisions must 1230

balance the interdependence of architectures with the need for local flexibility to address local 1231

issues. Alignment describes the minimum constraints needed to ensure consistency across 1232

architecture levels. Architectures often relate at some ‘touch point’ to other architectures on the 1233

same level, level(s) above, or level(s) below, and should be discovered and utilized in 1234

architecture development to ensure that appropriate linkages are created and maintained. The 1235

need to plan for them implies that each architecture sharing a touch-point should be available to 1236

architects on both sides. The DoD Metadata Registry (DMR) for data and the Defense 1237

Architecture Registry System (DARS) for architecture registration facilitate the ability to 1238

discover and utilize architecture data, with the caveat that any touch-points within the purview of 1239

an established COI adhere to COI guidance13

. 1240

1241

4.5 DoD Architecture Enterprise Services. The next generation of DoD Enterprise 1242

Architectures will be constructed by employing a set of DoD Architecture Enterprise Services 1243

13

Department of Defense Net-Centric Data Strategy, 9 May, 2003. Office of the Assistant Secretary of Defense (Networks &

Information Integration) (NII)/DoD Chief Information Officer (DoD CIO).


37 DRAFT


(DAES)14

for registering, discovering, aligning, translating, and utilizing architecture data, and 1244

derived information to support key DoD decision processes through implementing the concepts 1245

of the DoD Net-Centric Strategies. 15

DAES will be implemented using Web Services, in which 1246

specific content and/or functionality is provided by one user for others, many of whom may be 1247

unknown to the provider. An Operational Resource Data Flow Description (A redesigned 1248

Operational Viewpoint 2 (OV-2) DoDAF-described View) has been retained in DoDAF 2.0 to 1249

describe those services that can be discovered and subscribed from one or more specific sources 1250

and delivered to one or more known or unknown subscribers. 1251

1252

Registration of architectures, one of the goals of the Net Centric Data Strategy (NCDS)16

, is the 1253

first step toward enabling discovery of architecture metadata. DAES includes a registration 1254

service to register the metadata (Through the DoD metadata Repository), and a method to 1255

describe the purpose and scope of an architecture (Through DARS). The registration service will 1256

enable cataloging of architectures in federated repositories, and, once complete, architectures are 1257

‘available’ for discovery. When an architecture is discoverable, it can be aligned to, linked to, or 1258

re-used by other architectures. The discovery service enables users to execute a federated search 1259

for architecture holdings meeting specified search parameters. 1260

1261

4.6 Alignment to the Federal Enterprise Architecture (FEA) 1262 1263

The Office of Management and Budget (OMB) established the Federal Enterprise Architecture 1264

(FEA) program in 2003 to build a comprehensive business-driven blueprint of the entire Federal 1265

government. OMB’s Circular A-11 requires that Cabinet-level agencies, including the DoD, link 1266

their budget submissions to the FEA, and annually evaluates those submissions through the 1267

Enterprise Architecture Assessment Program, which establishes an evaluation score for overall 1268

agency progress. 1269

1270

The core principles of the FEA program are: 1271

• business-driven approach 1272

• promote collaboration of effort and reuse 1273

• improve efficiency and effectiveness of business operations through the use of enterprise 1274

architecture for the capital investment process 1275

• Demonstrate cost savings and cost avoidance through improved core processes, and 1276

cross-agency sharing and mutual investment 1277

1278

DoD leverages the FEA construct and core principles to provide the Department with the 1279

enterprise management information it needs to achieve its own strategic transformation goals and 1280

respond to upward reporting requirements of OMB. The primary objective is to improve DoD 1281

performance, using EA, by providing a framework for cross-mission analysis and identification 1282

14 Formerly called the GIG Architecture Enterprise Services (GAES) 15 For additional details about the services, please review Section 11, “GIG Architecture Enterprise Services (GAES) — Making the GIG

Architecture Visible, Accessible, and Understandable” of the “Global Information Grid (GIG) Architecture Federation Strategy,” Version 1.2, 1

August 2007 16 Department of Defense Net-Centric Data Strategy, 9 May, 2003. Office of the Assistant Secretary of Defense (Networks &

Information Integration) (NII)/DoD Chief Information Officer (DoD CIO).


38 DRAFT


of gaps and redundancies; and by developing transition plans and target architectures that will 1283

help move DoD to the net-centric environment. 1284

1285

Several Federal and DoD-specific EA artifacts exist that describe enterprise-level management 1286

information. These include: 1287

• The President’s Management Agenda. 1288

• OMB A-11 Exhibit 300 submissions 1289

• OMB FEA Practice Guidance 1290

• OMB EA Assessment Guide 1291

• OMB FEA Reference Models 1292

• DoD EA Reference Model (RM) Taxonomy 1293

• DoD EA Consolidated RM 1294

• DoD EA Transition Strategy 1295

• DoD Segment Architectures 1296

• DoD EA Self-Assessment 1297

• DoD Architecture Federation Strategy 1298

1299

These artifacts facilitate the alignment with the FEA, contribute to a broader understanding of 1300

architecture alignment, provide a basis for federated architectures, promote a more efficient and 1301

effective use of assets, and ultimately lead to better decision-making. 1302

When developing architectures, particularly at the Departmental and Component levels, 1303

alignment with the FEA is accomplished by utilizing the FEA-RM documents together with DoD 1304

documents and references as a basis for defining processes, data, services, and technical 1305

standards. As an example, when a process owner determines that an architecture is needed for 1306

some specific purpose, the first references to use are as shown below in Figure 4.6-1. 1307


39 DRAFT


1308

1309

Action Reference(s) Usage Determine processes

Involved

DoDAF

FEA Business Reference Model

(BRM)

(DoDAF) Determine techniques and

notation to be used

(FEA BRM) Determine FEA business

processes to align to; use taxonomies in

BRM to name processes

Identify and Define data DoDAF Meta-model (DM2)

FEA Data Reference Model

(DRM)

(DM2) Data Group and metadata structures

(DRM) Existing Government-wide

metadata for linkage to architecture

Document Architecture DoDAF

DoD Metadata Registry (DMR)

DoD Architecture Registry System

(DARS)

Toolset

OMB EA Guidance

OMB EA Assessment Guide

(DoDAF) provides described views, and

guidance on creating ‘Fit-for-purpose

Views’ for presentation purposes

(DMR) Provides existing metadata to use in

conjunction with DMR to create data

required

(DARS) provides registration services for

architecture discovery

(Toolset) provides automated notation

method for creating views

(OMB EA Guidance) provides information

on required format and content of EA for

OMB 53/300 process

(OMB EA Assess. Guide) provides

guidance on evaluation of architectures

submitted to OMB for review

Publish Architecture DoD Architecture Federation

Strategy

Agency Repository

DARS

(DoD Fed. Strategy) provides guidance on

architecture data discovery

(Agency Repository) stores EA Data

(DARS) Providers EA contact information

Figure 4.6-1. References to Architecture Development


40 DRAFT


4.7 Addressing Security Issues in DoDAF-conformant Architecture Development 1310 1311

Security continues to be a critical concern within the DOD, and architecture development efforts 1312

at any level need to ensure that appropriate security concerns are addressed clearly, so that any 1313

decisions made that rely on the architecture are valid and useful. Security concerns are routinely 1314

addressed through the risk assessment process described in Section 10 of Volume 1, and 1315

Appendix C of Volume 2. 1316

Each of the individual views described in detail in Volume 2 provides the architect and 1317

development team with a set of data for collecting, documenting, and maintaining security data. 1318

These data support physical, procedural, communications Security (COMSEC), TEMPEST, and 1319

Information Security (INFOSEC) concerns. 1320

1321

5. ARCHITECTURE PLANNING 1322 1323

5.1 Defining the Enterprise 1324 In a generic sense, an ‘enterprise’ is any collection of organizations that has a common set of 1325

goals and/or a single bottom line. An enterprise, by that definition, can encompass a Military 1326

Department, DoD as a whole, a division within an organization, an organization in a single 1327

location, or a chain of geographically distant organizations linked by a common management or 1328

purpose. An enterprise today is often thought of as an extended enterprise where partners, 1329

suppliers, customers, along with their activities and supporting systems are included in the 1330

architecture. 1331

1332

Government agencies may comprise multiple enterprises, and there may be separate enterprise 1333

architecture projects. However, the projects often have much in common about the execution of 1334

process activities and their supporting information systems, and they are all linked an enterprise 1335

architecture. The DoD Enterprise Architecture is described in Section 3.1. Architecture 1336

development in conjunction with the use of a common architecture framework, which describes 1337

the common elements of architecture, lends additional value to the effort, and provides a basis 1338

for the development of an architecture repository for the integration and re-use of models, 1339

designs, and baseline data. 1340

1341

5.2 The Enterprise-level Architecture. Enterprise-level architectures in DoD are generally 1342

created under the responsibility and authority of a senior-level official within the Department, 1343

Component, Organization, Agency, or the program office responsible for development of JCAs. 1344

As an enterprise-level effort, it is expected that all of the major processes are documented and 1345

described, even if a specific project involves only a more limited subset of processes or 1346

activities. That way, subsequent architecture efforts can build on previous efforts to ensure the 1347

integration and extension of the enterprise is not compromised. 1348

1349

Enterprise-level architectures usually exhibit breadth rather than depth. Since this architecture is 1350

the ‘capstone’, or highest level of an architecture, on which others will build, it is especially 1351

important that processes, which relate to each other, either through interaction of activities, or the 1352

use of data by internal and external stakeholders, are identified or documented. 1353


41 DRAFT


1354

5.3 The Solution-Level Architecture. The solution-level architecture is scoped to include all 1355

major activities that are executed by a specified program in response to a specific requirement, 1356

and contain links to other programs, which require the data and/or outputs produced by the 1357

specified program. A solution-level architecture may represent activities within a specified 1358

functional area, cross-functional areas, or even extend to other organizations, agencies, Federal, 1359

state and local activities who may have an interest or participate in Departmental programs. 1360

1361

5.4 Architecture Management 1362

1363 Architectures are designed to describe the data on an organization or program/capability that will 1364

support continuing managing decision-making over time. Creation of architectures and their 1365

management follow an established life cycle that is similar to those other resources that have 1366

well-described life cycles. OMB Circular A-13017

describes the life cycle as: 1367

• Develop 1368

• Use 1369

• Maintain 1370

For consistency, that structure is followed in this volume as well. These phases recognize 1371

discreet actions that occur at various times, all designed to ensure that architecture data can be 1372

collected and later reused for management decision-making and reporting. 1373

1374 5.4.1 Architecture Development. Architectures are developed to represent either the state of 1375

an activity at a specified time (i.e., Baseline architecture) or the results of change in an activity 1376

that will occur over some future time (i.e., ‘to-be’ or future architecture). Enterprise 1377

architectures (Departmental, Capability/Segment, and Component) are initially created to create 1378

a common context needed to understand the organization and operations of high-level processes 1379

under their control. 1380

1381

Program-level architectures collect data that is specific to their program or capability, and data 1382

necessary to link to both the higher-level architecture with which they share common parentage, 1383

and any lower-level architectures, which describe in more detail particular aspects of the 1384

program or JCA. 1385

1386

Visualization of data provides a unique perspective of data from the viewpoint needed for 1387

decision-making. That may be a commander/director, action officer, system developer, data 1388

administrator, user, or anyone else executing some part of the architected process. More 1389

discussion of data collection and visualization is contained in DoDAF Volume 2. 1390

1391

1392

5.4.2 Architecture Utilization. The ultimate success of an architecture effort lies in the ability 1393

to use architecture-related data to support management decisions for change within the 1394

17

Office of Management and Budget (OMB) Circular-A-130, Management of Federal Information Resources,

February 8, 1996. Executive Office of the President., Office of Management and Budget. The current version can

be found at: http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html#2


42 DRAFT


organization. While architecture development is generally accomplished as an project, 1395

accomplished through a team trained for that purpose, the results of the architecture 1396

development, to be effective over the longer term, need to be adopted as the common, normal 1397

mode of performing the organization’s business. 1398

1399

The enterprise architecture, as a corporate asset, should be managed like any other asset, and 1400

reinforced by management as a key part of the formal program that results in decision-making. 1401

Achieving that level of acceptance occurs only when architectures are created that reflect reality 1402

(e.g. baseline), or planned change/growth (e.g. to-be, or target). 1403

1404

Successful execution of the EA development process in an agency-wide endeavor requires 1405

management direction and support, allocation of resources, continuity, and coordination. 1406

Creating an EA program calls for sustained leadership and strong commitment. This degree of 1407

sponsorship and commitment needs the buy-in of the agency head, leadership by the CIO, and 1408

early designation of a chief architect. These leaders and the supporting EA team are the first 1409

level of support for institutionalizing the results of the effort. 1410

1411

1412

5.4.3 Architecture Maintenance. Changes in an organization supported by architecture 1413

development will achieve institutionalization only when the senior leadership agrees with, 1414

supports, encourages, reinforces, and adopts the results of the architecture effort. Ideally, a 1415

member of the senior leadership team should be designated as the ‘champion’ of the change 1416

effort, and should work with the process owner to ensure that institutionalization occurs 1417

Employees, who actually perform the daily activities described in the architecture, must be 1418

represented in the architecture development team and contribute to the overall data collection 1419

and view creation. 1420

1421

5.4.4 Architecture Utilization. Architecture views must be easy-to-understand at all levels of 1422

the organization—and described in such a way that they become roadmaps for activity. When 1423

architecture data and views are constructed and organized in a way that they are understood, 1424

accepted, and utilized in daily activities, they facilitate management decision-making. 1425

1426

Architecture views, and data must meet standards that facilitate reuse by others whose activities 1427

border on, or replicate activities, services and systems already documented by architecture data 1428

and products. To that end, data collection must adhere to the standards set by the COI, or other 1429

recognized authority so that the data can be registered for, and used by others. 1430

1431

1432

5.4.5 Architecture Compliance Reviews. Architecture compliance reviews are a key part of 1433

the validation & verification (V&V) process ongoing throughout the architecture development 1434

effort. A compliance review is a type of review that analyzes whether architecture developers 1435

are progressing according to the specifications and requirements developed for the architecture 1436

effort by the process owner. The goals of an architecture compliance review include: 1437

1438


43 DRAFT


• Identifying errors in the architecture early to reduce the cost and risk of changes required 1439

later in the project. These error-catching actions will reduce cost and schedule slips, and 1440

realize business objectives quicker. 1441

• Ensuring the application of best practices to architecture work. 1442

• Providing an overview of the compliance of architecture to mandated enterprise standards. 1443

• Identifying and communicating significant architectural gaps to product and service 1444

providers 1445

• Communicating to management the status of technical readiness of the project. 1446

1447

Utilization of architecture compliance reviews as an integral part of the development process 1448

ensures that utilization of architecture views and products later will be in conformance with 1449

applicable requirements. A more in-depth discussion of the compliance review process is 1450

contained in the DoDAF Journal, https://www.us.army.mil/suite/page/454707. 1451

1452

5.4.5.1 OMB Architecture Assessment. The Office of Management and Budget (OMB) 1453

requires departments and independent agencies to submit a self-assessment of their enterprise 1454

architecture programs in February of each year. For DoD, this applies at the Department level. 1455

The self-assessment is performed in three EA capability areas: completion of the EA, use of the 1456

EA and results, and utilization of the OMB Federal Enterprise Architecture program EA 1457

Assessment Framework.18

Specifics of the DoD/OMB architecture self-assessment are described 1458

in the DoDAF Journal, https://www.us.army.mil/suite/page/454707. 1459

1460

5.4.5.2 GAO Architecture Assessment. The Government Accountability Office (GAO) 1461

periodically requires all departments and independent agencies to submit a self-assessment of the 1462

maturity of the management of their EA programs. In addition, GAO may perform their own 1463

review and assessment of architecture efforts associated with large-scale programs. 19

In certain 1464

cases, GAO expects an agency to establish an independent quality assurance process for a large-1465

scale architecture to determine whether it meets quality criteria such as those identified earlier in 1466

this section. 20

Specifics of the DoD/GAO architecture self-assessment are described in the 1467

DoDAF Journal, https://www.us.army.mil/suite/page/454707. 1468

1469

18

Federal Enterprise Architecture Program: Enterprise Architecture Assessment Framework, version 2.2, October 2007. Executive Office of the President., Office of Management and Budget. The current version can be found at:

http://www.whitehouse.gov/omb/egov/a-2-EAAssessment.html. 19

United States Government Accountability Office (GAO) Report: DoD Business Systems Modernization: Long-standing

Weaknesses in Enterprise Architecture Development Need to Be Addressed, July 2005, GAO-05-702. A copy of the report is available at: http://www.gao.gov/new.items/d05702.pdf 20

United States Government Accountability Office (GAO) Report: Framework for Assessing and Improving Enterprise Architecture Management, version 1.1, April 2003, GAO-03-584G. A copy of the report is available at: www.gao.gov/new.items/d03584g.pdf


44 DRAFT


5.4.6 User Support. User support is the service that each enterprise unit provides its users, 1470

both internally and externally to the enterprise, as described in the architecture documents. 1471

1472

5.4.7 Training. It is the responsibility of agency executive management to institutionalize the 1473

control structures for the EA process as well as for the agency CPIC and Shelf Life Code (SLC) 1474

processes. For each decision-making body, all members should be trained, as appropriate, in the 1475

EA, the EA process, the relationship of the EA to the Agency’s mission, DoDAF, and the FEA. 1476

Specific training, at various levels of detail, should be tailored to the architecture role of the 1477

personnel. 1478

1479

Architecture development training for team members is provided by the team leader and Chief 1480

Architect during the course of team operations. Training for team members includes sessions on 1481

group interactions, toolset operations, data collection, and creation of models and views. 1482

1483

5.4.8 Communications Planning. Communication management is the formal and informal 1484

process of conducting or supervising the exchange of information to all stakeholders of 1485

enterprise architecture. Communication planning is the process of ensuring that the 1486

dissemination, management, and control of critical stakeholder information is planned and 1487

executed in an efficient and effective manner. 1488

1489

The purpose of communications planning is (1) to keep senior executives and business units 1490

continually informed, and (2) to disseminate EA information to management teams. The CIO’s 1491

staff, in cooperation with the Chief Architect and support staff, defines a marketing and 1492

communications plan consisting of: 1493

• constituencies 1494

• level of detail 1495

• means of communication 1496

• participant feedback 1497

• schedule for marketing efforts 1498

• method of evaluating progress and buy-in. 1499

1500

The CIO’s role is to interpret the Agency Head’s vision, and recognize innovative ideas (e.g., the 1501

creation of a digital government) that can become key drivers in the EA strategy and plan. In 1502

turn, the Chief Architect is the primary technical communicator with the community(ies) of 1503

interest involved in an architecture effort. 1504

1505

At the Process Owner level, the communications plan is similar to that described above for the 1506

CIO. As with the CIO at the enterprise, the process owner is the manager of architecture efforts, 1507

supported by an architect and development team. The process owner must clearly define the 1508

purpose and scope of an architecture effort (i.e. ‘Fit-for-Purpose’) and communicate those goals 1509

and objectives for the architecture effort to the architect and team. In turn, as development of the 1510

architecture progresses, the architect provides feedback to the process owner, participates in 1511

validation and verification activities, and provides revisions, as required to the original 1512

development plan. 1513

1514


45 DRAFT


5.4.9 Quality Planning. Quality management is the process of organizing activities involving 1515

the determination of quality requirements, establishing quality policies, objectives, performance 1516

metrics, and responsibilities, and ensuring that these policies, objectives, and metrics will satisfy 1517

the needs within the enterprise. The quality management system executes policies, procedures, 1518

and quality planning processes, along with quality assurance, quality control processes, and 1519

continuous process improvement activities to improve the overall health and capability of the 1520

enterprise. The primary input into the quality management process is quality planning. 1521

1522

Quality planning for architecture development identifies which quality standards are relevant to 1523

creation of the architecture and determines how to satisfy them. Quality requirements are stated 1524

in the Project Scope Statement, further defined in the Program Management Plan and other 1525

guidance, such as that provided by the methodology being applied to the development effort. 1526

Guidance also includes other enterprise environmental factors, such as Governmental agency 1527

regulations, rules, standards, and guidelines specific to the application area. Information needed 1528

during quality planning is generally collected during architecture development, and represented 1529

in architecture products and views as controls, resources, inputs, and outputs, as appropriate. A 1530

more comprehensive discussion of quality planning is provided online in the DoDAF Journal, 1531


1533

5.4.10 Risk Management. Risk management is the act or practice of dealing with risk. It 1534

includes planning for risk, assessing risk issues, developing risk handling strategies, and 1535

monitoring risk to determine how they have changed. Risk management planning is the process 1536

of deciding how to approach and conduct the risk management activities for the enterprise, 1537

program, and projects. 1538

1539

Architectural risk assessment is a risk management process that identifies flaws in architecture 1540

and determines risks to business information assets that result from those flaws. Through the 1541

process of architectural risk assessment, risks are identified and prioritized based on their impact 1542

to the business; mitigations for those risks are developed and implemented; and the architecture 1543

is reassessed to determine the efficacy of the mitigations. 1544

1545

Risk management planning should be initiated early during development of the scope for the 1546

architecture effort. Mitigation of risk is crucial to success of the overall effort. Inputs to the risk 1547

management planning process include a review of existing enterprise environmental factors, 1548

organizational process assets, the proposed scope statement, and the program management plan. 1549

Enterprise environmental factors are the attitudes toward risk and the risk tolerance of the 1550

organizations and people involved in the organization that exert influence over change. Risk 1551

attitudes and tolerances may be expressed in policy statements or revealed in actions. 1552

Organizational process assets are tools and techniques, which normally predefine organizational 1553

approaches to risk management such as established risk categories, common definitions of 1554

concepts and terms, standard templates, roles and responsibilities, and authority levels for 1555

decision-making. 1556

1557

A comprehensive discussion of Risk management can be found online in Section __ of the 1558



46 DRAFT


1560

1561

6. CUSTOMER REQUIREMENTS 1562 1563

In a large organization such as DoD, there are myriad decisions made each day. These decisions 1564

require facts (i.e. valid information) for successful execution. Two things affect the ability to 1565

make decisions. First, needed information must be available; second, a decision support process 1566

must exist to frame how the decision, once made, can be executed. Decision support can be as 1567

simple as an established procedure or rule for execution, or a more complex, integrated set of 1568

actions to assure that a decision is executed properly. 1569

1570

Within DoD are a number of very complex, overarching, decision support services that provide a 1571

framework for execution on DoD’s most critical program activities. These key DoD change 1572

management decision support processes include JCIDS, DAS, systems engineering, PPBE, and 1573

PfM. The following paragraphs discuss how these key decision support processes impact 1574

management decision making in DoD using architecture data. 1575

1576

6.1 Tailoring Architecture to Customers’ Needs 1577 1578

Architectures collect information about an organization that is relevant to a requirement. This 1579

information frequently includes processes, supporting systems, needed or desired services, 1580

interfaces, business rules, and other details that can be organized to facilitate a decision. From 1581

this perspective, Architecture applies a method for tailoring information collection to a specific 1582

local need with a clear understanding of the decisions the architecture must support, how those 1583

decisions should be made, and what information they require. Responding to the organization’s 1584

requirements generally requires the following information in order to apply the methodology 1585

described in Section 7, or another selected by the architect: 1586

• Detail on specific implementations of the basic processes, including explicit identification of 1587

critical decisions mandated or implied. 1588

• Identification of performance measures that can be used to judge the effectiveness of each 1589

process (including any mandated by the authoritative documents), taking special note of 1590

those that sample the effectiveness of architecture support (the DoDAF Journal, 1591

https://www.us.army.mil/suite/page/454707, includes a tutorial on a relatively painless 1592

method for performance engineering). 1593

• For each critical decision, identification of at least one method (and optionally several 1594

alternatives) for making that decision, identifying analyses to perform and questions to 1595

answer. 1596

• For each analysis or question, identification of needed information. 1597

• Creation of additional business objects/elements and attributes as needed to capture 1598

information in the architecture repository. 1599

• Process and information definitions for utilization in architecture development. 1600


47 DRAFT


The architect simplifies the architecture design by eliminating unneeded objects and attributes 1601

through a ‘best sense of opportunity’ approach, whereby interaction with the customer provides 1602

normal and expected needs that generally satisfies the majority of information needs for 1603

architecture development. Architecture views should be created to reflect, as closely as possible, 1604

the normal ‘culture’, and preferred presentation design of the agency. 1605

1606

6.2 Key Decision Support Processes 1607 1608

Organizations within the DoD may define local change management processes, supportable by 1609

architecture, while adhering to defined decision support processes mandated by the Department, 1610

including JCIDS, the DAS, systems engineering, PPBE, and PfM. These key support processes 1611

are designed to provide uniform, mandated, processes in critical decision-making areas, 1612

supplemented by individual agency operations, defined by architectures tailored to support those 1613

decisions-making requirements. 1614

1615 6.2.1 Joint Capability Integration and Development System. The primary objective of the 1616

JCIDS process is to ensure warfighters receive the capabilities required to execute their assigned 1617

missions successfully. JCIDS defines a collaborative process that utilizes joint concepts and 1618

integrated architectures to identify prioritized capability gaps and integrated joint DOTMLPF 1619

(i.e. Doctrine, Organization, Training, Materiel, Leadership, Personnel, Facilities) and policy 1620

approaches (materiel and non-materiel) to resolve those gaps21. JCIDS implements an integrated, 1621

collaborative process to guide development of new capabilities through changes in joint 1622

DOTMLPF and policy. 1623

1624

The JCIDS process owners recognized the need for architecture and wrote policy to support 1625

architecture requirements (i.e., specific product sets required in specific documents, such as the 1626

Information Support Plan, Capability Planning Document, and Capability Design Document) 1627

that permits components and lower echelon commands to invoke the JCIDS process for 1628

requirements at all levels. JCIDS description of the Functional Solution Assessment (FSA) step 1629

specifically includes both DOTMLPF analysis and business process improvement and re-1630

engineering. A more comprehensive discussion of JCIDS is contained in the DoDAF Journal, 1631


1633 6.2.2 Defense Acquisition System. The Defense Acquisition System (DAS) exists to manage 1634

the nation’s investments in technologies, programs, and product support necessary to achieve the 1635

National Security Strategy and support employment and maintenance of the United States Armed 1636

Forces.22

The DAS uses Joint Concepts, integrated architectures, and DOTMLPF analysis in an 1637

21 Chairman of the Joint Chiefs of Staff (CJCS) Instruction 3170.01E, Joint Capabilities Integration and Development System (JCIDS), 11 May 2005. A copy of the current version of the instruction and its accompanying Manual can be found at: https://acc.dau.mil/CommunityBrowser.aspx?id=42776 22

Department of Defense Directive (DoDD) 5000.1, The Defense Acquisition System, 12 May 2003 (certified current as of November 20, 2007). A current copy of the directive can be found at: https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2)


48 DRAFT


integrated, collaborative processes to ensure that desired capabilities are supported by affordable 1638

systems and other resources.23

1639

1640

DoD Directive 5000.1 provides the policies and principles that govern the defense acquisition 1641

system. In turn, DOD Instruction 5000.2, Operation of the Defense Acquisition System 1642

establishes the management framework for translating mission needs and technology 1643

opportunities, based on approved mission needs and requirements, into stable, affordable, and 1644

well-managed acquisition programs that include weapon systems and automated information 1645

systems (AISs).24

The Defense Acquisition Management Framework25

provides an event-based 1646

process where acquisition programs advance through a series of milestones associated with 1647

significant program phases. 1648

1649

The USD (AT&L) leads the development of integrated plans or roadmaps using integrated 1650

architectures as its base. DoD organizations use these roadmaps to conduct capability 1651

assessments, guide systems development, and define the associated investment plans as the basis 1652

for aligning resources and as an input to the Defense Planning Guidance (DPG), Program 1653

Objective Memorandum (POM) development, and Program and Budget Reviews.26

1654

1655 6.2.3 Systems Engineering (SE). DoD Acquisition policy directs all programs responding to 1656

a capabilities or requirements document, regardless of acquisition category, to apply a robust SE 1657

approach that balances total system performance and total cost with the family-of-systems, and 1658

system-of-systems context. Programs develop a Systems Engineering Plan (SEP) for Milestone 1659

Decision Authority (MDA) that describes the program’s overall technical approach, including 1660

activities, resources, metrics, and applicable performance incentives. 1661

Systems engineering processes are applied to allow an orderly progression from one level of 1662

development to the next detailed level using controlled baselines. These processes are used for 1663

the system, subsystems, and system components as well as for the supporting or enabling 1664

systems used for the production, operation, training, support, and disposal of that system. 1665

Execution of technical management processes and activities, such as trade studies or risk 1666

management activities may point to specific requirements, interfaces, or design solutions as non-1667

23 Department of Defense Instruction (DoDI) 5000.2., Operation of the Defense Acquisition System.(2003) Under-Secretary of Defense (Acquisition, technology & Logistics) (OUSD AT&L). A current copy of this document can be found at: https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2 24 Department of Defense Instruction (DoDI) 5000.2., Operation of the Defense Acquisition System.(2003) Under-Secretary of Defense (Acquisition, technology & Logistics) (OUSD AT&L). A current copy of this document can be found at: https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2 25 Integrated Defense Acquisition, Technology, & Logistics Life Cycle Management Framework

(2005). Defense Acquisition University, Ft. Belvoir, VA. A current copy of the chart is found

at: http://www.dau.mil/pubs/IDA/IDA_04.aspx 26

Department of Defense Instruction (DoDI) 5000.2., Operation of the Defense Acquisition System.(2003) Under-Secretary of Defense (Acquisition, technology & Logistics) (OUSD AT&L). A current copy of this document can be found at: https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2


49 DRAFT


optimal and suggest change to increase system-wide performance, achieve cost savings, or meet 1668

scheduling deadlines27. 1669

Architecture supports systems engineering by providing a structured approach to document 1670

design and development decisions based on established requirements. 1671

1672 6.2.4 Planning, Programming, Budgeting, and Execution (PPBE). The PPBE process 1673

allocates resources within the DoD and establishes a framework and process for decision-making 1674

on future programs. PPBE is a systematic process that guides DoD’s strategy development, 1675

identification of needs for military capabilities, program planning, resource estimation, and 1676

allocation, acquisition, and other decision processes. JCIDS is a key supporting process for 1677

PPBE, providing prioritization and affordability advice. 1678

1679

DoDAF 2.0 supports the PPBE process by identifying the touch points between architecture and 1680

the PPBE process, identifying the data to be captured within an architecture description, 1681

facilitating informed decision-making, and identifying ways of presenting data to various 1682

stakeholders/roles in the PPBE decision process. 1683

1684 6.2.5 Portfolio Management. DoD policy requires that IT investments be managed as 1685

portfolios to ensure IT investments support the Department’s vision, mission, and goals; ensure 1686

efficient and effective delivery of capabilities to the warfighter; and maximize return on 1687

investment within the enterprise. Each portfolio must be managed using the architecture plans, 1688

risk management techniques, capability goals and objectives, and performance measures. 1689

Capability architecting is done primarily to support the definition of capability requirements. 1690

Portfolio management uses the architecture to analyze decisions on fielding or analysis of a 1691

needed capability.28 1692

1693

Architecture support to PfM tends to focus on the investment decision itself (although not 1694

exclusively), and assists in justifying investments, evaluating the risk, and providing a capability 1695

gap analysis. 1696

1697 6.2.6 Operations. In most cases, an enterprise will capture its routine or repeatable business 1698

and mission operations as architecture content. However, when the basic structure of an activity 1699

is very stable and the activity repeated often, such as military operations planning or project 1700

definition and management, the enterprise may choose to include that structure as part of the 1701

structure of the architecture itself. In this case, the architecture repository may be enhanced to 1702

include templates, checklists, and other artifacts commonly used to support the activity. 1703

1704

27 DoD Acquisition Guidebook. Office of the Under-Secretary for Acquisition, Technology & Logistics (AT&L). A current copy

of the Guidebook can be found at: https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2 28

Department of Defense Directive (DoDD) 8115.01, Information Technology Portfolio Management, October 10, 2005. Office

of the Assistant Secretary of Defense (Networks & Information Integration)(NII)/DoD Chief Information Officer (DoD CIO).

The latest copy of this directive can be found at:

http://www.dtic.mil/whs/directives/corres/rtf/811501x.rtf


50 DRAFT


The JCIDS, PPBE, and DAS processes establish a knowledge-based approach, which requires 1705

program managers to attain the right knowledge at critical junctures to make informed program 1706

decisions throughout the acquisition process. The DoD IT PfM process continues to evolve that 1707

approach with emphasis on individual systems and/or services designed to improve overall 1708

mission capability. Consistent with OMB Capital Planning and Investment Control (CPIC) 1709

guidance, the DoD uses four continuous integrated activities to manage its portfolios -- analysis, 1710

selection, control, and evaluation. The overall process is iterative, with results being fed back 1711

into the system to guide future decisions.29 1712

1713

6.3 Information Sharing. Information sharing across the Department has existed for many 1714

years in various forms. The sharing of information took on new urgency following the events of 1715

September 2001, especially in the area of terrorist-related information. Since that time, new 1716

Federal legislation30

and presidential orders require that agencies develop a common framework 1717

for the sharing of information, and define common standards for how information is acquired, 1718

accessed, shared, and used within a newly created Information Sharing Environment (ISE). 1719

While initial efforts relate to terrorism-related data, the standards being set could apply, in the 1720

future, more broadly across the Department. 1721

1722

Importantly, an Information Sharing Environment Enterprise Architecture Framework (ISE-1723

EAF) is under development31

, which will provide guidance for information collection and 1724

dissemination within the Information Sharing Environment (ISE). This Framework is consistent 1725

with the DoDAF, and is essential data structures will be mappable to the DoDAF Meta-model 1726

described in DoDAF Volume 2 and Volume 3. When published, that ISE document should be 1727

used in coordination with DoDAF to ensure that these specific types of data meet established 1728

Federal standards. 1729

1730

29

DoDD 8115.01, 10 30

Intelligence Reform and Terrorism Prevention Act of 2004 (IRTPA), PL 108-458 (December 17, 2004) 31

Information Sharing Environment Enterprise Architecture Framework (DRAFT) June, 2008. Office of the

Program Manager, Information Sharing Environment


51 DRAFT


7. METHODOLOGIES. 1731

1732 This section introduces a methodology-based approach to architecture development in DoD, 1733

draws on the methodology originally introduced in DoDAF 1.5, and expands on that 1734

methodology to highlight its use in a data-driven, net-centric architecture development 1735

environment. The methodology contained in this section is notional, represents best practices 1736

that have evolved over time, and can be utilized in conjunction with, or as a replacement for 1737

other methodologies, as described below. 1738

1739

7.1 Methodology Based Approach to Architecture 1740 The Webster’s II New College Dictionary 2001 defines methodology as 1) the system of 1741

principles, procedures, and practices applied to a particular branch of knowledge, and, 2) the 1742

branch of logic dealing with the general principles of the formation of knowledge. Generally 1743

speaking, knowledge is gained through the acquisition of, and effective use of information 1744

organized from data for a particular purpose. 1745

An architecture development methodology specifies how to derive relevant information about an 1746

enterprise’s processes and business or operational requirements, and how to organize and model 1747

that information. Architecture methods describe consistent and efficient ways to collect data, 1748

organize the data in a particular grouping or structure, and store collected data for later 1749

presentation and use in decision-making processes. A methodology also provides a means for 1750

replicating the steps taken to create an architecture for a specific purpose later, by another person 1751

or team with the expectation of achieving similar results. 1752

In turn, through utilization of a method, it is possible to compare architectures created under the 1753

same, or similar methods, evaluate how disparate architectures can be linked to provide a higher-1754

level picture of a process or capability, and to analyze the impact of future change. These 1755

analyses can include: 1756

• Static Analyses – which could include capability audit, interoperability analysis, or 1757

functional analysis. These analyses are often performed using simple analysis tools such as 1758

“paper-based” comparisons and database queries. 1759

• Dynamic Analyses – sometimes referred to as executable models, these analyses typically 1760

examine the temporal, spatial, or other performance aspects of a system through dynamic 1761

simulations. For example, these analyses might be used to assess the latency of time 1762

sensitive targeting systems or conduct traffic analyses on deployed tactical networks under a 1763

variety of loading scenarios. 1764

• Experimentation – the use of tactical capability requirements, such as the Coalition Warrior 1765

Interoperability Demonstration (CWID), sponsored annually by the JCS, and various battle 1766

labs to provide the ability to conduct human-in-the-loop simulations of operational activities. 1767

Differing degrees of live versus simulated systems can be deployed during these experiments 1768

and there is a high degree of control over the experiment variables. These can be used for a 1769

variety of purposes. 1770

The six-step method described below is a generic, time-tested method, which can be utilized, in a 1771

wide range of architecture requirements through relatively simple adaptation. The examples 1772


52 DRAFT


described within the steps provide information on customization of the generic method for use in 1773

major departmental functions and operations. 1774

NOTE: The methodology described in this section is applicable to development of service-1775

oriented architecture(SOA). The steps described in the methodology, together with the 1776

requirements of the toolset, techniques and notation desired, should be considered together 1777

when defining a SOA. Volume 2 provides specific views that are useful for services-specific 1778

data collection, and presentation models and documents that describe services. 1779

If another method is desired, then utilization of the information contained in this Volume, 1780

Volume 2, the technical specifications of DoDAF, and Volume 3, the DoDAF Meta-model, 1781

provide the information needed for use in developing an architecture. When utilizing another 1782

method, reference to the notional methodology can ensure adherence to the principles described 1783

in DoDAF 2.0, to maximize the potential for reuse of essential data, and also to ensure 1784

conformance with DoDAF 2.0. 1785

7.1.1 6-Step Architecture Development Process. The high-level, six-step architecture 1786

development process provides guidance to the architect and architecture development team and 1787

emphasizes the guiding principles described in section 3.5.1. The process is data-centric rather 1788

than product-centric (e.g. it emphasizes focus on data, and relationships among and between 1789

data, rather than DoDAF products and views). This data-centric approach ensures concordance 1790

between views in the architecture while ensuring that all essential data relationships are captured 1791

to support a wide variety of analysis tasks. The views created as a result of the architecture 1792

development process provide visual renderings of the underlying architecture data and convey 1793

information of interest from the architecture needed by specific user communities or decision 1794

makers. Figure 7.1.1-1 depicts this six-step process. 1795

1796

NOTE: It is important to note in this section that the development of architecture is an iterative 1797

process and a unique one, in that every architecture is: 1798

• Different in that architecture creation serves a specific purpose, and is created from a 1799

particular viewpoint 1800

• Serving differing requirements, necessitating different types of views to represent the 1801

collected data 1802

• Representative of a ‘snapshot in time’ (e.g., the architecture may represent the current 1803

view or baseline, or it may represent a desired view in some future time) 1804

• Changeable over time as requirements become more focused or additional knowledge 1805

about a process or requirement becomes known. 1806

1807

The methodology described below is designed to cover the broadest possible set of 1808

circumstances, and also to focus on the most commonly used steps by the architecture 1809

community. 1810

1811


53 DRAFT


1812 Figure 7.1.1-1: Architecture Development Six-Step Process 1813

1814

1815

7.1.1.1 Step 1: Determine Intended Use of Architecture. Defines the purpose and intended 1816

use of the architecture (“Fit for Purpose”); how the architecture effort will be conducted; the 1817

methods to be used in architecture development; the data categories needed; the potential impact 1818

on others; and the process by which success of the effort will be measured in terms of 1819

performance and customer satisfaction. This information is generally provided by the process 1820

owner to support architecture development describing some aspect of their area of responsibility 1821

(process, activity, etc.). 1822

1823

A template for collection of high-level information relating to the purpose and scope of the 1824

architecture, its glossary, and other information, has been developed for registration of that data 1825

in DARS. An electronic copy is found on the public page of DARS, and additional information 1826

is contained in the DoDAF Journal, https://www.us.army.mil/suite/page/454707. 1827

7.1.1.2 Step 2: Determine Scope of Architecture. The scope defines the boundaries that 1828

establish the depth and breadth of the architecture and establish the architecture’s problem set, 1829

helps define its context and defines the level of detailed required for the architecture content. 1830

While many architecture development efforts are similar in their approach, each effort is also 1831

unique in that the desired results or effect may be quite different. As an example, system 1832


54 DRAFT


development efforts generally focus first on process change, and then concentrate on those 1833

automated functions supporting work processes or activities. In addition to understanding the 1834

process, discovery of these ‘system functions’ is important to decide how to proceed with 1835

development or purchase of automation support. 1836

Architecture development to describe services utilization within a process collect information 1837

similar in type to systems, with additional data collection of information concerning 1838

subscriptions, directory services, distribution channels within the organization, and supporting 1839

systems/communications web requirements. 1840

1841

Similar situations occur with architecture development for joint operations. Joint capabilities are 1842

defined processes with expected results, and expected execution capability dates. The 1843

architectures supporting the development of these types of capabilities usually require the reuse 1844

of data already established by the military services and agencies, analyzed, and configured into a 1845

new or updated process that provides the desired capability. Included are the processes needed 1846

for military service and/or agency response, needed automation support, and a clear definition of 1847

both desired result and supporting performance metrics. These types of data are presented in 1848

views further described in Volume 2. 1849

The important concept for this step is the clarity of scope of effort defined for the project that 1850

enables an expected result. Broad scoping or unclear definition of the problem can delay or 1851

prevent success. The process owner has the primary responsibility for ensuring that the scoping 1852

is correct, and that the project can be successfully completed. 1853

Clarity of scope can better be determined by defining and describing the data to be used in the 1854

proposed architecture in advance of the creation of views that present desired data in a format 1855

useful to managers. Early identification of needed data, particularly data about the architecture 1856

itself, the subject-matter of the proposed architecture, and a review of existing data from COIs, 1857

can provide a rich source for ensuring that architectures, when developed, are consistent with 1858

other existing architectures. It also ensures conformance with any data-sharing requirements 1859

within the Department or individual COIs, and conformant with the DoDAF Meta-model 1860

described in Section 9. 1861

1862

An important consideration beginning with this and each subsequent step of the architecture 1863

development process is the continual collection and recording of a consistent, harmonized, and 1864

common vocabulary. The collection of terms should continue throughout the architecture 1865

development process. As architecture data is identified to help clarify the appropriate scope of 1866

the architecture effort, vocabulary terms and definitions should be disambiguated, harmonized, 1867

and recorded in a consistent AV-2 process documented in the “DoDAF Architecture 1868

Development Process for the Models” Microsoft Project Plan. 1869

Analysis of vocabularies across different architectures with similar scope may help to clarify and 1870

determine appropriate architecture scope. Specific examples of data identification utilizing the 1871

AV-2 Data Dictionary construct are found in the DoDAF Journal, 1872


1874

7.1.1.3 Step 3: Determine Data Required to Support Architecture Development. The 1875


55 DRAFT


required level of detail to be captured for each of the data entities and attributes is determined 1876

through the analysis of the process undergoing review conducted during the scoping in Step 2. 1877

This includes the data identified as needed for execution of the process, and other data required 1878

to effect change in the current process, e.g. administrative data required by the organization to 1879

document the architecture effort. These considerations establish the type of data collected in 1880

Step 4, which relate to the architecture structure, and the depth of detail required. 1881

1882

The initial type of architecture data content to be collected is determined by the established scope 1883

of the architecture, and recorded as attributes, associations, and concepts as described in the 1884

DoDAF meta model (DM2). A mapping from DM2 concepts, associations, and attributes to 1885

architecture models is provided that suggests relevant architecture views the architect may 1886

develop (using associated architecture techniques) during the more comprehensive and coherent 1887

data collection of Step 4. This step is normally completed in conjunction with Step 4, a bottom-1888

up approach to organized data collection, and architecture development typically iterates over 1889

these two steps. As initial data content is scoped, additional data scope may be suggested by the 1890

more comprehensive content of architecture views desired for presentation or decision-making 1891

purposes. 1892

This step can often be simplified through reuse of data previously collected by others, but 1893

relevant to the current effort. Access to appropriate COI data and other architecture information, 1894

discoverable via DARS and the DoD Metadata Registry, can provide information on data and 1895

other architecture artifacts and views that may provide useful in a current effort. 1896

1897

Work is presently underway within the Department to ensure uniform representation for the 1898

same semantic content within architecture modeling, called "Architecture Modeling Primitives”. 1899

The Architecture Modeling Primitives, hereafter referred to as Primitives, will be a standard set 1900

of modeling elements, and associated symbols mapped to DM2 concepts and applied to 1901

modeling techniques. Using the Primitives to support the collection of architecture content and, 1902

in concert with the Physical Exchange Specification, will aid in generating common 1903

understanding and communication among architects in regard to architecture views. As the 1904

Primitives concepts are applied to more modeling techniques, they will be updated in the 1905

DoDAF Journal and details provided in subsequent releases of DoDAF. The full range of 1906

Primitives for views, as with the current BPMN Primitives, will be coordinated for adoption by 1907

architecture tool vendors. 1908

1909

NOTE: As of the distribution of this Volume for the Community-Wide Review, comments 1910

provided by the Core Management Stakeholders have not been resolved concerning the 1911

“Architecture Modeling Primitives.” It is intended to resolve the comments with the 1912

Stakeholders during the Community Review Period. 1913 1914

7.1.1.4 Step 4: Collect, Organize, Correlate, and Store Architecture Data. 1915

Architects typically collect and organize data through the use of architecture techniques designed 1916

to use views (e.g. activity, process, organization, and data models as views) for presentation and 1917

decision-making purposes. . Terms and definitions recorded are related to elements of the 1918

DoDAF Meta-model (DM2). 1919


56 DRAFT


1920

Designation of a data structure for the architecture effort involves creation of a taxonomy to 1921

organize the collected data. This effort can be made considerably simpler by leveraging existing, 1922

registered artifacts registered in DARS of the DM2, to include data taxonomies and data sets. 1923

Each COI maintains its registered data on DARS, either directly or though a federated approach. 1924

In addition, some organizations, such as US Joint Forces Command (JFCOM), have developed 1925

templates, which provide the basis of a customizable solution to common problems, or 1926

requirements, which includes datasets already described and registered in the DoD Metadata 1927

Registry. Examples of this template-based approach are in the DoDAF Journal. 1928

1929

DARS provides more information that is specific, and guidance on retrieving needed data 1930

through a discovery process. Once registered data is discovered, the data can be cataloged and 1931

organized within a focused taxonomy, facilitating a means to determine what new data is 1932

required. New data is defined, registered in DARS, and incorporated into the taxonomy structure 1933

to create a complete defined list of required data. The data is arranged for upload to an 1934

automated repository, such as DARS, to permit subsequent analysis and reuse. Discovery 1935

metadata (i.e., the metadata that identifies a specific architecture, its data, products, and usage) 1936

should be registered in DARS as soon as it is available to support discovery and enable 1937

federation. Architects and data managers should use the DoD EA Business Reference Model 1938

(DoD EA BRM) 10

taxonomy elements as the starting point for their registration efforts. 1939

Additional discovery metadata, such as processes and services may be required later, and should 1940

follow the same registration process. 1941

1942

7.1.1.5 Step 5: Conduct analyses in support of architecture objectives. Architecture data 1943

analysis determines the level of adherence to process owner requirements. This step may also 1944

identify additional process steps and data collection requirements needed to complete the 1945

architecture and better facilitate its intended use. Validation applies the guiding principles, 1946

goals, and objectives to the process requirement, as defined by the process owner, along with the 1947

published performance metrics, to determine the achieved level of success in the architecture 1948

effort. Completion of this step prepares the architecture for approval by the process owner. 1949

Changes required from the validation process result in iteration of the architecture process 1950

(repeat steps 3 through 5 as necessary). 1951

1952

7.1.1.6 Step 6: Document Results in Accordance with Architecture Framework. The final 1953

step in the architecture development process involves creation of architecture views based on 1954

queries of the underlying data. Presenting the architecture data to varied audiences requires 1955

transforming the architecture data into meaningful presentations for decision-makers. This is 1956

facilitated by the data requirements determined in Step 3, and the data collection methods 1957

employed during Step 4. 1958

1959

DoDAF 2.0 provides two types of views. ‘DoDAF-described Views’ are those views described 1960

in Volume 2 that enable an architect and development team to create views whose data has 1961

already been defined and described consistent with the DoDAF meta-model. These views 1962

include those previously described in earlier versions of DoDAF, along with new views 1963


57 DRAFT


incorporated from the Ministry of Defense (UK) Architecture Framework ( MODAF), the 1964

NATO Architecture Framework (NAF), and The Open Group Architecture Framework 1965

(TOGAF) that have relevance to DoD architecture development efforts. 1966

1967

The second type of views, ‘Fit-for-purpose Views’, are user-defined views that an architect and 1968

development team can create to provide information necessary for decision-making in a format 1969

customarily used in an agency. These views should be developed consistent with the DoDAF 1970

meta-model, but can be in formats (e.g. dashboards, charts, graphical representations, etc) that 1971

are normally used in an agency for briefing and decision purposes. An architecture development 1972

effort can result in an architecture that is a combination of DoDAF-described views and Fit-for-1973

purpose Views. 1974

1975

DoDAF does not require specific views, but suggests that local organizational presentation types 1976

that can utilize DoDAF-created data are preferred for management presentation. A number of 1977

available architecture tools support the creation of views described in this step. The PES 1978

provides the format for data sharing. 1979

1980

1981 1982

7.1.2 Accommodating Multiple Methods for Implementation. DoDAF v2.0 is designed to 1983

be flexible in development of architectures supporting all tiers, capabilities, component-level 1984

views, and specific functional or operational requirements. The method described within the 1985

Framework is generic, and can be used in conjunction with other frameworks, tools, or 1986

techniques to achieve the desired result. Specifically, the conceptual model supporting DoDAF 1987

v2.0 can be used to develop both relational and object-oriented (OO) databases in a wide variety 1988

of formats; supports both the structured analysis and Object-oriented analysis and design 1989

modeling techniques and their specific notations; and continues to support previous versions of 1990

this framework. 1991

1992

Many architectures are created utilizing data from architectures developed previously under 1993

another framework (i.e., MODAF, NAF, TOGAF). It is also possible, through data mapping, to 1994

link that data to the DoDAF v2.0 conceptual and logical data models, since the data models 1995

supporting these frameworks are based on either the predecessor C4ISR Framework or DoDAF, 1996

v1.0. 1997

1998

7.1.3 Architecture Life Cycle & Architecture Governance. Architecture development is only 1999

one phase of an overall architecture life cycle, similar to other process maturity and change life 2000

cycles. One such life cycle, the Architecture Governance, Implementation, and Maturity Cycle, 2001

NOTE: While DODAF does not require specific views in an architecture, several JCS

and DOD publications do require specific views in response to their stated requirements.

Managers and architects, in deciding what views are created in an architecture

development effort, must consider those specific requirements in order to ensure that the

architecture developed is useful in satisfying those requirements.


58 DRAFT


shown in Figure 7.1-1 below, is described in detail in the DoDAF Journal, 2002

https://www.us.army.mil/suite/page/454707. This life cycle relies on the commonly used Plan-2003

Do-Check-Act (PDCA) governance method. 2004

2005

2006

2007

2008 Figure 7.1-1: PDCA Cycle 2009

2010 2011

2012

7.1.4 Planning for Architecture Development. Planning an architecture effort involves more 2013

than selection of a method for development. The architecture effort starts with the identification 2014

of a requirement, problem, or desired change by the process owner – the senior official 2015

responsible for the overall operation of the functional, tactical, component or JCA. The process 2016

owner selects a team leader and team members who will actively participate in the architecture 2017

effort. That team may have a varying membership, generally including an enterprise architect, 2018

and subject matter experts in the process area undergoing analysis and potential change, and will 2019

refine the process owner’s vision and/or initial requirement into a project through development 2020

of an appropriate architecture, as shown in the steps in sections 6.1.1, and in Section 10, 2021

Architecture Planning. 2022

2023 Managers and decision-makers are generally not technicians or information architects. They do, 2024

however, have a vital part in the decisions that need to be made early in the planning process to 2025

define the types of views they need to support their involvement in the decision-making process. 2026

Organizations differ in the type of presentation materials they prefer (i.e. dashboards, charts, 2027

tables, etc.) and these preferences need to be accommodated during architecture development. 2028

Toolsets should be selected that have the capability to provide these management views and 2029

products, along with the ability to collect and organize data consistent with the DoDAF meta-2030


59 DRAFT


models to facilitate reuse. A detailed discussion of toolset requirements and capabilities is 2031

contained in the DoDAF Journal, https://www.us.army.mil/suite/page/454707. 2032

2033 7.1.5 Approaches to Architecture Development. Several methodologies, with supporting 2034

tools, techniques, and notations (i.e., a set of written symbols used to represent something such 2035

as activity, decisions, systems, applications, interfaces, etc.) exist for developing architectures. 2036

While DoDAF does not promote a specific approach, the DoDAF provides the rules, standard 2037

entities, and relationships for developing architectures in a semantically consistent and 2038

interoperable fashion. The DoDAF conceptual and logical data models, described in Volumes 1 2039

and 2, along with the Physical Exchange Specification in Volume 3, have been designed to 2040

facilitate adoption of DoDAF by a wide range of toolsets and techniques. The DoDAF Meta-2041

model should be used as the principal reference for creating the data structures in toolsets to 2042

ensure both interoperability and reuse capabilities. An achievable level of commonality among 2043

the notations is possible when basing architecture development on the DoDAF 2.0 conceptual 2044

and logical data models. 2045

2046

2047 2048

The two most common techniques—the Structured Analysis and Design (SADT) Approach and 2049

the Object-oriented Analysis & Design (OOAD) Approach—are discussed briefly below. 2050

Examples of the notation supporting these techniques are presented in examples contained within 2051

Volume 2. Either of these techniques can be used with the methodology described above, or by 2052

others, such as MODAF, NAF, TOGAF, or other Government or commercial offerings. 2053

2054

7.1.5.1 Structured Technique Overview. Architectures developed under a structured 2055

analysis-driven approach are process-oriented and characterized by a hierarchical process 2056

decomposition. Historically, structured models generally used in DoD originated from the 2057

Integration Definition Language developed by the US Air Force, and later used to develop the 2058

Activity Modeling standard (IDEF0) [IDEF0 1993] a Federal Information Processing Standard 2059

(FIPS) published by the National Institutes for Standards & Technology (NIST). This technique 2060

evolved from an earlier, also process-driven approach, Structured Analysis and Design 2061

Technique (SADT), developed for the U.S. Air Force Materiel Command. More recently, 2062

architecture development using structured methods has also included those utilizing the Business 2063

Process Modeling Notation (BPMN), developed by the Business Process Management Initiative, 2064

and currently managed by the Object Management Group (OMG). 2065

7.1.5.1.1 Process Data Flow.. A process flow diagram (PFD) is a graphical representation of 2066

the "flow" of data through a process. With a process flow diagram, users are able to visualize 2067

how the process will operate, what the process will accomplish, and how the process is executed 2068

NOTE: Several commercial toolsets that are commonly used to develop architecture

views still use the terms ‘model’ of ‘diagram’ to describe those views. Within this

chapter, we continue to use the terms ‘model’ and ‘diagram’, as they are used by

toolset vendors, in order to avoid confusion. However, a model or diagram created by

a toolset, using an appropriate notation, and included in a set of views in a DoD

architecture should be understood as a ‘view’ within DoDAF.


60 DRAFT


normally. Process flow diagrams can be used to provide the end user with a physical idea of the 2069

resulting actions that occur on data input, and how their actions ultimately have an effect upon 2070

the structure of the whole process. Process flow diagrams also define desired or required 2071

system-level functions—the level and type of automation desired to improve the time, efficiency, 2072

and results of executing a process. 2073

7.1.5.1.2 Process Task-Dependency Diagram. Process Task Dependency (PTD) Diagrams 2074

lay out clearly the step-by-step flow of a process by tracking the flow of material, information or 2075

a service through all its steps in a logical or required order. The PTD diagram assists an 2076

unfamiliar audience to picture the steps of a process and clarifies misconceptions about how the 2077

process actually operates, while providing a reference for the handling of corrective action or 2078

process improvement. Task-sequence notations work especially well for “uninterruptible” 2079

processes, meaning a set of steps that exhibits clear dependencies, doesn’t execute until 2080

explicitly triggered, and normally continues until it achieves a clear exit criterion. Such 2081

processes are generally low-level and detailed, and useful, among other things, for: 2082

2083

• Defining detailed performance metrics and metrics capture 2084

• Establishing an information base for executable architecture/process simulation 2085

• Defining automation functional requirements 2086

2087

7.1.5.1.3 Entity-Relation Model. The Entity-Relation Model describes the structure of an 2088

architecture domain’s system data types and the business process rules that govern the 2089

system data. It provides a definition of architectural domain data types, their attributes or 2090

characteristics, and their interrelationships. 2091

2092 7.1.5.2 Object-Oriented Technique Overview. Object-oriented architecture views are 2093

created utilizing the Unified Modeling Language (UML) architecture technique and notation, 2094

together with the DoDAF logical and Physical Exchange Specification data structures. This 2095

technique describes the operational need, places data (objects, or ‘performers’ in the DoDAF 2096

data structure) in the context of its use, and provides a traceable foundation for system and 2097

software design. It is based on the concepts of data abstraction and inheritance from a service-2098

oriented view. The object-oriented technique provides an orderly arrangement of the parts of the 2099

business organization and includes a style and method of design through its highly developed 2100

notation style. 2101

2102

7.1.5.2.1 Process – Activity Diagram, Object-Sequence Diagram. An activity diagram is 2103

frequently used in conjunction with a process flow diagram that describes the sequence and other 2104

attributes (i.e. timing) of the activities. A process flow diagram further captures the precedence 2105

and causality relations between situations and events. In object modeling, Activity diagrams 2106

address the dynamic view of the system. They are especially important in modeling the function 2107

of a system and emphasize the flow of control among objects. An object diagram shows a set of 2108

objects (i.e. performers) and their relationships. Object diagrams represent static snapshots of 2109

instances of things found in class diagrams. 2110

2111


61 DRAFT


7.1.5.2.2 Data – Object Class Diagram. Class diagrams offer all the UML elements 2112

needed to produce entity-relationship diagrams. Class diagrams consist of classes, interfaces, 2113

collaborations, dependency, generalization, association, and realization relationships. The 2114

attributes of these classes can be expanded to include associations and cardinality [Booch, 2115

1999]. In terms of support to DoDAF 1.5, Classes that appear in an OV-7 class diagram 2116

correlate to OV-3 information elements and OV-5 inputs and outputs. The OV-7 class diagram 2117

is a separate diagram from the class diagrams that may be developed for other products. 2118

2119

7.2 System (Component, Package, Deployment) Diagram. DoDAF 2.0 provides extensive 2120

architecture support for the systems engineering process. As the process of developing the 2121

system architecture moves from the high-level concept (e.g., system interface description, system 2122

overview diagram) to more detailed views, it becomes useful to create multiple models so that 2123

specialized views of the architecture can be depicted. Three important diagrams are the 2124

Component Model, which focuses on functional features of the system; the Package Diagram, 2125

which focuses on grouping of components for specific purposes; and the Deployment/ 2126

Operational Model, which focuses on the physical runtime infrastructure on which functional 2127

components will be deployed. 2128

2129

The value of using multiple models arises from the fact that each of these models begins to call 2130

upon different skills and knowledge sets as the level of detail increases. Since these diagrams/ 2131

models are dependent upon each other, they cannot be created in complete isolation. The 2132

architecting process thus becomes an iterative process, defining portions of each of these 2133

diagrams, then evaluating how each fits with the other, and making revisions that optimize the 2134

diagrams so they support each other effectively. 2135

2136

7.2.1 Component Model and Package Diagram. A Component Model describes the 2137

hierarchy of functional components, their responsibilities, static relationships, and the way 2138

components collaborate to deliver required functionality. A component is a relatively 2139

independent part of an IT System and is characterized by its responsibilities, and the interfaces it 2140

offers. Components can be decomposed into smaller components or aggregated into larger 2141

components. Some components already exist, but it may be necessary to build or buy others. A 2142

component can be a collection of classes, a program (e.g., one that performs event notification), a 2143

part of a product, or a hardware device with embedded functional characteristics (e.g., a Personal 2144

Digital Assistant [PDA]). Some are primarily concerned with data storage. A more 2145

comprehensive treatment of Component Models is found in the DoDAF Journal, 2146


2148

7.2.2 Deployment/Operational Model. The Operational Model describes the operation of the 2149

IT system, as illustrated below in Figure 7.2.2-1. This model is derived primarily from the 2150

operational requirements) placed on the e-business application. Like the Component Model, the 2151

Operational Model is typically developed through a series of progressively more detailed 2152

elaborations (i.e., Conceptual, Specified, and Physical). Also like the Component model, at each 2153

level of elaboration there may be a need to create more than one view of the Operational Model 2154

so that no single view becomes overloaded by attempting to convey too much information. A 2155


62 DRAFT


more comprehensive treatment of the Deployment/Operational Model is contained in the 2156


2158 E SS

«node» *

: MF Residence Installation

«node»: Central Monitoring Station

«hardware»: CM Server

allocatedFrom«software» S/W Distrib Mgr«software» System CM

«hardware»: DB Server

allocatedFrom«software» CMS RDBMS«data» CMS Database

«hardware»: MS LAN

«hardware»: Application Server

allocatedFrom«software» MS Comm I/F«software» MS Event Monitor«software» PS Report Mgr«software» PS Request Mgr«software» Site Interface Mgr

«hardware»: Video Server

«hardware»: PS Comm

I/F

«hardware»: Help Desk Client

«internal actor»

: Help Desk Operator

«node» *

: Business Installation

«hardware»: Phone Lines

«external»: CommNetwork

*: SF Residence Installation

«hardware»2

: Video Camera«hardware»

: DSL Modem

«hardware»: Site Hard Disk

allocatedFrom«data» Site Database

«hardware»*

: Optical Sensor

«hardware»: Alarm

«hardware»2

: DVD-ROM Drive

allocatedFrom«data» Site Database

«hardware»: NW Hub

allocatedFrom«software» SF Comm I/F

«hardware»: User Console

«hardware»: Site Processor

allocatedFrom«software» Device Mgr«software» Event Mgr«software» Site Config Mgr«software» Site RDBMS«software» Site Status Mgr«software» User I/F«software» User Valid Mgr

ibd [system] ESS

2159 Figure 7.2.2-1: Deployment/Operational Model 2160

2161


63 DRAFT


8. ARCHITECTURE PRESENTATION TECHNIQUES 2162

2163 While information is the lifeblood of enterprise architecture, it can be overwhelming to decision 2164

makers when presented in a raw format. Likewise, the structured methodology of modeling 2165

enterprise architecture information is both necessary and useful for creating architectures that can 2166

be shared between organizations. However, many of the ‘traditional’ architecture products are 2167

unwieldy because of their format and are useful only to trained architects. Many organizations 2168

develop a “mandated” architecture but make it expensive shelf-ware instead of using it to 2169

communicate important, accurate, and relevant information to the stakeholders who need it. 2170

Architects must be able to communicate architecture information in a meaningful way to process 2171

owners and other stakeholders, or the discipline of enterprise architecture will soon meet an 2172

untimely demise. 2173

2174

The results of architecture-related data collection need to be presentable to non-technical senior 2175

executives and managers at all levels. Many managers are skilled decision-makers, but have not 2176

had technical training in architecture development. Since architecture development efforts are 2177

designed to provide input to the decision-making process, graphical representation of data 2178

needed is a logical extension of the overall process. This section describes these graphical 2179

representations (architects call them 'products' or 'views'). 2180

2181 8.1 Overview. Effective presentation of business information is necessary for architects to tell 2182

the story of the architecture data with stakeholders. Since the purpose of the architecture 2183

discipline is to collect and store all relevant information about an enterprise, or some specific 2184

part of the enterprise, it can reasonably be assumed that the majority of information needed by an 2185

organization’s decision makers is contained somewhere in the architecture data. Many of the 2186

existing architecture methods are valuable for organizing architecture information, but less 2187

valuable for communicating that information to stakeholders. Presentation views are always 2188

dependent on the quality of the architecture information that is collected through the rigor of 2189

architecture methods. As figure 8.1-1 illustrates, presentation techniques pull from the 2190

architecture information store and display the data in a variety of meaningful ways to 2191

stakeholders. 2192


64 DRAFT


2193 Figure 8.1-1 Presentation Techniques 2194

2195

The presentation techniques and best practices described here (And documented more fully in 2196

Volume 2) were developed based on the idea that business information, captured both internally 2197

and externally to an organization’s architecture in support of common user requirements, can be 2198

displayed in a way that enhances clarity and understanding, and facilitates decision-making. 2199

That often means that complex technical information must be ‘translated’ into a form for 2200

presentation that is useful to management. An ‘Information Bridge’, as shown in Figure 8.1-2 is 2201

the link between the architect and management. The bridge provides the means to take technical 2202

information, and recast that information in graphical or textual terms that consistent with the 2203

culture of the organization. 2204

2205

2206 Figure 8.1-2 The Information Bridge 2207

2208

DoDAF, Version 1.0 and Version 1.5 defined a set of ‘products’ for visualizing, understanding, 2209

and assimilating the broad scope and complexities of an architecture description through graphic, 2210


65 DRAFT


tabular, or textual means. These products can still be produced, and are supported by the sets of 2211

views described in Volume 2. 2212

2213

8.2 Choosing an Appropriate Presentation Technique. In any given business process, 2214

decisions must be made at multiple levels of the organization. Whether one is a senior level 2215

executive, a process owner, or a system developer, he or she will need to make judgment calls 2216

based upon the available data. Each level of decision maker, in turn, has both a unique purpose 2217

and understanding of architecture, making it important to tailor the data in order to maximize its 2218

effectiveness. The presenter, with the help of an experienced architect, must determine the 2219

audience of a presentation before choosing the type of presentation technique to use. Figure 8.2-2220

1, based on the Zachman Framework,32

summarizes the multiple levels of decision makers 2221

within a typical organization that make up an audience. 2222

2223

2224

2225

2226

2227

2228

2229

2230

2231

2232

2233

2234

2235

2236

Figure 8.2-1 Levels of Decision-Makers 2237 2238

2239

2240

Each level has differing requirements for presentation of data. Level 1 Planners may find a 2241

graphical wall chart more useful in making decisions, whereas a Level 4 Builder will most likely 2242

require a more technical presentation, one relating more directly to the architecture. Level 5 sub-2243

contractors are the workers who will perform the work required, and generally required varying 2244

levels of technical data and other information to accomplish their task. 2245

2246

Narrowing down the type of presentation required is done by asking the following question: 2247

What information does the decision maker need in order to make a data-supported decision? 2248

For each decision level there is a data set that can be manipulated using a presentation technique. 2249

After analyzing the audience and type of information, the presenter should consider the various 2250

32

Zachman, John. Zachman Framework. © Zachman International. The Zachman Framework can be found at the Zachman

International Website: http://zachmaninternational.com/index.php/the-zachman-framework/26-articles/13-the-zachman-

framework-a-concise-definition.


66 DRAFT


types of techniques discussed in this section. Figure 8.2-2 is a simplified representation of the 2251

presentation development 2252

process.2253

2254 Figure 8.2-2: Presentation Development Process 2255

2256

It is imperative to realize that when choosing how to present data sets, there is no limit on what. 2257

views to use. There are countless ways to display information to decision makers, and it is up to 2258

the presentation developer to determine the most effective way to accomplish this task. This 2259

section describes a base of view development techniques to start from, each created to serve its 2260

own unique purpose. Details are provided on five different presentation techniques that have 2261

proven to be useful in engaging various audiences. 2262

2263

A more detailed discussion of DoDAF Meta-model Groups is provided in Volume 2, Section 2, 2264

that includes a description and purpose for each group, the data capture method, and the use of 2265

each group.. There are the DoDAF-described Views that derive from and conform to the 2266

DoDAF Meta-model. Additionally, within each view are a number of described presentation 2267

views that present differing sets of possible representations, with their associated data. 2268

2269

Alternatively, user-defined views, called Fit-for-purpose Views can be created, utilizing 2270

DoDAF-conformant data that provide other forms of graphical presentation. These use 2271

presentation that are more common to briefings and decision analysis The five techniques 2272

commonly used are: 2273

2274

• Composite Products: Display multiple pieces of architecture in formats that are relevant 2275

to a specific decision maker (Section 8.3) 2276

2277


67 DRAFT


• Dashboards: Integrate abstracted architecture information for a given business context 2278

(Section 8.4) 2279

2280

• Fusion Products: Display multiple pieces of architecture and incorporate disparate 2281

pieces of information that are not captured within the architecture (Section 8.5) 2282

2283

• Graphics: Visually represent manipulated data (Section 8.6) 2284

2285

• Reference Models: Capture the elements of the architecture products and translate those 2286

elements into text (Section 8.7) 2287

Fit-for-purpose Views provide wide flexibility for the architect and process owner to create 2288

architecture views easily understood and useful to management for decision-making purposes. 2289

Each of these types of views is described below. 2290

2291

2292

8.3 Composite Views. A composite view displays multiple pieces of architecture in formats 2293

that are relevant to a specific decision maker. By drawing information from numerous sources, 2294

this presentation technique provides a holistic view for the audience. Contrasting two or more 2295

snapshots next to each other, composite products allow for an easy comparison. As seen in 2296

Figures 8.3-1, and 8.3-2, below. These views will be comprised of related architecture products 2297

that directly support each other (i.e., system functions in an SV-4 that support activities in an 2298

OV-5). The view can be graphically displayed in three dimensions to tie the pieces of 2299

architecture together. 2300

2301

8.3.1 Purpose and Audience. Composite views allow decision makers to view important 2302

relationships in data without reading through large pieces of architecture. Most business owners 2303

are interested only in their particular business area and its immediate interconnections. By 2304

placing relevant parts of architecture directly in front of the audience, it is easier to gain a 2305

comprehensive understanding of the data in an efficient manner. The audience that will find 2306

these products most useful are: 2307

• Process Owners who have direct staff oversight or technical systems expertise and 2308

require high level conceptual briefings 2309

• Designers—implementers of the initiative, who require information detailing specifics of 2310

implementation 2311

• Builders—System architects who require details on how to implement and use products. 2312

2313

8.3.2 Examples. Figure 8.3.2-1 illustrates a simplified example of a Composite View. The 2314

activity Determine Accession Type is supported by the system function Maintain Candidate Data 2315

via User Interface. The information to support this system function includes Accession Type 2316

Information and Other Candidate Information. The activity is carried out by a Human Resource 2317

Specialist. 2318

2319


68 DRAFT


Determine Accession

Type

Accession Type Information

Other Candidate

Information

Maintain Candidate Data

via User Interface

Human Resource Specialist

Activity from OV-5 Node Connectivity

Information Exchange from OV-5 Activity

Model

System Function from

SV-4 Role from OV-2

2320 Figure 8.3.2-1: Example Composite View 2321

2322

Figure 8.3.2-2 illustrates a final version of a different Composite View. Four architecture 2323

samples are displayed, and a three-dimensional Capability label lets the audience know the 2324

common tie. 2325

2326

2327 Figure 8.3.2-2: Another Composite View 2328

2329

Composite views are ideal for explaining interconnections between architectures. The audience 2330

will more easily understand relationships in data by viewing manageable slices of mappings all 2331

at once. The developer of this product can interchange architectures easily, highlighting the most 2332

important parts for the audience. Composite views are neither wordy, nor oversimplified. 2333

Additionally, they can be used by a wide range audience. 2334

2335

8.4 Dashboard Views. Dashboards integrate abstracted architecture information for a given 2336

business context and are generally geared to displaying information required by a specific 2337


69 DRAFT


stakeholder. A well-constructed dashboard consists of a status, trend, or a variance to a plan, 2338

forecast, or budget (or combination thereof). Dashboards are generally user friendly, providing 2339

easy access to enterprise data to enable organizations to track performance and optimize 2340

decision-making. High-level decision makers generally like dashboards because dashboards are 2341

frequently used in other business contexts besides enterprise architecture, and decision makers 2342

have a familiarity with this presentation tool. In addition, the dashboard is formatted so key 2343

stakeholders can review valuable, insightful information at a glance to manage their 2344

organization’s performance goals effectively. 2345

2346 8.4.1 Purpose and Audience. The visual qualities of a dashboard allow executives and 2347

managers to identify which of their business areas are successful and which are problem areas 2348

that need immediate attention. Like all enterprise architecture presentation techniques, the 2349

dashboard must be designed with the stakeholder audience in mind and should be geared towards 2350

the audience’s specific goals. One of the most important goals in creating a dashboard is to 2351

deliver a highly intuitive tool that yields greater business insight for decision makers. 2352

2353

Since dashboards display highly aggregated and abstracted information, they are typically 2354

targeted to senior decision makers. However, they are also a great tool to share with junior 2355

architects to ensure they understand key business drivers and concepts as they take a deeper dive 2356

into their respective areas. 2357

2358

8.4.2 Examples. Table 8.4.2-1 illustrates various visualization techniques that can be used to 2359

create a dashboard. 2360

2361

Table 8.4.2-1: Visualization Techniques 2362

Visualization Technique Description When to Use

Pie Chart Pie charts can be used for representing

small sets of information. However, they

are generally considered poor data

visualization for any data set with more

than half a dozen elements. The problem

with pie charts is that it is very difficult to

discern proportional differences with a

radically divided circle, except in the case

of a small data set that has large value

differences within it. Pie charts also pose

a problem for labeling, as they are either

dependent on a color or pattern to

describe the different data elements, or

the labels need to be arranged around the

perimeter of the pie, creating a visual

distraction.

Pie charts should be used to represent

very small data sets that are geared to

high-level relationships between data

elements. Pie charts present

summary level relationships, and

should be used carefully for detailed

analysis.

Bar Chart Bar charts are an ideal visualization for

showing the relationship of data elements

within a series or multiple series. Bar

charts allow for easy comparison of

values, share a common measure, and are

easily compared to one another.

Bar charts are best suited for

categorical analysis but can also be

used for short duration series

analysis (e.g., the months of a year.)

A presenter needs to be aware of the

risks in using bar charts if there is a

data set that has one element with a


70 DRAFT


large outlier value; this will render

the visualization for the remaining

data elements unusable. This chart

scale is linear, and will not clearly

represent the relationships between

the remaining data elements.

Line Charts Time series line charts are most

commonly used with the time dimension

along the X-axis and the data being

measured along the Y-axis.

Use line charts when you would like

to see trends over time in a measure,

versus a side-by-side, detailed

comparison of data points. Line

charts are ideal for time series

analysis where you want to see the

progress of one or more measures

over time. Line charts also allow for

comparative trend analysis as you

can stack multiple series of data into

one chart.

Area Charts Area charts can be considered a subset of

the line chart, where the area under or

above the line is shaded or colored.

Area charts are good for simple

comparisons with multiple series of

data. By setting contrasting color

hues you can easily compare the

trends over time between two or

more series.

Tables and Lists Tables and lists contain large amounts of

data that can be categorized into a list or

divided into a table but cannot be easily

compiled into a visual or numerical

analysis tool.

Tables and lists are best used for

information that either contains large

lists of non-numeric data, or data that

has relationships not easily

visualized or does not lend itself to

easy numeric analysis.

2363 2364

Figure 8.4.2-1 illustrates the use of these techniques to create a dashboard. 2365

2366

2367 Figure 8.4.2.-1: Notional Dashboard 2368

2369

2370

2371


71 DRAFT


A dashboard is effective in demonstrating the number of systems supporting an Activity or 2372

modifying a data element. It can provide data from a variety of sources to create a multi-2373

disciplined and multi-dimensional performance feedback. It combines standard components and 2374

building blocks to create an executive dashboard that meets particular needs. 2375

2376

8.5 Fusion Views. A fusion view is very similar to a composite view in that it displays multiple 2377

pieces of architecture in formats that are relevant to a specific decision maker. However, a 2378

fusion view also incorporates disparate pieces of information that are not captured within the 2379

architecture. Fusion views are frequently used to display information that is sensitive in nature 2380

and that is viewed only by certain stakeholders making specific decisions. For example, fusion 2381

views could be used to display funding information regarding a program or system. 2382

2383

8.5.1 Purpose and Audience. Fusion views serve as a single location for viewing disparate 2384

pieces of information from within and outside of the context of the architecture. A fusion view 2385

can be used to bridge the gap between an enterprise architecture analysis, other analysis, and 2386

transformation processes. It is frequently used when making a decision that incorporates 2387

information that has been deliberately not included in the architecture. 2388

2389

Fusion views can be used by all members of the development team (i.e. Planners, Owners, 2390

Designers, Builders, and Subcontractors). Planners use them to review portfolio choices within 2391

the context of the architecture and to determine how choices compare to the portfolio as a whole, 2392

as well as against an individual system or group of systems. Owners use fusion views to review 2393

current progress against planned goals, which may include cost and schedule data or to address 2394

capability gaps within the architecture. Designers, Builders, and Subcontractors can use a more 2395

detailed fusion view to review implementation impacts associated with the development of a 2396

particular system and to show the complexity of the information involved. 2397

2398

8.5.2 Examples. Figure 8.5.2-1 incorporates financial data and support information into an 2399

analysis. The outside information commonly consists of financial data gathered from authorized 2400

sources or scheduling information and constraints gathered from a Work Breakdown Structure 2401

(WBS) or similar reporting mechanism. This can be tailored so that the user can use any data 2402

that is relevant to their needs. 2403

2404


72 DRAFT


2405 Figure 8.5.2-1: Financial Data Fusion View 2406

2407

A similar Fusion view is shown in Figure 8.5.2-2 that does not include the financial data. 2408

2409


73 DRAFT


2410 Figure 8.5.2-2: Fusion View without external financial data 2411

2412

A fusion view is a powerful tool with the ability to portray accurately the relationships between 2413

different types of information. A fusion view can be used to provide a 360-degree view of a 2414

system, validate systems against architectures, show availability of services, or provide a 2415

perspective of a current environment (e.g. a viewpoint) that can be used in decision-making 2416

discussions. 2417

2418

8.6 Graphics Views. A graphic is a representation (as a picture, map, or graph) used especially 2419

for illustration of concepts. In the case of enterprise architecture, graphics views are used for the 2420

pictorial representation and manipulation of data. In other words graphics provide a visual 2421

representation of business information and processes. Graphics views can be of tremendous 2422

benefit in representing multiple concepts in a clean, simple design. 2423

2424

8.6.1 Purpose and Audience. Graphics views provide a visual depiction of the information 2425

and are therefore targeted at visually oriented learners. When properly executed, a graphical 2426

view allows the intended audience to view the information in an uncluttered, easy to understand, 2427

and precise design. Additionally, graphical views can attract attention and cause interest. Most 2428

people understand pictures faster and easier than they do text or model-based documents. 2429

Graphical views provide the presenter with literally unlimited options for displaying their 2430

business concepts and for tailoring their product to the targeted audience. 2431

2432

Because of the lack of underlying complexity, a graphic view tends to be more abstract and is 2433

usually presented to high-level audiences. The identification of the target stakeholder level and 2434

the intended message is the first step in determining whether a graphic view is the appropriate 2435

tool for information delivery. The appropriateness of graphical views can only be determined 2436


74 DRAFT


once the message and stakeholder level have been identified. Graphical depictions of data and 2437

business processes can be tailored to any stakeholder level as long as the intended message and 2438

information can be represented in a logical, reader-friendly form. All levels of decision makers 2439

will find graphical views useful for high-level analysis. 2440

2441

8.6.2 Examples. The use of graphical views is a common practice in DoD and non-DoD 2442

organizations. Because graphical views do not usually show the underlying complexity, it is 2443

important to remember that they are tied to details within the architecture. As with dashboard 2444

views, if a stakeholder does not understand where the information came from, or if they lack 2445

faith in the detailed architecture information, then the graphic view will essentially be 2446

meaningless to them. It is also critical to emphasize the underlying architectural information 2447

when briefing the graphic to senior decision makers. An OV-1, for example, provides a high-2448

level concept description of a business, and is usually the first, and can be the only architecture 2449

product a senior decision maker sees. In order for an OV-1 to have an impact, a decision maker 2450

must be able to see a direct correlation from the graphic view to the detailed aspects of the 2451

business. Figure 8.6.2-1 and Figure 8.6.2-2 illustrate this concept. Each part of the graphic 2452

view corresponds to a detailed area of the overall business, which will be represented and 2453

composed of a complex set of architecture products. The graphical views are also used to show 2454

the relationships between the business areas which come together to form a complete picture. 2455

2456

2457 Figure 8.6.2-1: Non-prescriptive, Illustrative High-level Concept Description (OV-1) 2458

2459


75 DRAFT


2460 Figure 8.6.2-2: Non-prescriptive, Illustrative High-level Concept Description (OV-2) 2461

2462

2463

2464

Graphical views enable the efficient communication of complex quantitative ideas. In a society 2465

that is fascinated with visual stimulation, the use of graphical views provides an attractive and 2466

efficient communications tool. When effectively designed, graphical views can facilitate 2467

understanding and recognition; promote analysis; and support learning and sharing of ideas. 2468

2469

8.7 Reference Models. Reference models provide textural extractions of underlying 2470

architectural data. As Figure 8.7-1 illustrates, reference models capture the elements of the 2471

architecture products, and translate those elements into text. This reference model provides a 2472

framework for describing important elements of the Federal Enterprise Architecture (FEA) in a 2473

common and consistent way. The FEA consists of five reference models: Performance 2474

Reference Model (PRM), Business Reference Model (BRM), Service Component Reference 2475

Model (SRM), Data Reference Model (DRM), and the Technical Reference Model (TRM). 2476

Through the use of this common framework and vocabulary, IT portfolios can be better managed 2477

and leveraged across the Federal Government33

. 2478

33

Federal Enterprise Architecture Consolidated Reference Model Version 2.0. Executive office of the President, Office of




76 DRAFT


2479

2480 Figure 8.7-1: A Notional Reference Model 2481

2482

8.7.1 Purpose and Audience. Reference models are designed to facilitate cross-agency 2483

analysis, through the development of a common taxonomy and ontology for describing the 2484

business operations of Federal agencies, independent of any specific agency. Cross-agency 2485

analysis is used by planners and process owners to identify duplicate investments, gaps, and 2486

opportunities for collaboration within and across agencies. Collectively, the reference models 2487

comprise a framework for describing important elements of the Federal Enterprise Architecture 2488

(FEA) in a common and consistent way. Through the use of this common framework and 2489

vocabulary, IT portfolios can be better managed and leveraged across the Federal government.34 2490

2491

8.7.2 Examples. One example of a reference model is the FEA Business Reference Model 2492

(BRM). The BRM provides an organized, hierarchical construct for describing the day-to-day 2493

business operations of the Federal government. While many models exist for describing 2494

34

Federal Enterprise Architecture Consolidated Reference Model Version 2.0. Executive office of the President, Office of




77 DRAFT


organizations - org charts, location maps, etc. - this model presents the business using a 2495

functionally driven approach. The Lines of Business and Sub-functions that comprise the BRM 2496

represent a departure from previous models of the Federal government that use antiquated, stove-2497

piped, agency-oriented frameworks. The BRM is the first layer of the Federal Enterprise 2498

Architecture, and it is the main viewpoint for the analysis of data, service components, and 2499

technology (See Figure 8.7.2-1).35 2500

2501

2502 Figure 8.7.2-1: BRM Structure 2503

2504

The BRM is broken into four areas: Services for Citizens, Mode of Delivery, Support Delivery 2505

of Services, and Management of Government Resources. The model’s four Business Areas are 2506

decomposed into 39 Lines of Business. Each business line includes a collection of Sub-functions 2507

that represent the lowest level of granularity in the BRM. For example, the Environmental 2508

Management Line of Business encompasses three Sub-functions: (1) Environmental Monitoring 2509

and Forecasting; (2) Environmental Remediation; and (3) Pollution Prevention and Control. 2510

Within each Sub-function are the agency-specific business functions, processes, and activities 2511

(see Figure 8.3.4-2).36 2512

2513

35

Federal Enterprise Architecture - Business Reference Model. The current version can be found at:

http://www.whitehouse.gov/omb/egov/a-3-brm.html 36

Federal Enterprise Architecture Records Management Profile, Version 1.0, December 15, 2005. Executive Office of the

President., Office of Management and Budget. A current version of the profile can be found here:

http://www.cio.gov/documents/RM_Profile_v1.pdf


78 DRAFT


2514 Figure 8.3.4-2: BRM Areas 2515

2516

Federal agencies are currently using the FEA reference models to plan and develop their annual 2517

budgets and set strategic goals. Agencies’ annual budget submissions to OMB for IT must 2518

describe how these investments “align” to the business, performance, service component, and 2519

technical reference models. In practical terms, this means that agencies must describe their IT 2520

investments in terms of the business operations they will support, the functional capabilities they 2521

intend to deliver, the supporting technologies used to build or deliver the capabilities, and 2522

performance impacts.37 2523

2524

By providing a common language to describe the relationship between Federal business 2525

operations, technology, and information, the FEA enables the Government to identify 2526

opportunities to leverage technology which: 2527

2528

• Reduce unnecessary redundancy 2529

• Facilitate intergovernmental information sharing 2530

• Establish a direct relationship between IT and agency performance to support citizen 2531

centered, customer-focused Government 2532

• Maximize IT investments to better achieve mission outcomes38 2533

2534

37

Federal Enterprise Architecture Records Management Profile, Version 1.0, December 15,

2005. Executive Office of the President., Office of Management and Budget. A current version

of the profile can be found here: http://www.cio.gov/documents/RM_Profile_v1.pdf 38

Federal Enterprise Architecture Records Management Profile,


79 DRAFT


9. DODAF META-MODEL 2535

2536

Note: This section describes the DoDAF Meta-model(DM2), which replaces the Core 2537

Architecture Data Model referenced in previous versions of DoDAF. 2538 2539

The DM2 provides a high-level view of the data normally collected, organized, and maintained 2540

in an architecture effort. It also serves as a roadmap for the reuse of data under the federated 2541

approach to architecture development and management. Reuse of data among communities of 2542

interest provides a way for managers in any level or area of the Department to understand what 2543

has been done by others, and also what information is already available for use in their 2544

architecture, and management decision-making efforts. 2545

2546

The DM2 has several levels, each of which is important to a particular viewer of Departmental 2547

processes. A conceptual level or Conceptual Data Model (CDM) is described in this volume 2548

and defines the high-level data constructs from which architectures are created in non-technical 2549

terms,, so that executives and managers at all levels can understand the data basis of architecture. 2550

The Logical Data Model (LDM) adds technical information, such as attributes to the CDM and, 2551

when necessary, clarifies relationships into an unambiguous usage definition. The Logical data 2552

Model is described further in Volume 2. 2553

A Physical Exchange Specification (PES) is described in Volume 3, and consists of the Logical 2554

Data Model with general data types specified and implementation attributes (e.g., source, date) 2555

added, and then generated as a set of XSD’s, one schema per DoDAF-described View, except for 2556

the OV-1. 2557

2558

The DM2 defines architecture data elements and enables the integration and federation of 2559

architectures. It establishes a basis for semantic (i.e. understanding) consistency within and 2560

across architectures. In this manner, the DM2 supports the exchange and reuse of architecture 2561

information among Joint Capability Areas (JCAs), Components, and Federal and Coalition 2562

partners, thus facilitating the understanding and implementation of interoperability of processes 2563

and systems. As the DM2 matures to meet the ongoing data requirements of process owners, 2564

decision makers, architects, and new technologies, it will to a resource that more completely 2565

supports the requirements for architecture data, published in a consistently understandable way, 2566

and will enable greater ease for discovering, sharing, and reusing architecture data across 2567

organizational boundaries. 2568

2569

In order to facilitate the use of information at the data layer, the DoDAF describes a set of views 2570

for visualizing data through graphic, tabular, or textual means. These views are contained in 2571

eight (8) data groups, each of which contribute to more specific views that respond to 2572

requirements for producing an architecture. 2573

2574

a. 9.1 The DoDAF Conceptual Data Model. The CDM defines concepts involving high-2575

level data constructs from which architectures are created, enabling executives and 2576

managers at all levels to understand the data basis of architecture. The CDM also 2577


80 DRAFT


describes the relationships among data constructs in relatively non-technically and easily 2578

understood terms. Figure 9.1-1 is a graphical representation of the CDM. Definitions for 2579

the CDM are in Appendix B. Underlying the CDM is a foundation the utilizes common 2580

data modeling constructs that facilitate the reuse of common data patterns. 2581

2582

The top-level foundation elements are: 2583

2584

a. Thing, similar to other model’s “object” 2585

b. Individual, a “thing” that exists as an indivisible whole, or as a single member of a 2586

category. 2587

c. Type, a set of individuals or classes of other sets or classes 2588

d. Tuple, ordered places of “things” (e.g. a block in a spreadsheet or a table) 2589

2590

These foundation elements are similar to many other foundation high-level data constructs that 2591

exist in the industry. The common patterns that are reused are: 2592

2593

a. Composition (or whole-part) 2594

b. Super/Sub Type (or generalization/specialization, e.g. tank or main battle tank) 2595

c. Before /After, for “things” that have time-related relationships in their Type 2596

d. Interface, for “things” that can exchange other things that are parts of themselves 2597

2598

Composition and Super/Sub Type apply to almost all architecture concepts. Before/After is 2599

frequently used to model before/after situations, while Interface applies to few concepts, limited 2600

at this time to the pattern describing Activity. 2601


81 DRAFT


2602 2603

Figure 9-1: DoDAF Conceptual Data Model 2604 2605

2606


82 DRAFT


2607 2608

10. ARCHITECTURE-BASED ANALYTICS 2609 Architecture-based analytics includes all of the processes that transform architecture data into 2610

useful information in support of the decision making process. Various types of analysis are 2611

described below (static vs. dynamic), along with descriptions of desirable characteristics for the 2612

overall architecture data set needed for successful and accurate analysis capability. Architectures 2613

are an ideal construct to use in decision-making since they represent the most current, and 2614

accurate information about a program or mission requirement. 2615

2616

10.1 Analytics Context 2617 DoDAF 2.0 has been designed to facilitate collection of data usable through quantitative, 2618

repeatable, analytical processes to support decisions at all levels of enterprise and/or system 2619

engineering. Architecture views (formerly ‘products’) are no longer the end goal, but are 2620

described solely to facilitate useful access to information in the architecture database. All views 2621

are tailorable. The requirements for data completeness and self-consistency within the data 2622

schema are more critical than the view chosen at any particular time by a particular user. 2623

Analytics, properly conducted, represent a powerful tool for the decision-maker, ensuring that 2624

the most appropriate and current, as well as valid data is used for decision-making. 2625

2626

Figure 10.1-1 below, an adaptation of Figure 1.3-1, from Section 1, illustrates the overall 2627

architecting process. More specifically, it illustrates that analytics, the process of doing analysis 2628

with and on architecture data, is central to successful decision-making. Analysis defines and 2629

describes potential courses of action (i.e. alternatives) that can be considered when considering a 2630

mission or program decision. 2631

2632

2633 Figure 10.1-1: Analytics Process, Central to transforming architectural data into usable 2634

forms to support decision-makers 2635 2636


83 DRAFT


Architecture development is an iterative process, evolved over time. Analyses developed from 2637

architecture data remain valid only as long as the processes and information do not change, and 2638

management decision-making remains focused on the same problem for which the architecture 2639

data was collected. When any of these variables (i.e. architecture purpose, process steps, 2640

information, or management direction) change, then previous analyses should be reviewed to 2641

determine if the previous analysis needs to be redone, based on the newly provided information. 2642

Constant feedback and examination needs to be understood as natural in an environment where 2643

program direction and priorities are constantly in flux. 2644

2645

The need for an iterative analytical capability points towards tool-assisted and tool-supported 2646

analyses whenever possible. Process steps, such as re-running analyses, that are difficult or time 2647

consuming to perform will likely not be performed unless automated. The iterative approach (as 2648

depicted in Figure 10.1-2) of build a little, use a little, build a little, … enables architectures to 2649

achieve incremental, reachable goals early and throughout the entire architecture life-cycle 2650

process. 2651

2652

2653 Figure 10.1-2: Iterative Approach 2654

2655

10.2 Architecture Analytics is a process that uses architecture data to support decision-2656

making through automated extraction of data from a structured dataset. Automated extraction 2657

may be nothing more than results from a query into a database. Architectures well designed, and 2658

consistent with the purpose for which they were created, are also well suited to the analytics 2659

process. 2660

2661

10.3 Types of Architecture Analysis 2662 There are two categories of analytical activity. These are: 2663

2664

• Static Analyses: Those analyses, which are based on making a value judgment, based on 2665

data extracted from the architecture. For example, analysis of the weather patterns and 2666

measurements for the last 50 years to determine trends and correlations would be static 2667

analyses. 2668

• Dynamic Analyses: Those analyses, which are based on “running” an executable version of 2669

the architecture to observe the overall behavior of the model. For example, the construction 2670

and execution of a dynamic weather prediction model to determine the possible future 2671

weather trends is an example of dynamic analysis. 2672

2673


84 DRAFT


10.4 Examples of Analytics 2674 Analytics can be used in conjunction with many aspects of the architecting process. Examples of 2675

analytical support can be found within DOTLMPF, as shown in Table 10.4-1, below. 2676

DOTMLPF is the analysis of who (people, organization, leadership) perform what operations 2677

(doctrine) at which locations (facilities) using (training) which system resources (material) to 2678

produce and consume information and data. DOTLMPF analysis leads to better definitions of 2679

warfighting capabilities by being able to anticipate effects and assess impact of change on 2680

domains and by examining usage (who/what affects something) and references (who/what is 2681

affected by something). DOTLMPF domains map to DoDAF architecture elements with the 2682

following analytical support activities. 2683

Table 10.4-1: DOTMLPF 2684 DOTMLPF Domains

DoDAF Architecture Elements

Analytical Support Activities

Doctrine Functions, Performers, Assets, Locations, Nodes

Examine Tactics, Techniques and Procedures

Organization Performers, Org Units Examine organizational structure Training Functions, Performers,

Assets Train personnel on their activities and the systems they use

Leadership Org Units, Performers, Assets

Examine leadership issues

Materiel Functions, Material, Data, Information, Location. Assets, Performers

Examine materiel solutions – a new system?

Personnel Performers Examine personnel solutions – new personnel or personnel with better qualifications

Facilities Locations Examine fixing, building or modifying facilities

2685

It is not the intent for DoDAF to prescribe all possible analytical activities. The list above is 2686

only a partial listing of potential activities that relate to DoDAF architecture elements useful to 2687

the DOTMLPF Domains. As more demands are placed on architecture, and as industry spawns 2688

more automation, the flexibility described in DoDAF will encourage further innovation from 2689

architects and from tool vendors. 2690

2691

10.5 Principles of Architecture Analytics 2692 The five key foundational principles of architecture analytics are described below. These 2693

principles help in maintaining quality architecture and foster further innovation for spawning 2694

new analytical activities in the future. 2695

2696

10.5.1 Information Consistency. Information consistency means that data (and its derived 2697

information) within the architecture descriptions is consistent with an overarching metadata 2698

structure (called a ‘schema’). In addition to adhering to the explicit syntax rules of the schema, 2699

data also needs to be consistent with any additional rules specified for the project. Information 2700

consistency is often checked to some degree by commercial architecture tools, and additional 2701

checking capabilities can be implemented to help assure a more reliable architecture product. 2702

2703

Information consistency also refers to whether the data in one section of the architecture 2704

description agrees with the data in another section. For instance, if a specific Activity is assigned 2705


85 DRAFT


to a role in one place, yet in another portion of the architecture, that role is shown as not having 2706

responsibility for that activity, this would be a information inconsistency. This is normally 2707

because the underlying architectural data is found in two or more places. In this case, the tool 2708

itself or some configurable process must perform rule-based checks for redundancy to ensure the 2709

data in multiple places is consistent. Consistency also involves architecture integration where 2710

the underling architectural data is stated only once—one fact, one place—and the architectural 2711

views are projections of a single, inherently consistent model. 2712

2713

10.5.2 Data Completeness. Data completeness refers to the requirement that all required 2714

attributes of data elements are specified. For example, a set of system functions where only 2715

some of the functions have associated textual descriptions would not be data complete. Data 2716

completeness also refers to the property of having all necessary data to perform certain analyses, 2717

view (product/artifact) generation, and/or simulations or executable architectures. 2718

2719

Analytics demands that the architecture data be understandable. Not every analytical procedure 2720

will need to examine every part of the architecture. However, no analytical procedure can 2721

analyze an architecture that it cannot sufficiently understand, so the architecture’s structured 2722

dataset must be complete enough to support required analytics, thus making it essential that the 2723

structured dataset support and define all aspects of the architecture. The architectural model, the 2724

projections of the model, and the transformations of the model should, to the extent possible, be 2725

based upon open standards. Open standards allow analytics choices 2726

2727

10.5.3 Transformation. Many decisions require the use of data contained in datasets created 2728

by different toolsets. Utilizing the data for analysis may require a transformation of the data into 2729

an alternative structure, which in turn may be accessed by another tool. Transformation allows 2730

the intellectual capital invested in the architecture to reach beyond the set of tools used in 2731

creating it. 2732

2733

10.5.4 Iteration. Analysis must support an iterative architecture refinement and decision 2734

process (refer to Figure 10.1-2). Analysis that takes too long in any iteration will quickly 2735

become irrelevant to the overall process. Rather, small iterative steps or modules should be 2736

created that will produce reliable, trustable results. 2737

2738

10.5.5 Lack of Ambiguity. An architecturally structured dataset must make clear the 2739

meaning of each defined element. If there are semantically variable architectural constructs, they 2740

cannot be accurately analyzed by multiple analysis tools. This limits the scope and effectiveness 2741

of analytics and therefore limits the usefulness of the architecture itself. Semantic specificity is 2742

essential to gain the full benefit of analytics. 2743

2744


86 DRAFT


11. CONFIGURATION MANAGEMENT OF THE DODAF ARCHITECTURE 2745

FRAMEWORK 2746 2747

Configuration management (CM) provides an orderly way to facilitate change, based on a 2748

documented requirements baseline, and utilizing best practices in the change management 2749

process. This is intended to ensure that expectations are fully understood and realized in an 2750

efficient manner, including proper consideration of all potential impacts on customers and 2751

resources. CM is a necessary and critical process to assure an orderly and stable evolution of any 2752

architecture and also to ensure that the DoDAF remains current in the face of evolving methods 2753

and techniques of architecture creation and management. 2754

2755

This section provides a summary overview of the two primary aspects of configuration 2756

management of DoD enterprise architecture efforts: 2757

2758

• Configuration management guidance to developers of specific instance architectures 2759

prepared within DoD in accordance with the DoDAF. 2760

• Configuration Management of the DoD Framework document content itself. 2761

2762

These CM activities are complementary with existing DoD CM processes for the DoD 2763

Architecture Registry System (DARS), the DoD Information Technology Standards Registry 2764

(DISR), and the Metadata Registry (MDR). A more comprehensive description of the overall 2765

CM Process is found online in the DoDAF Journal, https://www.us.army.mil/suite/page/454707. 2766

2767

11.1 Configuration Management Authority 2768 The Configuration Management Authority for the contents of the DoDAF document is The Chief 2769

Information officer (CIO), OASD (NII). 2770 2771

11.2 Configuration Management Guidance for Program Managers 2772 2773

There are many benefits to the Department gained by adhering to a CM Program in the 2774

production of architecture data, thus providing consistency to the creation and utilization of 2775

presentation views, while still allowing flexibility in graphical presentation. These include: 2776

2777

• Utilization of the DM2 (Conceptual, Logical and Physical Exchange Specification) in 2778

architecture data collection, organization, storage, and documentation. 2779

• Utilization of DoDAF technical guidance (Contained in Volume 2, and the DoDAF 2780 Journal, https://www.us.army.mil/suite/page/454707) in the creation and graphical 2781

representation of views, based on architecture data and a desired viewpoint. This is 2782

accomplished by: 2783

- DoDAF definition of attributes for common architecture views. Thus, there is a known 2784

basis for making change to architecture views, and a means for evaluating the 2785

effectiveness of that change according to the chosen viewpoint. 2786

- DoDAF representation of a common vocabulary and grammar for documenting 2787

architectures thus facilitating common understanding among DoD components, ensuring 2788


87 DRAFT


interoperability in exchanging architecture data and federation of individual architectures 2789

within a higher tier enterprise view. 2790

• Traceability of Requirements. Architectural data can more easily be associated with 2791

baseline requirements, and, as requirements change, the associated impacts on present and 2792

future actions can more easily be evaluated, and more accurately reflect the change 2793

requirement. 2794

• Configuration Identification. Utilization of DoDAF data elements allows a consistent 2795

identification of Configuration Items (CIs), which are currently defined as: 2796

- The “Vocabulary” - The Elements (e.g. process, system function, Capability, etc.) and 2797

Views (AV, OV, SV, TV, etc.) that describe the behavioral, tabular, mapping, ontological, 2798

and structural representations of an architecture.-The metadata (e.g. Information about data in 2799

the architecture). 2800

- The “Grammar” - The formal conceptual and logical relationships between elements 2801

and products of the “Vocabulary” – The Conceptual and Logical Data Model. 2802

- The Presentation Guidelines – “Fit for Purpose” view points, dashboards, decision 2803

views, etc.—The “Architecture Results” 2804

- Methods and Process Guidelines 2805 - The DoDAF Document - The narrative volumes comprising the DoDAF. 2806

• Organized Process. Change activity is controlled through a known, documented, and 2807

organized process. 2808

• Improved Change Management. Architecture data can be better managed to produce 2809

stable and consistent requirements to guide the development of interoperable systems, 2810

processes, and procedures. 2811

• Improved Analysis and Trades. Analyses that better reflect customer need through 2812

common understanding and explicit documentation of architecture baselines and change 2813

evolution. 2814

2815

11.2.1 Configuration Management Implementation. Each architecture effort must establish 2816

a configuration management process and document it in a CM plan. This plan is submitted when 2817

each version or update to the architecture is submitted to DARS for registration and discovery. 2818

In developing CM processes for architectures it is recommended that “best practices” be adopted 2819

such as those outlined in EIA Standard EA-64939

. This a flexible, but well-defined standard 2820

employed most often at the ‘enterprise’ level. Its flexibility lies in the ability to provide CM 2821

practices that can be selectively applied to the degree necessary for each of the areas to be 2822

covered under this plan. 2823

11.2.2 Evaluating Architecture Changes. Appropriate evaluation criteria should be 2824

developed in the CM Plan and applied according to the scope and tier of the architecture effort. 2825

The evaluation criteria must include factors that test compliance with the Net-Centric Reference 2826

Architectures and the DoD IE as outlined in Section 3.0 of the DoDAF and the Net-Centric 2827

Guidance contained in Volume 2. The results of architecture evaluations should be used to guide 2828

39

ANSI/GEIA Standard EIA 649-A National Consensus Standard for Configuration Management American National Standards

Institute. This standard is available at: http://www.techstreet.com/cgi-bin/detail?product_id=1160265


88 DRAFT


decisions for approving proposed changes, as well as in planning future extensions or updates to 2829

the architecture. 2830

2831

11.2.3 The DARS Registration Process. Consistent with the federated architecture approach 2832

described in Section 3, essential architecture information must be registered with DARS so that 2833

discovery of reusable architecture data can be accomplished throughout the Department. 2834

Generally, and as further described in the instructions on registration contained online in the 2835

DARS, this consists of the Overview and Summary Information (AV-1) which can be completed 2836

online, and the Configuration Control Plan (CCP) that describes how the organization intends to 2837

manage and periodically update its information. Individual data entities and other artifacts are 2838

similarly registered in the DoD Metadata Registry. 2839

2840 11.3 Configuration Control Board (CCB). The DoD Architecture Configuration Control 2841

Board (CCB) provides an organized management review process to ensure validity, currency, 2842

and timeliness of architecture data described over time. The board provides configuration 2843

management and control carefully scoped and administered to reduce the burden and complexity 2844

of architecture sharing and maintenance, as well as update, while providing flexibility to the 2845

DoD community in the continued management of their architectural products and associated 2846

data. The CCB Consists of members appointed by the Deputy DoD CIO, and includes 2847

representatives of the Joint Staff, OSD, The Military Services, Combatant Commands, and 2848

Defense Agencies. 2849

2850

11.4 Technical Working Groups (TWGs). The CCB may, from time to time, establish 2851

technical working groups (TWG), as required, to oversee, review, and make recommendations to 2852

the board on specific technical aspects of the CM Program, or configuration items. TWGs 2853

provide the subject-matter expertise necessary to ensure that documents, database schemas, and 2854

other products under configuration control of the CCB are maintained in a responsible manner. 2855

TWGs, when tasked by the CCB, provide detailed and comprehensive technical review of 2856

proposed changes and recommendations to the CCB on action(s) to be taken that result from 2857

recommended changes. Both permanent members of the CCB and members of all technical 2858

working groups are notified about all CCB meetings and all scheduled TWG sessions, as are the 2859

Combatant Commands and Defense Agencies. 2860

2861

2862


89 DRAFT


12. RELATIONSHIPS TO OTHER ARCHITECTURE FRAMEWORKS/ 2863

REFERENCE DOCUMENTS 2864 DoDAF is designed to align, map, and socialize with industry, allies with their own national 2865

frameworks, and other reference documents required for interoperability, reuse, and operational 2866

purposes. The DoDAF approach to alignment is to incorporate relevant concepts into DoDAF 2867

from other frameworks and reference documents and understand, integrate and describe the 2868

differences. 2869

2870

12.1 Frameworks 2871 2872

2873

12.1.1 Federal Enterprise Architecture (FEA) Program 2874

2875 The FEA promotes shared development for common Federal processes, interoperability, and 2876

sharing of information among the Agencies of the Federal Government and other Governmental 2877

entities through the use of a set of reference models and practices that apply to all Federal 2878

agencies in the Executive branch. The FEA Practice Guidance uses a segment architecture 2879

approach that allows critical parts of the overall Federal Enterprise, called architectural 2880

segments, to be developed individually, while integrating these segments into the larger 2881

Enterprise Architecture. The DoDAF leverages the FEA construct and core principles to provide 2882

the Department with the enterprise management information it needs to achieve its strategic 2883

transformation goals, while ensuring that upward reporting and review can be accomplished 2884

against the FEA. 2885

2886

The current version of the FEA can be found at the E-Gov Website: 2887

http://www.whitehouse.gov/omb/egov/a-1-fea.html 2888

2889

12.1.2 The Zachman Framework 2890 2891

The Zachman Framework provides a formal and highly structured way of defining an enterprise. 2892

It is based on a two-dimensional classification model, displayed as a matrix, which utilizes 6 2893

basic communication interrogatives (What, How, Where, Who, When, and Why) and 2894

intersecting 6 distinct model types which relate to stakeholder groups (Planner, Owner, Designer, 2895

Builder, Implementer and Worker) to give a holistic view of the enterprise. Decomposition of 2896

the matrix allows for several diagrams of the same data sets to be developed for the same 2897

architecture, where each diagram shows an increasing level of detail. DoDAF v2.0 supports the 2898

needs of various stakeholders’ perspective by supporting various levels of abstraction and 2899

granularity. 2900

2901

The Zachman Framework can be found at the Zachman International Website: 2902

http://zachmaninternational.com/index.php/the-zachman-framework/26-articles/13-the-zachman-2903

framework-a-concise-definition. 2904

2905

12.1.3 The Open Group Architecture Framework (TOGAF) 2906 2907


90 DRAFT


TOGAF is a comprehensive architecture framework and methodology, which enables 2908

practitioners to design, evaluate, and build an appropriate architecture for the organization. The 2909

TOGAF Architecture Development Method (ADM) supports the TOGAF architecture 2910

development approach for architectures that meet business needs. TOGAF’s ADM prescribes 2911

methodology, not products, or modeling notation, and should be used with other architecture 2912

frameworks as appropriate. TOGAF evolved from the DoD Technical Architecture Framework 2913

for Information Management (TAFIM). DoDAF v2.0 and TOGAF both provide a practical, 2914

design agnostic method for creating enterprise architectures. The DoDAF v2.0 “Fit for 2915

Purpose” approach for developing views, presentations, or generated reports are based on 2916

TOGAF’s business, data, application, and technology views. 2917

2918

The latest version of TOGAF can be found at the Open Group Website: 2919

http://www.opengroup.org/architecture/togaf/ 2920

2921

12.1.4 The Ministry of Defense Architecture Framework (MODAF) 2922 2923

MODAF is based on the DoDAF version 1.0 baseline, which it represents through the MODAF 2924

Meta Model (M3). MODAF retains compatibility with US modeling initiatives, but is 2925

specifically designed to support architecture modeling for the UK Ministry of Defense (MOD) 2926

business. MODAF uses aspects of the existing DoDAF with additional viewpoints (acquisition, 2927

capability) that are required to support MOD processes, procedures, and organizational 2928

structures. The additional viewpoints provide a rigorous method for understanding, analyzing, 2929

and specifying capabilities, systems, System of Systems (SoS), business processes, and 2930

organizational structures. DoDAF v2.0 incorporates the data elements from MODAF required to 2931

support an acquisition and capability views in Version 2.0. 2932

2933

The latest version of the MODAF can be found at the MODAF Website: 2934

http://www.modaf.org.uk/ 2935

2936

12.1.5 NATO Architecture Framework (NAF) 2937 2938

The NAF provides the rules, guidance, and product descriptions for developing, presenting, and 2939

communicating architectures across NATO and other national boundaries. Earlier versions of 2940

NAF were tightly coupled to the DoDAF. NAF’s new features include a capability, service-2941

oriented, and program view. DoDAF v2.0 has adopted the capability and program views 2942

described in NAF as defined by NAF. 2943

2944

The NATO Architecture Framework can be found at the NATO Website (Requires User 2945

Registration) 2946

2947

12.2 Other Reference Documents 2948 2949

12.2.1 DoD Information Enterprise Architecture Reference (DoD IEA) [Add in DoD IEA Info] 2950

TBD 2951


A-1

DRAFT Content is Pre-Decisional Material

APPENDIX A ACRONYMS 2952 2953

2954

2955 This is the integrated DoDAF v2.0 acronyms and their definitions. Some have more than one 2956

definition depending on their usage; they could have a specific meanings in Architecture as well 2957

as generic English language usage. 2958

2959

2960

Term Definition

A

A&T Acquisition and Technology

AIS Automated Information System

ASD (C3I) Assistant Secretary of Defense for Command, Control, Communications, and

Computer Systems Directorate, Joint Staff

AV All Viewpoint

B

BMM Business Motivation Model

BPMN Business Process Modeling Notation

BPR Business Process Reengineering

BRM Business Reference Model

BT Business Transformation

BTA Business Transportation Agency

C

CADM Core Architecture Data Model

C3I Command, Control, Communications, and Intelligence

C4ISR Command, Control, Communications, Computers, Intelligence, Surveillance,

and Reconnaissance

CDM Conceptual Data Model

CCB Configuration Control Board

CDM Conceptual Data Model

CI Configuration Item

CIO Chief Information Officer

CJCS Chairman of the Joint Chiefs of Staff

CJCSI Chairman of the Joint Chiefs of Staff Instruction

CM Configuration Management

COI Communities of Interest

CPIC Capital Planning and Investment Control

CPM Capability Portfolio Management

CRM Consolidated Reference Model

CV Capability Viewpoint

CWID Coalition Warrior Interoperability Demonstration

D

DAES DoD Architecture Enterprise Services

DARS Department of Defense Architecture Registry System

DAS Defense Acquisition System

DDMS DoD Discovery Metadata Specification

DFD Data Flow Diagrams

DIE DoD Information Enterprise


A-2


Term Definition

DIEA DoD Information Enterprise Architecture

DISR DoD Information Technology Standards Registry

DIV Data & Information Viewpoint

DM2 DoDAF Meta-model

DoD Department of Defense

DoD EA DoD Enterprise Architecture

DoD EA BRM DoD EA Business Reference Model

DoDAF DoD Architecture Framework

DODI Department of Defense Instruction

DOTMLPF Doctrine, Organization, Training, Material, Leadership and education,

Personnel, and Facilities

DRM Data Reference Model

E

EA Enterprise Architecture

EAAF Enterprise Architecture Assessment Framework

EAMMF Enterprise Architecture Management Maturity Framework

EIA Electronic Industries Alliance

ES Enterprise Services

F

FEA Federal Enterprise Architecture

FEA RM Federal Enterprise Architecture Reference Model

FEAF Federal Enterprise Architecture Framework

FIPS Federal Information Processing Standard

G

GAES GIG Architecture Enterprise Services

GAO Government Accountability Office

GIG Global Information Grid

H

I

IDEF Integration Definition (IEEE)

IDEF0 Integration Definition for Activity Modeling

IDEF1X Integration Definition for Data Modeling

IDEF3 Integration Definition for Process Description Capture

ISO International Standards Organization

IT Information Technology

JCA Joint Capability Area

JCIDS Joint Capabilities Integration and Development System

JCS Joint Chief of Staff

JFCOM US Joint Forces Command

JP Joint Publication

L

LDM Logical Data Model

LOB Line of Business

M

M3 MODAF Meta Model

MOD Ministry of Defense (UK)

MODAF Ministry of Defense Architecture Framework

N

NAF NATO Architecture Framework


A-3


Term Definition

NC Net-Centric

Net Centric (JCA)

NCDS Net-centric Data Strategy

NCDSWG Net Centric Data Strategy Working Group

NCE Net-Centric Environment

NCES Net-Centric Enterprise Services

NCO Net-Centric Operations

NCOW Net-Centric Operations and Warfare

NCOW RM Net-Centric Operations and Warfare Reference Model

NII Networks and Information Integration

NSS National Security Systems

O

OASD Office of the Assistant Secretary of Defense

OMB Office of Management and Budget

OOAD Object-Oriented Analysis & Design Technique

OSD Office of the Secretary of Defense

OSD(NII) A&I Office of the Secretary of Defense Networks and Information Integration

Architectures and Integration

OV Operational Viewpoint

P

PDA Personal Digital Assistant

PDCA Plan, Do, Check, Act

PDM Physical Data Model

PEOs Program Executive Office

PFD Process Flow Diagram

PfM Portfolio Management

PPBE Planning, Programming, Budgeting, and Execution

PRM Performance Reference Model

PTD Process Task Dependency

PV Project Viewpoint

Q

QA Quality Assurance

QC Quality Control

R

RM Reference Model

S

SADT Structured Analysis and Design Technique

SE Systems Engineering

SECDEF Secretary of Defense

SEI Systems Engineering Institute

SeV Systems Viewpoint

SLC Shelf-Life Code

SOA Service-Oriented Architecture

SRM Service Component Reference Model

SrV Service Viewpoint

StdV Standards Viewpoint

SUMO Suggested Upper Merged Ontology

SysML Systems Modeling Language

T


A-4


Term Definition

TA

Technical Architecture ??

Tiered Accountability

TAFIM Technical Architecture for Information management

TOGAF The Open Group Architecture Framework

TRM Technical Reference Model

TSAT Transformational Communications Satellite

TTP Tactics, Techniques, and Procedures

TWG Technical Working Groups

U

UML Unified Modeling Language

URL Uniform Resource Locator

USD(AT&L) Under Secretary of Defense for Acquisition, Technology & Logistics

USJFCOM United States Joint Forces Command

V

V&V Validation & Verification

W

WBS Work Breakdown Structure

X

XSD XML Schema Definition

2961


B-1


Appendix B Conceptual Data Model Definitions 2962 2963

Table B-1: Conceptual Data Model Definitions 2964

Class Definition Activity A discrete unit of work, not specific to a single organization, weapon system, or

individual that transforms inputs into outputs or changes their state.

Accuracy The nearness of an functional goal to the true value

Agreement A consent among parties regarding the terms and conditions of activities that said

parties participate in.

Capacity The amount an object can hold, receive, or absorb.

Capability Capability: (n) 1. The ability to execute a specified course of action. (JP 1-02) 2.

The ability to achieve a desired effect under specified standards and conditions

through combinations of means and ways to perform a set of tasks. (JCIDS)

CapabilityConfiguration A combination of organizational aspects (with their competencies) and equipment

that combine to provide a capability.

Condition A statement of the values or states needed for the execution of an action.

Constraint The range of permissible states for an object.

Cost 1. Cost - financial: The price paid to acquire, produce, accomplish, or maintain

anything. 2. Cost - general: The expenditure of something, such as time or labor,

necessary for the attainment of a goal.

Data Factual information used as a basis for processing, reasoning, discussion,

calculation, or decision making by humans or machines.

Dependability (SEI): Availability / Robustness, Reliability, Safety, Trustworthiness, Security

Effect (JP 1-02) Effect: (n) the result, outcome, or consequence of an action [activity].

Event Something that happens at an instant in the world that causes a process to be

launched.

Facility Real property, having a specified use, consisting of one or more of the following:

a building, structure, or linear structure. Facilities are parts of Sites, which are

parts of Installations.

ExchangeObject

FunctionalDependency A constraint on or dependence of, an activity on one or more outside influences,

conditions, activities, triggers or events.

FunctionalStandard (ISE FS 200): Functional standards set forth rules, conditions, guidelines, and

characteristics.

GeoFeature An object that encompasses meteorological, geographic, and control features

mission significance.

Goal Goal: An end toward which long-term, ongoing effort is directed.

Guidance An authoritative statement intended to lead or steer the execution of actions.

Information An instance of knowledge or data that exists in any medium or form and can be

communicated or received.

Installation (DODI 4165.14): A base, camp, post, station, yard, center, or other activity,

including leased facilities, under the jurisdiction, custody, or control of a

Performer [the Secretary of Defense or the Secretary of a Military Department or,

in the case of an activity in a foreign country, under the operational control of the

Secretary of Defense or the Secretary of a Military Department], without regard to

the duration of operational control. An installation may include one or more sites.

Materiel Equipment, apparatus, or supplies that are of military interest, without distinction

as to its application for administrative or combat purposes.

Measure The magnitude of some attribute of an object.

Means An action or system by which a result is brought about; a method

Network An interconnected or interrelated chain, group, or system


B-2


Class Definition Objective Objective: (n) the clearly defined, decisive, and attainable end toward which every

operation is directed. An objective is a specific, time-targeted, measurable, and

attainable target that an enterprise seeks to meet in order to achieve its goals.

Organization An assemblage of people and other resources organized through an observable

power hierarchy for an on-going purpose.

Performer Any entity - human, automated, or any aggregation of human and/or automated -

that performs a function, activity, or role, or provides a capability.

PersonType(Personnel) A category of persons defined by the activity or activities they share.

PerformerState A stage in a process of change or development.

Plan (BMM Concept Catalog): Courses of Action are what the enterprise has decided

to do. A Course of Action is more than simply a resource, skill, or competency

that the enterprise can call upon. A Course of Action is a way of configuring

some aspect of the enterprise (things, processes, locations, people, and time) to

channel efforts towards Desired Results - the result of a decision by the enterprise

about the best way to use its resources, skills, and competencies. A Course of

Action defines what has to be done, not how well it has to be done. Measures of

Performance are defined in Objectives that are supported by the Courses of

Action. Definition: means that is an approach or plan for configuring some aspect

of the enterprise involving things, processes, locations, people, timing, or

motivation undertaken to achieve ends Note: Categories of course of action

include: strategy, tactic. Dictionary Basis: a mode of action; “if you persist in that

course you will surely fail”; “once a nation is embarked on a course of action it

becomes extremely difficult for any retraction to take place”

[www.dictionary.com]. Source: WordNet® 2.0 [ 'course of action']. Dictionary

Basis: a chosen manner of conducting oneself: way of acting “our wisest course is

to retreat” [MWCD 'course' (3b)]. In the Business Motivation Model, Courses of

Action are categorized as Strategies and Tactics. The model does not make a hard

distinction between the two. Enterprises define their own criteria.

Project A planned action that represents a set of activities organized and managed to

produce a specified product in a specified period of time with specified resources.

(DDDS Counter (19607/1) (A)).

Rate The ratio of the effective or useful output to the total input in any system.

RealProperty (DODI 4165.14): Land and improvements to land (i.e., facilities), equipment

affixed and built into the facility as an integral part of the facility heating

systems), but not movable equipment (e.g., plant equipment, industrial buoys). In

many instances this term is synonymous with real estate.

Rule A prescriptive set of procedures regarding the execution of activities within an

enterprise.

Service

Site (DODI 4165.14): Physical (geographic) location that is or was owned by, leased

to, or otherwise possessed by a Performer [DoD Component]. Each site is

assigned to a single installation. A site may exist in one of three forms: (1) Land

only, where there are no facilities present and where the land consists of either a

single land parcel or two or more contiguous land parcels. (2) Facility or

facilities only, where the underlying land is neither owned nor controlled by the

government. A stand-alone facility can be a site. If a facility is not a stand-alone

facility, it must be assigned to a site. (3) Land and all the facilities thereon, where

the land consists of either a single land parcel or two or more contiguous land

parcels.

SoftwareService

Skill The ability, coming from one's knowledge, practice, aptitude, etc., to do

something well.


B-3


Class Definition Standard A ratified and peer-reviewed specification of allowed values for outputs inputs or

processes.

System System: Any organized assemblage of procedures and human and/or non-human

resources united and regulated by interaction or interdependence to accomplish a

set of specific functions.

Task A action, activity or undertaking enabling missions, activities, or functions to be

performed or accomplished.

Technical Standard (ISE FS 200): Technical standards document specific technical methodologies

and practices to design and implement.

Timeliness The time from the occurrence of an event to the time required action occurs.

Trigger Recommend Delete as Milestone is a type of Event and can either be sub classed

or made an attribute of the class of event

Vision Vision (n) An end that describes the future state of the enterprise, without regard

to how it is to be achieved; a mental image of what the future will or could be like.

Couple

Individual A Thing that has spatio-temporal extent. Note - this may be some that existed in

the past, exists now, or may exist in some future possible world.

superSubType Extends couple.

Thing The union of element, type, and tuples.

Tuple

Type

wholePart Extends couple. A couple that asserts one (part) Individual is part of another

(whole) Individual.

TemporalType Sets of (and powersets based on) individuals that have temporal relations (time

dimension before/after) with themselves or others over time.

beforeAfter Extends couple.

CalendarPeriod

Country

endBoundary

GeoPoliticalArea

GeoPoliticalAreaState

overlapPart A wholePart that relates a ProperOverlap to the Individual of which it is a part.

Region

RegionOfCountry

startBoundary

temporalBoundary

temporalWholePart A wholePart that asserts the spatial extent of the (whole) individual is co-

extensive with the spatial extent of the (part) individual for a particular period of

time.

InterfaceType Sets of (and powersets based on) spatio/temporal individuals that can have a

boundary (common spatio-temporal existence) with other individuals.

Interface A common boundary or interconnection between systems, equipment, concepts, or

human beings.

2965


C-1


APPENDIX C REFERENCES/BIBLIOGRAPHY 2966

2967

Consolidated Reference used in this Volume 2968

2969 ANSI/GEIA Standard EIA 649-A National Consensus Standard for Configuration Management 2970 American National Standards Institute. This standard is available at: 2971

http://www.techstreet.com/cgi-bin/detail?product_id=1160265 2972 2973 Chairman of the Joint Chiefs of Staff (CJCS) Instruction 3170.01E, Joint Capabilities Integration and 2974 Development System (JCIDS), 11 May 2005. A copy of the current version of the instruction and 2975

its accompanying Manual can be found at: 2976

https://acc.dau.mil/CommunityBrowser.aspx?id=42776 2977

2978

Department of Defense Directive (DoDD) 5000.1, The Defense Acquisition System, 12 May 2003 2979

(certified current as of November 20, 2007). A current copy of the directive can be found at: 2980

https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2 2981 2982 Department of Defense Directive (DoDD) 8115.01, Information Technology Portfolio Management, 2983

October 10, 2005. Office of the Assistant Secretary of Defense (Networks & Information 2984

Integration)(NII)/DoD Chief Information Officer (DoD CIO). The latest copy of this directive 2985

can be found at: 2986

http://www.dtic.mil/whs/directives/corres/rtf/811501x.rtf 2987

2988 Department of Defense Instruction 4630.8, Procedures for Interoperability and Supportability of 2989 Information Technology (IT) and National Security Systems (NSS) 30 June 2004. Office of the 2990

Assistant Secretary of Defense (Networks & Information Integration) (NII)/ DoD Chief 2991

Information Officer (DoD CIO). The current version is found at: 2992

www.dtic.mil/whs/directives/corres/pdf/463008p.pdf 2993

2994

Department of Defense Instruction (DoDI) 5000.2., Operation of the Defense Acquisition System.(2003) 2995

Under-Secretary of Defense (Acquisition, technology & Logistics) (OUSD AT&L). A current 2996

copy of this document can be found at: 2997 https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2 2998

2999

Department of Defense Manual 8210-11-M, DoD Architecture Federation Manual, dated (DRAFT) 3000

XX-XX-200X Office of the Assistant Secretary of Defense (Networks and Information 3001

Integration) (NII)/ DoD Chief Information Officer (DoD CIO).. 3002 3003

Department of Defense Net-Centric Data Strategy, 9 May, 2003. Office of the Assistant Secretary of 3004 Defense (Networks & Information Integration) (NII)/DoD Chief Information Officer (DoD 3005

CIO). 3006

3007

DoD Acquisition Guidebook. Office of the Under-Secretary for Acquisition, Technology & 3008

Logistics (AT&L). A current copy of the Guidebook can be found at: 3009

https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2 3010


C-2


3011

Federal Enterprise Architecture (FEA). Executive Office of the President, Office of Management 3012

and Budget E-Gov Initiative. The current version of the FEA, and its associated reference 3013

models can be found at: http://www.whitehouse.gov/omb/egov/a-2-EAModelsNEW2.html 3014

3015

Federal Enterprise Architecture - Business Reference Model. The current version can be found at: 3016 http://www.whitehouse.gov/omb/egov/a-3-brm.html 3017

3018

Federal Enterprise Architecture Consolidated Reference Model Version 2.0. Executive office of the 3019

President, Office of Management and Budget (OMB). A current version can be found at: 3020

http://www.whitehouse.gov/omb/egov/documents/FEA_CRM_v20_Final_June_2006.pdf 3021

3022

Federal Enterprise Architecture Program: Enterprise Architecture Assessment Framework, version 2.2, 3023

October 2007. Executive Office of the President., Office of Management and Budget. The 3024

current version can be found at: http://www.whitehouse.gov/omb/egov/a-2-3025

EAAssessment.html. 3026

3027

Federal Enterprise Architecture Records Management Profile, Version 1.0, December 15, 2005. 3028 Executive Office of the President., Office of Management and Budget. A current version of the 3029

profile can be found here: http://www.cio.gov/documents/RM_Profile_v1.pdf 3030

3031

Global Information Grid (GIG) Architecture Federation Strategy, 1 August 2007. Office of the 3032

Assistant Secretary of Defense (Networks & Information Integration) (NII)/DoD Chief 3033

Information Officer (DoD CIO). 3034 3035 Information Sharing Environment Enterprise Architecture Framework (DRAFT) June, 2008. Office of 3036

the Program Manager, Information Sharing Environment. 3037

3038

Integrated Defense Acquisition, Technology, & Logistics Life Cycle Management Framework (2005). 3039

Defense Acquisition University, Ft. Belvoir, VA. A current copy of the chart is found at: 3040

http://www.dau.mil/pubs/IDA/IDA_04.aspx 3041

3042

Intelligence Reform and Terrorism Prevention Act of 2004 (IRTPA), PL 108-458 (December 17, 3043

2004) 3044

3045

Ministry of Defense Architecture Framework (MODAF). Ministry of Defense of the United 3046 Kingdom. The latest electronic version of the MODAF can be found at the MODAF Website: 3047

http://www.modaf.org.uk/ . An offline (PDF) version can be accessed here for downloading: 3048

20081001-MODAF_Handbook_V1_2_003_Adobe6-U.pdf [5.51MB] 3049 3050

NATO Architecture Framework (NAF) for C3 Systems (2006). The North Atlantic Treaty 3051

Organization. The latest version of the NAF, and other associated documents can be found at 3052 the NATO Website 3053

http://194.7.80.153/website/book.asp?menuid=15&vs=0&page=volume2%2Fch02s02.html 3054

(Requires User Registration) 3055


C-3


3056 Office of Management and Budget (OMB) Circular-A-130, Management of Federal Information 3057 Resources, February 8, 1996. Executive Office of the President., Office of Management and 3058

Budget. The current version can be found at: 3059

http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html#2 3060

3061

The Open Group Architecture Framework (TOGAF), Version 8.11 The current version can be found 3062

at: http://www.opengroup.org/architecture/togaf/ 3063

3064 United States Government Accountability Office (GAO) Report: DoD Business Systems Modernization: 3065 Long-standing Weaknesses in Enterprise Architecture Development Need to Be Addressed, July 2005, 3066

GAO-05-702. A copy of the report is available at: http://www.gao.gov/new.items/d05702.pdf 3067

3068 United States Government Accountability Office (GAO) Report: Framework for Assessing and 3069

Improving Enterprise Architecture Management, version 1.1, April 2003, GAO-03-584G. A copy of 3070 the report is available at: www.gao.gov/new.items/d03584g.pdf 3071

3072

Zachman, John. Zachman Framework. © Zachman International. The Zachman Framework 3073

can be found at the Zachman International Website: 3074

http://zachmaninternational.com/index.php/the-zachman-framework/26-articles/13-the-3075

zachman-framework-a-concise-definition 3076

3077

3078

Bibliography 3079

3080

Dinoli, D. (2008) Enterprise Architecture A to Z: Frameworks, Business Process Modeling, SOA, and 3081 Infrastructure Technology. Auerbach Publishing. 504pp. 3082

3083

Grigoriu, A. (2007) An Enterprise Architecture Framework. Privately Published 226.pp. 3084

3085

McGovern, J,, Ambler, S,, Stevens, M. E., Linn, J, Sharan, V & Jo, E. K. (2004) A Practical 3086

Guide to Enterprise Architecture. New Jersey: Prentice-Hall. 306pp. 3087

3088

Ross, J. W., Weill, P., & Robertson, D. C.(2006). Enterprise Architecture as Strategy. Boston, 3089

MA: Harvard Business School press. 235pp. 3090

3091

Ross, R. (2005). Business Rule Concepts (2nd

. Ed.) Business Rules Forum. 135pp. 3092

3093

Ross, R. (2003). Principles of the Business Rule Approach. Boston, MA: Addison-Wesley 3094

Publishing. 372pp. 3095

3096

Schekkerman, Jaap (2004). How to Survive in the Jungle of Enterprise Architecture 3097

Frameworks. Victoria, BC: Trafford 222. pp. This volume is particularly valuable for its chart 3098

showing the evolution of architecture frameworks 3099


C-4


3100

Spewak, Steven H (1992). Enterprise Architecture Planning. New York: John Wiley & Sons. 3101

368 pp. 3102

3103

3104

3105