1

Presented to Colorado Front Range INCOSE Chapter

Colorado Springs

27 May 2008

An Introduction to theDoD Architecture Framework v1.5

2

Agenda

�DODAF Overview

�DODAF 1.5 Volume I / Volume II

�DODAF 1.5 Volume III

3

Background

The DoDAF Challenge

�As the Department transforms to support net-centric operations, the DoDAF must:

– Represent net-centric architectural constructs within the DoDAF views and products

– Use architecture in support of better decision making

Goal and Objectives

�Support integration of key Net-Centric concepts and associated Service-Oriented Architecture (SOA) principles into the DoDAF

� Improve the quality and utility of the DoDAF for Mission Area, Component, and Program architectures to support Net-centricity

�Modifications should be backward compatible

4

1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002

1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002

C4ISR Architecture Framework History

Navy establishes WSA&E 85

USN WSA&E Process

First Architecture Guidance

AWG Final Report

Government Performance & Results Act

Formulation of AWG

DSB Task Force Recommendations 93

“DoD needs an overarching “architect” for military information systems who can work across all Department and component boundaries and reach down to the operating forces (to the combat level) to identify what is needed to better integrate military information systems into combat operations.”

“ With CINC participation, develop an integrated architecture for command, control, communications, computers, and intelligence (C4I) to increase effectiveness when operating across the boundaries among CINCs’ areas of responsibility.”

“…I am directing the acceleration of the development of C4I integration and architecture efforts through the creation of a DoD-wide C4I Integrated product Team. …I have designated the ASD(C3I), in his capacity as the department’s C4I architect, to sponsor, organize, and manage this effort.” DepSecDef

Tasking Memo

“We see the Architecture Framework as a critical element of the strategic direction in the Department, and accordingly direct that all on-going and planned C4ISR or related architectures be developed in accordance with Version 2.0. Existing architectures will be described in accordance with the Framework during appropriate revision cycles”

USD (A&T), ASD (C3I), Joint Staff Director for C4 Systems Strategic Direction

WSA Architectures

C4ISR Integrated Task Force

C4ISR Framework 2.0

C4ISR Framework 1.0

Second USN Architecture Primer

1995 CORM Recommendation

C4ISR Framework 2.1

SEW Baseline System Performance Specification

M-97-16

DOD Framework 1.0 (Draft)

Navy Architecture

Tutorial

Naval Architecture Primer

5

The DoDAF is the common architecture language in DoD

The Department of Defense (DoD) Architecture Framework (DoDAF), Version 1.5, defines a common approach for DoD architecture description development, presentation, and integration.

The Framework enables architecture descriptions to be compared and related across organizational boundaries, including Joint and multinational boundaries.

6

The goal of the DoDAF is “Integrated Architecture”…

The term integrated architecture refers to an architecture description that has integrated OVs, SVs, and TVs (i.e., there are common points of reference linking the OV and SV and also linking the SV and TV). The Operational Activity to Systems Function Traceability Matrix (SV-5), for example, relates operational activities from the Operational Activity Model (OV-5) to system functions from the Systems Functionality Description (SV-4); the SV-4 system functions are related to systems in the Systems Interface Description (SV-1), thus bridging the OV and SV. An architecture is defined to be an integrated architecture when products and their constituent architecture data elements are developed such that architecture data elements defined in one view are the same (i.e., same names, definitions, and values) as architecture data elements referenced in another view.

OV, SV, TV?

As the story goes, when the original authors of C4ISR were crashing to finish the deliverable, they were so tired of saying “Operational View”, “System View”, and “Technical View” they started using the abbreviations OV, SV, TV, and those abbreviations have stuck.

7

PRODUCT AND ARCHITECTURE DATA ELEMENT RELATIONSHIPS

� There are general relationships that logically interconnect the Framework products

� The architect needs to be continuously aware of these necessary relationships

� Produces an architecture that is consistent across the three views

� Provides clear traceability

� Figure 2-4 illustrates some relationships among the architecture data elements for a subset of the products

8

Overview of DoDAF 1.5 Volumes

Volume 1: Definitions and Guidelines �Provides executive summaries for topics covered in depth in other Volumes (e.g. Net-

Centricity, Architecture Data Management, Decision Support/Overlays)� Introduces methodologies

Volume 2: Product Descriptions�Provides a detailed overview on the Net-Centric concepts selected �Provides Net-Centric guidance for each product & notional Ex. for some SV products� Includes CADM 1.5. models and CADM-conformant data element tables

Volume 3: Architecture Data Management�Establishes a data strategy for the architecture community�CADM 1.5: eliminates complexity with the addition of new supertypes, supports all

DoDAF 1.5 requirements, complexity built into the business rules

DoDAF Online Journal� Includes Deskbook content currently in DoDAF 1.0 Volume 3�Additional content includes: Activity-Based Modeling (ABM), SOA and Federation�Will be hosted on the DoD Architecture Registry System* (DARS)

*DARS Website: https://dars1.army.mil/IER/index.jsp

9

DoDAF 1.5 Three Volume-Suite

Volume 2Volume 1 Volume 3

CADM 1.5

DATA

EVENT-TRIGGER

INFORMATION

OPERATIONAL-ACTIVITY

OPERATIONAL-NODE

PERFORMANCE

PHYSICAL-NODE

STANDARD

SYSTEM

SYSTEM-FUNCTION

TECHNOLOGYFederationStrategy

State of DoDArchitecting

Net-Centricity Sources

& Prioritization

Decision Support

Processes

Survey, SME interviews, Feedback

Workshop Inputs

10

Product Overview

�Purpose:– Document decomposition of attributes into specific characteristics that were applied

to the architecture views

– Document content gathered from workshops and analysis with respect to the 5 Net-Centric Concepts

Concept 1: Populate the NCE

Concept 2: Utilize the NCE

Concept 3: Support the Unanticipated User

Concept 4: Leverage COIs to promote Jointness

Concept 5: Support Shared Infrastructure

– Identify product impacts of characteristics and data elements for DoDAF Architecture Views

11

OV-1: High-Level Operational Concept Graphic

General Description: High-level graphical/textual description of operational concept

Product Impacts:• Include in its textual and

graphic description how the architecture addresses Net-Centric Operations as applicable (i.e. identify connectivity to the GIG)

• Unanticipated user: Depict the target user and the “anticipated” unanticipated users; (Note: depiction of types of Users will be used to describe unanticipated user)

Business Protection Environment

Construction Mgmt

EngineeringAnalysis & Approval Payment/

Disbursement

Budget Planning

Personnel Admin

Auditing Transportation

Health, Safety,Environment

ProgramSch, Dir, Cont

Procurement

Oversight

Training

Adjudication

DisposalMgmt

Funds MgmtInventory Flow

Mgmt

Log Planning

MaintenancePlanning

Maintenance

TrainingDevelopment

Movement

Requirements Analysis

T&E

Facilities Mgmt

DoDDoD Business OperationsBusiness Operations

Warfighter Operations

Industry(various ops)

Industry(various ops)

Business Protection Environment

Contract Admin

Accounting

Receiving

TechnologyProjection

DoDBusiness Operations Environment

• Initiate a transaction• Manage a transaction• Manage reference data• Provide decision support• Control access to and protect transaction and

reference data• Transmit and translate transactions and reference d ata

DoDBusiness Operations Environment

• Initiate a transaction• Manage a transaction• Manage reference data• Provide decision support• Control access to and protect transaction and

reference data• Transmit and translate transactions and reference d ata

12

OV-2: Operational Node Connectivity Description

General Description: Operational nodes, connectivity, and information exchange needlines between nodes.

Product Impacts:• Consumers:

• Capture services users (i.e. consumers) as role for an operational nodes

• Capture Information Environment as a user/actor in the NCE

• Provider• Capture service provider as a “role”

for an operational node; may capture other user roles for a portal as well

• Unanticipated User: • Future concept: External nodes

(nodes that need to be accounted for to support federated architecture)

NodeA

Node B

Performs:Activity 1Activity 2

Node C

Performs:Activity 3

Performs:Activity 2Activity 3

ExternalSource M

Needline 4Information Type Z

Needline 3Information Type W

External Destination L

Needline 1Information Type X

Needline 2Information Type Y

NodeA

NodeA

Node B

Performs:Activity 1Activity 2

Node C

Performs:Activity 3

Performs:Activity 2Activity 3

ExternalSource M

Needline 4Information Type Z

Needline 3Information Type W

External Destination L

Needline 1Information Type X

Needline 2Information Type Y

13

OV-5: Operational Activity Model

General Description: Capabilities, operational activities, relationships

among activities, inputs, and outputs; overlays can show cost,

performing nodes, or other pertinent information.

Product Impacts:• Post before processing: Depict the activity or activities of

posting information. May show multiple outputs from a particularactivity.

• Services: A service (specifically web services) is a set of system functions executed by a system, accordingly a service is a set of process activities. As such, services could be captured as mechanisms if you use IDEF 0.

Level 1 Flow Diagram For Operational Activity (A0)

Flow 1

Flow 2

Flow 3

Flow 4

A1Activity 1

A2Activity 2

A3Activity 3

A1Activity 1

A2Activity 2

A3Activity 3

A1.2Activity 5

A3.1Activity 6

A3.2Activity 7

A1.1Activity 4

A3.2.1Activity 8

A3.2.2Activity 9

A0High-Level Operational Activity

ActivityHierarchy Level 1 Flow Diagram For

Operational Activity (A0)

Flow 1

Flow 2

Flow 3

Flow 4

A1Activity 1

A2Activity 2

A3Activity 3

Level 1 Flow Diagram For Operational Activity (A0)

Flow 1

Flow 2

Flow 3

Flow 4

A1Activity 1

A2Activity 2

A3Activity 3

A1Activity 1

A2Activity 2

A3Activity 3

A1.2Activity 5

A3.1Activity 6

A3.2Activity 7

A1.1Activity 4

A3.2.1Activity 8

A3.2.2Activity 9

A0High-Level Operational Activity

ActivityHierarchy

A1Activity 1

A2Activity 2

A3Activity 3

A1.2Activity 5

A3.1Activity 6

A3.2Activity 7

A1.1Activity 4

A3.2.1Activity 8

A3.2.2Activity 9

A0High-Level Operational Activity

ActivityHierarchy

14

SV-1: Systems Interface Description

General Description: Identification of systems nodes, systems, and system items and their interconnections, within and between nodes

Product Impacts:• Service: Capture showing a system using and

consuming a web service• Service Interface: Show how the services are

going to employ services, how are they going to interact with them

• Service Consumer and Anticipated Consumer: Primary consumers may be system nodes

• Service Registry: Capture the physical service registry

• Physical Components: The physical attributes about a service (hardware, location) may be visualized as a system node

• Service Provider: Visually represent a service provider as a system node

• Enterprise Service Bus: Visually represent the service bus with 3 dimensions: the ESB, repository and registry may be described

• Portals, web based applications: Capture nodes as edge users and portal/web based application would be depicted as a system

• Federated Catalogs: Decompose into different layers in order to see certain levels of service

• Ports/Protocols: Capture port/protocol for service, which is the mechanism to gain access to that information or capability (access point)

NODE A

NODE B

NODE C

EXTERNAL

CONNECTION

SYSTEM 1

SYSTEM 1

Key Interface 3-a

Interface 1-a

Interface 2

Interface 1-b

Interface 3-b

Sys Func L

Sys Func M

Sys Func L

Sys Func M

SYSTEM 5

SYSTEM 4

Sys Func H

Sys Func I Sys Func J

SYSTEM3 Sys Func N

SYSTEM1

Sys Func L

Sys Func M

NODE A

NODE B

NODE C

EXTERNAL

CONNECTION

SYSTEM 1

SYSTEM 1

Key Interface 3-a

Interface 1-a

Interface 2

Interface 1-b

Interface 3-b

Sys Func L

Sys Func M

Sys Func L

Sys Func M

SYSTEM 5

SYSTEM 4

Sys Func H

Sys Func I Sys Func J

SYSTEM3 Sys Func N

SYSTEM1

Sys Func L

Sys Func M

15

SV-4: Systems Functionality Description

General Description: Functions performed by systems and the system

data flows among system functions

Product Impacts:• Service Location: Properties of SDF may

capture where the service is registered• Web Service: Define a web service• Service Listing/Catalog: Capture the detail

of services related to discovery of that service

• Service Function: Capture services and decompose into system functions

• Interface Publishing Spec: Different from the service provider and may be defined

• Service Description: Capture attributes of SDF/SST including applicable extensions

• Interface Specification: Capture the defined interface specifications (i.e. WSDL)

FUNCTION 1

SUBFUNCTION11

SUBFUNCTION13

SUBFUNCTION12

SUBFUNCTION121

SUBFUNCTION122

FUNCTION 1

SUBFUNCTION11

SUBFUNCTION13

SUBFUNCTION12

SUBFUNCTION121

SUBFUNCTION122

System Function 1

DATAREPOSITORY

DATAFLOW 1

DATAFLOW 2

DATAFLOW 3

DATAFLOW 4

DATAFLOW 5

DATAFLOW 6

DATAFLOW 7

DATAFLOW 8

DATAFLOW 9

DATAFLOW 10

EXTERNALSOURCE 1

EXTERNALSOURCE 2

EXTERNALSINK 1

EXTERNALSINK 2

System Function 3

System Function 4

System Function 2

System Function 1

DATAREPOSITORY

DATAFLOW 1

DATAFLOW 2

DATAFLOW 3

DATAFLOW 4

DATAFLOW 5

DATAFLOW 6

DATAFLOW 7

DATAFLOW 8

DATAFLOW 9

DATAFLOW 10

EXTERNALSOURCE 1

EXTERNALSOURCE 2

EXTERNALSINK 1

EXTERNALSINK 2

System Function 3

System Function 4

System Function 2

16

SV-5: Operational Activity to Systems Function Trac eability Matrix

General Description: Mapping of systems back to capabilities or of system functions back to operational activities.

Product Impacts:• Capabilities Supported: The SV-5 may depict

the traceability to operational activities• Policies: A derivation of the SV-5 may

capture the service levels required from the services as captured in the OV-6a and the service levels provided from the SV-10a (Post version 2.0 proposal, i.e. SV-5a.)

• Proposed recommendation- note update to product

• SV- 5A - Activity to System functions• SV- 5B - Activity to System • SV- 5C - Activity to Service

11.11.1.11.1.1.11.1.1.21.1.1.31.1.21.1.2.11.1.2.21.1.2.31.1.31.1.3.11.1.3.21.1.3.3

1.1.3.4

3.11

3.11

.3

3.12

3.12

.1

3.12

.2

3.12

.3

3.13

3.14

3.14

.1

3.14

.2

3.14

.3

3.14

.4

3.15

3.16

3.17

3.17

.1

System Functions

..

Operational Activities

X

XX

X

X

X

XX

X

X

X

X

XX

X

11.11.1.11.1.1.11.1.1.21.1.1.31.1.21.1.2.11.1.2.21.1.2.31.1.31.1.3.11.1.3.21.1.3.3

1.1.3.4

11.11.1.11.1.1.11.1.1.21.1.1.31.1.21.1.2.11.1.2.21.1.2.31.1.31.1.3.11.1.3.21.1.3.3

1.1.3.4

3.11

3.11

.3

3.12

3.12

.1

3.12

.2

3.12

.3

3.13

3.14

3.14

.1

3.14

.2

3.14

.3

3.14

.4

3.15

3.16

3.17

3.17

.1

3.11

3.11

.3

3.12

3.12

.1

3.12

.2

3.12

.3

3.13

3.14

3.14

.1

3.14

.2

3.14

.3

3.14

.4

3.15

3.16

3.17

3.17

.1

System Functions

..

Operational Activities

X

XX

X

X

X

XX

X

X

X

X

XX

X

X

XX

X

X

X

XX

X

X

X

X

XX

X

17

SV-10c: Systems Event-Trace Description

General Description: One of three products used to describe system

functionality- identifies system-specific refinements of critical sequences of

events described in the Operational View

Product Impacts:• Orchestration: Depict the orchestration

between services (the various events between services)

• Service Registry: Capture service registry as services are registered

• Service Dependencies: Capture service dependencies

• Post before Processing: Show how the service passes information to another service before a user gets the information for processing

MESSAGES/TIME

Systems/Functions

System/Function 1

System/Function 2

System/Function 3

Event 1time 1

time 2

time 3

time 3'

{formula relatingtime 3 to time 3'}

time n

{formula relatingtime 1 to time 2}

Event 2

Event 3

Event 5 Event 4

Event 6

Event 7Event 8

MESSAGES/TIME

Systems/Functions

System/Function 1

System/Function 2

System/Function 3

Event 1time 1

time 2

time 3

time 3'

{formula relatingtime 3 to time 3'}

time n

{formula relatingtime 1 to time 2}

Event 2

Event 3

Event 5 Event 4

Event 6

Event 7Event 8

18

TV-1: Technical Standards Profile

General Description: Listing of standards that apply to Systems View elements in a given architecture.

Product Impacts:• Specifications: Capture

deviations, extensions, departures from specifications, particularly those around COI

DISR Service Area Service DISR Standard and Source Document

Information-Processing Standards Higher Order Languages Software Life-Cycle Process Geospatial Data Interchange Motion Imagery Data Interchange - Video Distributed-Object Computing Information-Transfer Standards Data Flow Network Command and Control Information (C2I) Network Physical Layer Network Interface Layer Management File Transfer Standards Remote Terminal Standards Network Time Synchronization Standards Web Services Standards Connectionless Data Transfer Transport Services Standards Information Modeling, Metadata, and Information Exchange Standards

Activity Modeling

Data Modeling Object-Oriented Modeling Human Computer Interface Mandates Information Security / Information Infrastructure Standards

Password Security

Application Software Entity Security Standards Virtual Private Network Service Intrusion Detection Service Human-Computer Interface Security Standards

19

Objectives of Volume III

� Implement the Net-Centric Data Strategy within the Architecture Community of Practice

– Prescribe discovery metadata to facilitate the registration and discovery of architecture content across the Department of Defense

– Describe how architecture registries and repositories will be federated utilizing web services

� Incorporate the Core Architecture Data Model as an integral component of the DoDAF

20

CADM Evolution

DODAF1.0

DODAF1.5

CADM 1.0X SERIES

CADM1.04

CADM1.5

DODAF2.0

CADM2.0

21

CADM 1.5 Characteristics

�Extends CADM 1.04

– Incorporates Net-Centric Requirements

– Remains backwards-compatible with CADM 1.0X – Mapping Business Rules; Processes

�Details

– Substantial Streamlining: 135 Entities

– Meta-modeling of Relationships & Legacy Architecture Concepts

– Flexible but Stable Framework for Future DoDAF Versions

22

Architecture& Requirements TeamColorado Springs Points of Contact

�Team Leads

– Michael Johnston

– Andy Hall

�Team Contacts

– Bruce Winchester, Kirk Moen, Donny Holaschutz – TSAT Architecture

– Judy Moldenhauer- AFSCN Requirements, MM III, SMD Crypto Architecture

– Dan Hutton – AFSCN NMS

– Melissa McCullough, Ann Cobb – AFSCN Architecture

– Jim Doughty – ITW/AA Architecture

– Andy Hall – NASA Constellation Architecture

– Linda Davis – SE&I OSP, Space Radar

– Matt Wingert, Vern Miller – GPS SATAF, GPS Ops Support

23

Questions?