1 Presented to Colorado Front Range INCOSE Chapter Colorado Springs 27 May 2008 An Introduction to the DoD Architecture Framework v1.5
1
Presented to Colorado Front Range INCOSE Chapter
Colorado Springs
27 May 2008
An Introduction to theDoD Architecture Framework v1.5
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
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