Department of Defense Architecture Framework · v2.02

The Complete DoDAF Tutorial — Every Step, Every Model, One Worked Example

Learn enterprise architecture the DoD way: the full 6-Step Architecture Development Process and all 52 models across all 8 viewpoints — each illustrated with an architecture diagram built on a single, end-to-end maritime Search & Rescue (SAR) mission.

6process steps

8viewpoints

52models

40+diagrams

0 Introduction — What DoDAF Is

DoDAF (the Department of Defense Architecture Framework) is the U.S. DoD's official guidance for describing, developing, and integrating enterprise architectures. Version 2.02 is the current edition and is data-centric: the value is in the underlying architectural data, while diagrams and tables are simply presentations of that data.

Why architecture frameworks exist

Large organizations make decisions — buy this system, retire that one, build a new capability — that ripple across people, processes, data, and technology. Without a shared, structured description of "how things connect," those decisions are made blind. DoDAF gives everyone a common vocabulary and a common set of views so that operators, engineers, and decision-makers are looking at the same reality.

The three big ideas of DoDAF 2.02

Data-centric, not product-centric. Earlier versions told you to produce a fixed list of "products." 2.02 says: capture good data conforming to the meta-model, then render whatever views your audience needs.
Fit-for-Purpose. You never build all 52 models. You build only the ones that answer your decision-maker's questions. This tutorial teaches all 52 so you can choose; real projects use a subset.
Six-Step Process. A repeatable method for how to develop an architecture, regardless of which models you end up producing.

✓ How to read this tutorial

First learn the 6-Step Process (the method). Then walk the 8 viewpoints / 52 models (the outputs). Every model section shows the same SAR mission so you watch one architecture grow from a one-page concept into a fully traceable description.

0.1 Core Concepts & the DoDAF Meta-Model (DM2)

Because DoDAF is data-centric, everything ultimately ties back to the DoDAF Meta-Model (DM2) — the formal schema that defines the things an architecture can contain and how they relate. Understanding DM2 is what lets your separate diagrams be integrated rather than disconnected pictures.

DM2 — the layered meta-model

DM2 layer	Audience	What it defines
Conceptual Data Model (CDM)	Executives, non-technical	The high-level concepts and their relationships in plain language (e.g., Performer performs Activity).
Logical Data Model (LDM)	Architects	Adds attributes, types, and precise relationships to the CDM — technology-independent.
Physical Exchange Specification (PES)	Tool developers	Implementable format (XSD) for exchanging architecture data between tools.

The vocabulary you must know

flowchart LR
  P["Performer
(who/what acts)"] -->|performs| A["Activity
(work done)"]
  A -->|consumes / produces| R["Resource
(data, materiel, energy)"]
  P -->|exchanges| RF["Resource Flow"]
  C["Capability
(ability to achieve an effect)"] -->|realized by| A
  A -->|guided by| Rule["Rule / Guidance"]
  P -. has .-> Loc["Location"]
  A -. occurs in .-> Cond["Condition"]
  classDef k fill:#13294b,stroke:#0b1f3a,color:#fff;
  classDef r fill:#2f81f7,stroke:#1d4ed8,color:#fff;
  class P,A,C k; class R,RF,Rule,Loc,Cond r;

Figure 0.1 — Core DM2 concepts. Nearly every DoDAF model is a particular "view" over these few building blocks.

Concept	Plain meaning	SAR example
Capability	An ability to achieve a desired effect under set conditions.	"Maritime Search & Rescue"
Activity	Work / a transformation of inputs to outputs.	"Plan Search Pattern"
Performer	Anything that performs activities (org, system, person, service).	"Rescue Coordination Center (RCC)"
Resource Flow	The exchange of data/materiel/energy between performers.	"Distress Alert" message
System	A functional, physical, or behavioral resource that performs activities.	"SARSAT Beacon Receiver"
Service	A reusable, contracted mechanism to access a capability.	"Position Reporting Service"

0.2 The Running Example — Maritime Search & Rescue

Every diagram in this tutorial describes the same mission so you can see one architecture evolve. We will architect a national Maritime Search & Rescue (SAR) capability operated by a Coast-Guard-style organization.

⚓ Scenario

A vessel in distress activates an emergency beacon. A satellite relays the distress signal. A national Rescue Coordination Center (RCC) detects it, locates the vessel, plans a search, tasks an aircraft and a cutter, coordinates the rescue, and recovers the survivors. We want to modernize the supporting systems and prove the new architecture delivers the SAR capability faster.

The actors at a glance

Actor	Role	DoDAF type
Vessel in Distress	Originates the distress alert via beacon (EPIRB).	Performer (external)
SARSAT Satellite	Relays beacon signal to ground.	Performer / System
Rescue Coordination Center (RCC)	Detects, plans, coordinates, directs the mission.	Performer (organization)
SAR Aircraft	Conducts aerial search; drops survival kit.	Performer / System
Rescue Cutter	Recovers survivors; provides medical aid.	Performer / System
Medical Facility	Receives and treats survivors.	Performer (external)

0.3 The 8 Viewpoints & 52 Models

A viewpoint is a perspective on the architecture for a particular audience; a model (also called a "view" or, historically, a "product") is a specific output within a viewpoint.

mindmap
  root((DoDAF 2.02))
    AV (All Viewpoint)
      AV-1 Overview
      AV-2 Dictionary
    CV (Capability)
      CV-1..CV-7
    OV (Operational)
      OV-1..OV-6
    SV (Systems)
      SV-1..SV-10
    SvcV (Services)
      SvcV-1..SvcV-10
    StdV (Standards)
      StdV-1..StdV-2
    DIV (Data & Info)
      DIV-1..DIV-3
    PV (Project)
      PV-1..PV-3

Figure 0.2 — The 8 viewpoints and how the 52 models distribute among them.

Viewpoint	Answers the question…	Models
All (AV)	What is this architecture about, and what do the terms mean?	2
Capability (CV)	What must we be able to do, and when?	7
Operational (OV)	Who does what, with whom, and how (mission view)?	9
Systems (SV)	Which systems support the operations, and how do they interact?	13
Services (SvcV)	Which services support the operations (SOA view)?	13
Standards (StdV)	What rules/standards constrain the design?	2
Data & Info (DIV)	What information is exchanged and how is it structured?	3
Project (PV)	How do projects deliver the capabilities over time?	3

1 The 6-Step Architecture Development Process

This is the method: how to actually build a DoDAF architecture, in order, without skipping anything. It applies no matter which models you produce.

flowchart TD
  S1["1 · Determine the
intended USE"] --> S2["2 · Determine the
SCOPE"]
  S2 --> S3["3 · Determine the
DATA required"]
  S3 --> S4["4 · COLLECT, organize,
correlate & store data"]
  S4 --> S5["5 · Conduct
ANALYSES"]
  S5 --> S6["6 · DOCUMENT &
present results"]
  S6 -. feedback / iterate .-> S1
  classDef s fill:#13294b,stroke:#0b1f3a,color:#fff,font-weight:bold;
  class S1,S2,S3,S4,S5,S6 s;

Figure 1.0 — The DoDAF Six-Step Architecture Development Process. Iterative, not strictly linear.

Step 1 · Determine the intended use of the architecture

Start with why. An architecture with no decision to support is wasted effort. Capture: who the decision-maker is, what decision they face, what questions they need answered, and how success will be judged.

⚓ SAR · Step 1

Decision-maker: SAR Program Director.
Decision: Approve a modernization that replaces the legacy radio-based coordination system.
Key questions: (1) Will the new architecture reduce "time-to-first-asset-on-scene"? (2) Does every operational activity still have a supporting system? (3) Are there single points of failure?

flowchart LR
  D["SAR Program Director
(decision-maker)"] --> Q1["Q1: Faster response?"]
  D --> Q2["Q2: Full system coverage?"]
  D --> Q3["Q3: Single points of failure?"]
  Q1 --> M["Architecture must support
measures & traceability"]
  Q2 --> M
  Q3 --> M
  classDef a fill:#2f81f7,color:#fff,stroke:#1d4ed8; classDef b fill:#13294b,color:#fff;
  class D,M b; class Q1,Q2,Q3 a;

Figure 1.1 — Step 1 ties the decision-maker's questions to what the architecture must demonstrate.

Output of Step 1: a clear purpose statement → this becomes the heart of model AV-1.

Step 2 · Determine the scope of the architecture

Scope sets the boundaries so the effort stays affordable: organizational scope, operational scope, time frame, level of detail, and what is explicitly out of scope.

⚓ SAR · Step 2

In scope: Detection → Coordination → Search → Rescue → Handover, within national maritime waters.
Out of scope: Land SAR, international coordination, long-term medical care.
Time frame: Current ("As-Is") and target year 2028 ("To-Be").

flowchart LR
  subgraph IN["IN SCOPE — Maritime SAR"]
    direction TB
    a1[Detection] --> a2[Coordination] --> a3[Search] --> a4[Rescue] --> a5[Handover]
  end
  OUT1["Land SAR"]:::out
  OUT2["International ops"]:::out
  OUT3["Long-term medical care"]:::out
  IN -.excluded.- OUT1
  IN -.excluded.- OUT2
  IN -.excluded.- OUT3
  classDef out fill:#fde2e2,stroke:#c0392b,color:#7b1c1c,stroke-dasharray:4 3;

Figure 1.2 — Step 2 draws the boundary: the mission thread that is in scope vs. explicitly excluded areas.

Step 3 · Determine the data required to support development

Now map each decision-maker question to the DM2 data — and therefore to the models that present that data. This is the Fit-for-Purpose selection step.

Question (from Step 1)	Data needed (DM2)	Models that present it
Faster response?	Activities, durations, resource flows, measures	OV-5b, OV-6c, SV-7
Full system coverage?	Activity ↔ System traceability	SV-5a / SV-5b
Single points of failure?	System interfaces & dependencies	SV-1, SV-2, CV-4

flowchart TD
  Q1[Q1 Response time] --> OV5b[OV-5b]
  Q1 --> OV6c[OV-6c]
  Q1 --> SV7[SV-7]
  Q2[Q2 Coverage] --> SV5[SV-5a / SV-5b]
  Q3[Q3 SPOF] --> SV1[SV-1]
  Q3 --> CV4[CV-4]
  classDef q fill:#13294b,color:#fff; classDef m fill:#2f81f7,color:#fff,stroke:#1d4ed8;
  class Q1,Q2,Q3 q; class OV5b,OV6c,SV7,SV5,SV1,CV4 m;

Figure 1.3 — Step 3 selects the Fit-for-Purpose model set by tracing each question to the data and models that answer it.

⚠ Key principle

You do not build all 52 models. Step 3 is where you justify each model you will build by tying it to a question. The rest of this tutorial teaches every model so you can make that choice with full knowledge.

Step 4 · Collect, organize, correlate & store the data

Gather the actual data (interviews, doctrine, existing system docs), normalize it against the DM2, resolve conflicts, and store it in an architecture repository/tool so all models share one source of truth.

flowchart LR
  SRC1[SAR Doctrine] --> COL[Collect]
  SRC2[Operator interviews] --> COL
  SRC3[Legacy system docs] --> COL
  COL --> ORG[Organize
to DM2 terms]
  ORG --> COR[Correlate
resolve conflicts]
  COR --> REPO[(Architecture
Repository)]
  REPO --> V1[OV models]
  REPO --> V2[SV models]
  REPO --> V3[CV models]
  classDef s fill:#eef3f9,stroke:#bcd; classDef p fill:#2f81f7,color:#fff; classDef d fill:#16a34a,color:#fff;
  class SRC1,SRC2,SRC3 s; class COL,ORG,COR p; class REPO d;

Figure 1.4 — Step 4 funnels many sources into one DM2-conformant repository that feeds every view.

✓ Why one repository matters

When "RCC" exists once in the repository, it appears consistently in OV-2, SV-1, and CV-5. Edit it once, every view updates. That single-source-of-truth is what makes the architecture integrated.

Step 5 · Conduct analyses in support of objectives

Use the stored data to actually answer the questions: gap analysis, traceability checks, performance/measures analysis, and risk/SPOF analysis.

flowchart TD
  REPO[(Repository)] --> GAP[Gap analysis
As-Is vs To-Be]
  REPO --> TRC[Traceability
activity→system]
  REPO --> PERF[Performance
timeline / measures]
  REPO --> RISK[Risk / SPOF]
  GAP --> FIND[Findings &
recommendations]
  TRC --> FIND
  PERF --> FIND
  RISK --> FIND
  classDef d fill:#16a34a,color:#fff; classDef a fill:#2f81f7,color:#fff; classDef f fill:#13294b,color:#fff;
  class REPO d; class GAP,TRC,PERF,RISK a; class FIND f;

Figure 1.5 — Step 5 turns stored architecture data into decision-relevant findings.

⚓ SAR · Step 5 finding

Traceability (SV-5b) reveals the activity "Plan Search Pattern" is supported only by a single legacy planning system with no backup — a confirmed single point of failure answering Q3.

Step 6 · Present results per decision-maker needs

Package the findings into the formats the decision-maker can act on — the actual diagrams, matrices, and dashboards. Tailor fidelity to the audience.

flowchart LR
  FIND[Findings] --> EXEC["Executive:
OV-1 + AV-1 + dashboard"]
  FIND --> ARCH["Architects:
OV-5b, SV-1, SV-5b"]
  FIND --> ENG["Engineers:
SV-2, DIV-3, StdV-1"]
  classDef f fill:#13294b,color:#fff; classDef o fill:#2f81f7,color:#fff;
  class FIND f; class EXEC,ARCH,ENG o;

Figure 1.6 — Step 6 renders the same underlying data differently for each audience.

⚠ Iterate

Steps loop. Presenting results usually raises new questions, sending you back to Step 1 with a sharper purpose. Architecture is a living product.

All Viewpoint (AV)

Sets the context for the entire architecture and defines its vocabulary. Always built first.

2 models · AV-1, AV-2

AV-1

Overview & Summary Information

A structured text document describing the architecture's scope, purpose, users, environment, and findings. It is the cover sheet — directly built from Steps 1 & 2.

Purpose: Justify a SAR modernization that cuts response time and removes single points of failure.
Scope: Maritime SAR mission thread: Detect → Coordinate → Search → Rescue → Handover.
Users: SAR Program Director, system architects, acquisition engineers.
Timeframe: As-Is (current) and To-Be (2028).
Findings: (populated after Step 5 analysis — e.g., SPOF in search planning).

flowchart TD
  AV1["AV-1 Overview"] --> P[Purpose & Viewpoint]
  AV1 --> SC[Scope & boundaries]
  AV1 --> CTX[Context & environment]
  AV1 --> TOOLS[Tools & standards used]
  AV1 --> FIND[Findings & recommendations]
  classDef h fill:#334155,color:#fff; classDef n fill:#64748b,color:#fff;
  class AV1 h; class P,SC,CTX,TOOLS,FIND n;

Figure AV-1 — The standard content blocks of an AV-1 overview.

AV-2

Integrated Dictionary

The single glossary of every term, node, activity, system, and data element used anywhere in the architecture — with definitions and metadata. It guarantees that "RCC" means the same thing in every model.

Term	Type	Definition
RCC	Performer (Org)	Rescue Coordination Center — directs SAR missions.
EPIRB	Resource/System	Emergency Position-Indicating Radio Beacon.
Distress Alert	Resource Flow	Message carrying beacon ID, position, time.
Plan Search Pattern	Activity	Compute optimal search area from last-known position & drift.

flowchart LR
  DICT[(AV-2 Integrated
Dictionary)]
  OV[OV models] -->|defines terms in| DICT
  SV[SV models] -->|defines terms in| DICT
  CV[CV models] -->|defines terms in| DICT
  DICT -->|one definition per term| ALL[Consistent vocabulary
across ALL views]
  classDef d fill:#334155,color:#fff; classDef m fill:#64748b,color:#fff;
  class DICT d; class OV,SV,CV,ALL m;

Figure AV-2 — Every model contributes terms to one dictionary, enforcing consistency.

Capability Viewpoint (CV)

Captures capability requirements, how they are delivered, and how they evolve over time. The "strategic" viewpoint.

7 models · CV-1 … CV-7

CV-1

Vision

The strategic context and high-level goals — the "why now" that ties capabilities to enterprise vision and outcomes.

flowchart TD
  VIS["Vision: Save more lives at sea,
faster, with fewer assets"]
  VIS --> G1["Goal 1: Cut time-to-on-scene by 30%"]
  VIS --> G2["Goal 2: 24/7 all-weather detection"]
  VIS --> G3["Goal 3: No single point of failure"]
  G1 --> C["Drives capability:
Maritime SAR"]
  G2 --> C
  G3 --> C
  classDef v fill:#7c3aed,color:#fff; classDef g fill:#a78bfa,color:#1a1033; classDef c fill:#13294b,color:#fff;
  class VIS v; class G1,G2,G3 g; class C c;

Figure CV-1 — Vision and goals cascade into the capability the architecture must deliver.

CV-2

Capability Taxonomy

A hierarchy of capabilities — decomposing the top capability into sub-capabilities. Defines what must be achievable, not how.

flowchart TD
  C0["Maritime Search & Rescue"]
  C0 --> C1["Detect & Locate"]
  C0 --> C2["Coordinate & Plan"]
  C0 --> C3["Search"]
  C0 --> C4["Rescue & Recover"]
  C1 --> C1a["Distress Detection"]
  C1 --> C1b["Position Fixing"]
  C3 --> C3a["Aerial Search"]
  C3 --> C3b["Surface Search"]
  classDef t fill:#7c3aed,color:#fff; classDef s fill:#c4b5fd,color:#2a1466;
  class C0 t; class C1,C2,C3,C4,C1a,C1b,C3a,C3b s;

Figure CV-2 — Capability taxonomy: the SAR capability decomposed into sub-capabilities.

CV-3

Capability Phasing

Shows when capabilities are fielded across time/increments — the planned delivery schedule of capability, independent of any single project.

gantt
  title CV-3 Capability Phasing (SAR)
  dateFormat YYYY
  axisFormat %Y
  section Detect & Locate
  Legacy beacon receiver      :done, 2024, 2026
  Upgraded SARSAT receiver    :active, 2026, 2028
  section Coordinate & Plan
  Manual planning (legacy)    :done, 2024, 2027
  Automated search planner    :2027, 2029
  section Search
  Aerial search (manned)      :done, 2024, 2028
  UAV-augmented search        :2028, 2030

Figure CV-3 — Capability phasing timeline: when each capability increment becomes available.

CV-4

Capability Dependencies

Maps how capabilities depend on one another — critical for finding cascading risk and single points of failure (Q3).

flowchart LR
  C1["Detect & Locate"] --> C2["Coordinate & Plan"]
  C2 --> C3["Search"]
  C3 --> C4["Rescue & Recover"]
  C1 -. requires .-> COMM["Communications"]
  C2 -. requires .-> COMM
  C3 -. requires .-> COMM
  COMM:::risk
  classDef risk fill:#fde2e2,stroke:#c0392b,color:#7b1c1c;
  classDef c fill:#7c3aed,color:#fff; class C1,C2,C3,C4 c;

Figure CV-4 — Dependencies reveal that Communications underpins three capabilities — a potential SPOF.

CV-5

Capability → Organizational Development Mapping

Which organizations are responsible for delivering/operating each capability — and where gaps in ownership exist.

Capability ↓ / Org →	RCC	Air Wing	Cutter Fleet
Detect & Locate	●	○	○
Coordinate & Plan	●	○	○
Search	○	●	●
Rescue & Recover	○	○	●

● = primary responsibility, ○ = supporting

CV-6

Capability → Operational Activities Mapping

Connects capabilities to the operational activities (OV-5) that realize them — the bridge from strategy (CV) to operations (OV).

flowchart LR
  CAP1["Cap: Detect & Locate"] --> A1["Act: Receive Distress Alert"]
  CAP1 --> A2["Act: Fix Position"]
  CAP2["Cap: Coordinate & Plan"] --> A3["Act: Plan Search Pattern"]
  CAP3["Cap: Search"] --> A4["Act: Execute Search"]
  classDef c fill:#7c3aed,color:#fff; classDef a fill:#0284c7,color:#fff;
  class CAP1,CAP2,CAP3 c; class A1,A2,A3,A4 a;

Figure CV-6 — Each capability is realized by specific operational activities.

CV-7

Capability → Services Mapping

Connects capabilities to the services (SvcV) that deliver them — the SOA equivalent of CV-6.

Capability	Delivering Service
Detect & Locate	Distress Detection Service, Position Reporting Service
Coordinate & Plan	Search Planning Service, Asset Tasking Service
Search	Track Management Service

Operational Viewpoint (OV)

Describes the mission/operations: who does what, with whom, and in what sequence — independent of technology.

9 models · OV-1, OV-2, OV-3, OV-4, OV-5a/5b, OV-6a/6b/6c

OV-1

High-Level Operational Concept Graphic

The "one picture" of the mission — the most-shown diagram in any architecture. It tells the story to executives in a single glance.

flowchart LR
  V(("🚢 Vessel
in Distress")) -->|distress beacon| SAT(("🛰️ SARSAT
Satellite"))
  SAT -->|relay alert| RCC["🏢 Rescue
Coordination Center"]
  RCC -->|task & direct| AIR(("✈️ SAR Aircraft"))
  RCC -->|task & direct| CUT(("🛟 Rescue Cutter"))
  AIR -->|locate / drop kit| V
  CUT -->|recover survivors| V
  CUT -->|transfer| MED["🏥 Medical Facility"]
  classDef n fill:#0284c7,color:#fff,stroke:#0369a1; classDef e fill:#13294b,color:#fff;
  class SAT,AIR,CUT n; class RCC,MED,V e;

Figure OV-1 — High-level operational concept for the maritime SAR mission.

OV-2

Operational Resource Flow Description

Shows the operational nodes (performers) and the resource flows (needlines) exchanged between them — the "what is exchanged with whom" view.

flowchart LR
  N1["Node: Distress Source"] -->|"Distress Alert
(position, ID, time)"| N2["Node: RCC"]
  N2 -->|"Search Tasking"| N3["Node: Air Asset"]
  N2 -->|"Rescue Tasking"| N4["Node: Surface Asset"]
  N3 -->|"Sighting Report"| N2
  N4 -->|"Recovery Status"| N2
  N4 -->|"Patient Handover"| N5["Node: Medical"]
  classDef n fill:#0284c7,color:#fff;
  class N1,N2,N3,N4,N5 n;

Figure OV-2 — Operational nodes and the resource flows (needlines) between them.

OV-3

Operational Resource Flow Matrix

The tabular detail behind OV-2: every exchange with its content, producer, consumer, and attributes (timeliness, classification).

ID	Resource Flow	Producer	Consumer	Trigger	Timeliness
RF-01	Distress Alert	Distress Source	RCC	Beacon activated	< 5 min
RF-02	Search Tasking	RCC	Air Asset	Plan approved	< 10 min
RF-03	Sighting Report	Air Asset	RCC	Target sighted	Real-time
RF-04	Patient Handover	Surface Asset	Medical	Survivor recovered	ASAP

OV-4

Organizational Relationships Chart

The command/reporting and collaboration relationships among the organizations performing the mission.

flowchart TD
  HQ["SAR Command HQ"] --> RCC["Rescue Coordination Center"]
  RCC -->|tasks| AW["Air Wing"]
  RCC -->|tasks| CF["Cutter Fleet"]
  RCC -. coordinates .- MED["Medical Authority"]
  AW --- CF
  classDef o fill:#0284c7,color:#fff; class HQ,RCC,AW,CF,MED o;

Figure OV-4 — Command (solid) and coordination (dashed) relationships.

OV-5a / OV-5b

Operational Activities

OV-5a is the activity decomposition tree (what activities exist); OV-5b is the activity model/flow with inputs, controls, outputs and mechanisms (ICOM) — how activities connect.

flowchart TD
  A0["A0: Conduct SAR Mission"]
  A0 --> A1["A1: Detect & Locate"]
  A0 --> A2["A2: Plan Response"]
  A0 --> A3["A3: Execute Search"]
  A0 --> A4["A4: Rescue & Recover"]
  A0 --> A5["A5: Handover to Medical"]
  classDef a fill:#0284c7,color:#fff; class A0,A1,A2,A3,A4,A5 a;

Figure OV-5a — Operational activity decomposition tree.

flowchart LR
  IN(["Distress Alert"]) --> A1["A1 Detect & Locate"]
  A1 -->|"Position fix"| A2["A2 Plan Response"]
  A2 -->|"Search plan + tasking"| A3["A3 Execute Search"]
  A3 -->|"Survivor located"| A4["A4 Rescue & Recover"]
  A4 -->|"Survivor aboard"| A5["A5 Handover"]
  A5 --> OUT(["Survivor in care"])
  CTRL["Control: SAR Doctrine / Rules"] -.-> A2
  MECH["Mechanism: RCC, Aircraft, Cutter"] -.-> A3
  classDef a fill:#0284c7,color:#fff; classDef io fill:#13294b,color:#fff;
  class A1,A2,A3,A4,A5 a; class IN,OUT io;

Figure OV-5b — Activity flow with ICOM: inputs/outputs (arrows), controls and mechanisms (dashed).

OV-6a / 6b / 6c

Operational Behavior — Rules, States & Events

OV-6a = business rules; OV-6b = state transitions; OV-6c = event-trace (sequence) of an operational scenario.

OV-6a — Operational Rules (sample)

Rule	Statement
R-1	IF distress alert received THEN RCC must acknowledge within 5 minutes.
R-2	IF position uncertainty > 10 nm THEN expand search area before tasking.
R-3	IF survivor recovered THEN notify nearest medical facility immediately.

OV-6b — State Transition

stateDiagram-v2
  [*] --> AlertReceived
  AlertReceived --> Locating: position requested
  Locating --> Planning: position fixed
  Planning --> Searching: assets tasked
  Searching --> Rescuing: survivor located
  Searching --> Searching: not found / re-plan
  Rescuing --> Handover: survivor aboard
  Handover --> [*]: mission complete

Figure OV-6b — Lifecycle states of a single SAR mission.

OV-6c — Event-Trace (Sequence)

sequenceDiagram
  participant V as Vessel
  participant SAT as Satellite
  participant RCC as RCC
  participant AIR as Aircraft
  participant CUT as Cutter
  V->>SAT: Activate beacon (distress)
  SAT->>RCC: Relay distress alert
  RCC->>RCC: Fix position & plan search
  RCC->>AIR: Search tasking
  AIR->>RCC: Sighting report
  RCC->>CUT: Rescue tasking
  CUT->>V: Recover survivors
  CUT->>RCC: Recovery status (complete)

Figure OV-6c — Event-trace of the SAR scenario; the timeline used to measure response time (Q1).

Data & Information Viewpoint (DIV)

Describes the data exchanged in the architecture at three levels of detail — the structure behind the resource flows.

3 models · DIV-1, DIV-2, DIV-3

DIV-1

Conceptual Data Model

High-level information concepts and their relationships, in business language.

erDiagram
  DISTRESS-EVENT ||--o{ POSITION-FIX : has
  DISTRESS-EVENT ||--|| SEARCH-PLAN : triggers
  SEARCH-PLAN ||--o{ ASSET-TASKING : produces
  ASSET-TASKING }o--|| ASSET : assigns
  DISTRESS-EVENT ||--o{ SURVIVOR : involves

Figure DIV-1 — Conceptual data model: the key information concepts of SAR.

DIV-2

Logical Data Model

Adds attributes, keys, and precise cardinalities — technology-independent but implementation-ready in structure.

erDiagram
  DISTRESS_EVENT {
    string event_id PK
    string beacon_id
    datetime received_time
    string status
  }
  POSITION_FIX {
    string fix_id PK
    string event_id FK
    float latitude
    float longitude
    float uncertainty_nm
  }
  SEARCH_PLAN {
    string plan_id PK
    string event_id FK
    string search_pattern
    float area_sq_nm
  }
  DISTRESS_EVENT ||--o{ POSITION_FIX : has
  DISTRESS_EVENT ||--|| SEARCH_PLAN : triggers

Figure DIV-2 — Logical data model with attributes and keys.

DIV-3

Physical Data Model

The implementable schema — concrete data types, table/field names, formats, and the actual exchange message structure.

Field	Type	Format / Constraint	Example
`event_id`	CHAR(12)	"SAR" + yyyymmdd + seq	SAR202806230001
`beacon_id`	CHAR(15)	Cospas-Sarsat hex ID	1D0CE3A...
`latitude`	DECIMAL(8,5)	WGS-84, −90..90	13.08410
`received_time`	TIMESTAMP	ISO-8601 UTC	2026-06-23T04:21:00Z

Systems Viewpoint (SV)

Describes the systems that automate/support the operations and how they interconnect, function, and evolve.

13 models · SV-1 … SV-10c

SV-1

Systems Interface Description

The systems and the interfaces between them — the technical counterpart of OV-2. This is where single points of failure become visible (Q3).

flowchart LR
  S1["SARSAT Receiver"] -->|"alert feed (TCP)"| S2["SAR C2 System"]
  S2 -->|"plan data"| S3["Search Planner
(legacy, no backup)"]:::risk
  S3 -->|"tasking"| S2
  S2 -->|"datalink"| S4["Aircraft Mission System"]
  S2 -->|"datalink"| S5["Cutter Nav/Comms"]
  S2 -->|"HL7 feed"| S6["Hospital System"]
  classDef s fill:#d97706,color:#fff,stroke:#b45309;
  classDef risk fill:#fde2e2,stroke:#c0392b,color:#7b1c1c;
  class S1,S2,S4,S5,S6 s;

Figure SV-1 — System interfaces. The Search Planner has no redundancy — the confirmed SPOF.

SV-2

Systems Resource Flow Description

Adds the communication details to SV-1: protocols, media, and the physical paths the resource flows travel.

From	To	Resource	Protocol / Media
SARSAT Receiver	SAR C2	Distress alert	TCP/IP over leased line
SAR C2	Aircraft Mission Sys	Tasking + track	Link-16 / SATCOM
SAR C2	Cutter Nav/Comms	Tasking + track	VHF data + SATCOM
SAR C2	Hospital System	Patient handover	HL7 over TLS

SV-3

Systems-Systems Matrix

A matrix of which systems interface with which — quick to scan for missing or unexpected connections.

	C2	Receiver	Planner	Aircraft	Cutter	Hospital
C2	—	●	●	●	●	●
Receiver	●	—
Planner	●		—
Aircraft	●			—
Cutter	●				—
Hospital	●					—

● = interface exists. The C2 system is the hub — itself worth examining for resilience.

SV-4

Systems Functionality Description

The functions each system performs and how data flows between functions — the system-internal counterpart of OV-5.

flowchart LR
  F1["Receive Alert"] --> F2["Decode Beacon ID"]
  F2 --> F3["Resolve Position"]
  F3 --> F4["Generate Search Area"]
  F4 --> F5["Optimize Pattern"]
  F5 --> F6["Issue Tasking"]
  F6 --> F7["Track Assets"]
  classDef f fill:#d97706,color:#fff; class F1,F2,F3,F4,F5,F6,F7 f;

Figure SV-4 — System functions of the SAR C2 + Planner chain.

SV-5a / SV-5b

Operational Activity → System (Function) Traceability

The keystone for answering Q2 (coverage): maps operational activities (OV-5) to system functions (SV-4 → SV-5a) and to systems (SV-5b). Empty cells = unsupported activities = gaps.

Operational Activity ↓ / System →	Receiver	C2	Planner	Aircraft	Cutter
A1 Detect & Locate	●	●
A2 Plan Response		●	●
A3 Execute Search		●		●	●
A4 Rescue & Recover		●			●

⚓ Finding for Q2/Q3

Every activity has at least one supporting system (coverage ✔), but A2 "Plan Response" depends solely on the single legacy Planner — confirming the SPOF from SV-1.

SV-6

Systems Resource Flow Matrix

The detailed, attribute-rich matrix of every system-to-system data exchange (the SV equivalent of OV-3).

Exchange	Source Sys	Dest Sys	Format	Latency	Classification
EX-01 Alert	Receiver	C2	Cospas-Sarsat msg	<30 s	Unclass
EX-02 Tasking	C2	Aircraft	Link-16 J-series	<5 s	Restricted
EX-03 Handover	C2	Hospital	HL7 v2.x	<60 s	PII/Health

SV-7

Systems Measures Matrix

Performance parameters of systems — the data that answers Q1 (faster response). Compare As-Is vs To-Be.

Measure	System	As-Is	To-Be (2028)
Alert-to-detection time	Receiver	8 min	2 min
Plan generation time	Planner	25 min	5 min
Availability	C2 System	99.0%	99.95%
Time-to-first-asset	End-to-end	52 min	34 min (−35%)

✓ Answers Q1

The To-Be column shows a 35% reduction in time-to-first-asset, meeting CV-1 Goal 1 (≥30%).

SV-8

Systems Evolution Description

How systems migrate from As-Is to To-Be over time — the roadmap of system change.

gantt
  title SV-8 Systems Evolution
  dateFormat YYYY
  axisFormat %Y
  section C2 System
  Legacy radio C2        :done, 2024, 2026
  Networked C2 v2        :active, 2026, 2028
  section Planner
  Manual/legacy planner  :done, 2024, 2027
  Automated planner (HA) :2027, 2029
  section Sensors
  SARSAT receiver        :done, 2024, 2027
  Multi-constellation rx :2027, 2030

Figure SV-8 — System evolution roadmap; the new HA planner removes the SPOF.

SV-9

Systems Technology & Skills Forecast

Predicted technology and workforce-skill trends that will affect the systems — informs timing of upgrades.

Technology / Skill	Now	2-yr	4-yr
Beacon positioning	GPS only	GPS+Galileo	Multi-GNSS + MEOSAR
Search planning	Rule-based	Drift modeling	ML-assisted optimization
Workforce skill	Radio ops	Network ops	Data/ML literacy

SV-10a / 10b / 10c

Systems Behavior — Rules, States & Events

Mirror of OV-6 at the system level: SV-10a system rules, SV-10b system state transitions, SV-10c system event-trace.

SV-10a — System Rules (sample)

Rule	Statement
SR-1	If primary Planner is unavailable, C2 shall fail over to standby Planner within 30 s.
SR-2	C2 shall reject malformed beacon messages and log to audit.

SV-10b — System State Transition

stateDiagram-v2
  [*] --> Idle
  Idle --> Receiving: alert arrives
  Receiving --> Processing: message valid
  Receiving --> Idle: message invalid
  Processing --> Planning: position resolved
  Planning --> Tasking: plan ready
  Tasking --> Monitoring: tasks dispatched
  Monitoring --> Idle: mission closed

Figure SV-10b — Internal states of the SAR C2 system.

SV-10c — System Event-Trace

sequenceDiagram
  participant RX as Receiver
  participant C2 as C2 System
  participant PL as Planner
  participant AC as Aircraft Sys
  RX->>C2: Distress message
  C2->>C2: Validate & decode
  C2->>PL: Request search plan
  PL-->>C2: Search pattern + area
  C2->>AC: Tasking (Link-16)
  AC-->>C2: Acknowledge + ETA

Figure SV-10c — System event-trace realizing the OV-6c operational scenario.

Services Viewpoint (SvcV)

The service-oriented (SOA) counterpart of the Systems Viewpoint — describes the architecture in terms of reusable services. Its 13 models mirror SV one-for-one.

13 models · SvcV-1 … SvcV-10c

SvcV is used when the architecture is service-based. Each SvcV model parallels the equivalent SV model — substitute "service" for "system." Below are the most-used ones for the SAR example; the remainder follow the same pattern as their SV twins.

SvcV model	SV twin	Purpose (SAR)
SvcV-1 Services Context	SV-1	Which services exist & how they connect.
SvcV-2 Service Resource Flow	SV-2	Comms/protocol detail between services.
SvcV-3a/3b Matrices	SV-3	System↔service and service↔service interfaces.
SvcV-4 Service Functionality	SV-4	Functions each service provides.
SvcV-5 Activity→Service Traceability	SV-5	Which service supports which activity.
SvcV-6 Service Resource Flow Matrix	SV-6	Detailed exchange attributes.
SvcV-7 Service Measures	SV-7	SLA/QoS measures.
SvcV-8 Service Evolution	SV-8	Service roadmap.
SvcV-9 Tech & Skills Forecast	SV-9	Service technology outlook.
SvcV-10a/b/c Behavior	SV-10	Service rules, states, event-trace.

SvcV-1 — Services Context (SAR)

flowchart LR
  DD["Distress Detection Service"] --> SP["Search Planning Service"]
  PR["Position Reporting Service"] --> SP
  SP --> AT["Asset Tasking Service"]
  AT --> TM["Track Management Service"]
  TM --> HO["Handover Service"]
  classDef sv fill:#0d9488,color:#fff; class DD,SP,PR,AT,TM,HO sv;

Figure SvcV-1 — The reusable services delivering the SAR capability (SOA view).

SvcV-4 — Service Functionality

flowchart TD
  SP["Search Planning Service"]
  SP --> O1["computeSearchArea()"]
  SP --> O2["optimizePattern()"]
  SP --> O3["estimateDrift()"]
  classDef sv fill:#0d9488,color:#fff; classDef op fill:#5eead4,color:#06302b;
  class SP sv; class O1,O2,O3 op;

Figure SvcV-4 — Operations exposed by the Search Planning Service.

Standards Viewpoint (StdV)

The rules — technical standards, policies, and guidance — that govern the implementation, plus how they are forecast to change.

2 models · StdV-1, StdV-2

StdV-1

Standards Profile

The set of standards that apply to the architecture's systems/services, organized by area.

Area	Standard	Applies to
Distress beacons	Cospas-Sarsat T.001 / T.018	Receiver, beacon decode
Tactical datalink	MIL-STD-6016 (Link-16)	C2 ↔ Aircraft/Cutter
Position datum	WGS-84	All positioning
Medical exchange	HL7 v2.x over TLS 1.3	C2 ↔ Hospital
Time reference	ISO-8601 UTC	All timestamps

StdV-2

Standards Forecast

Predicted evolution of the standards — so upgrades are timed before standards become obsolete.

gantt
  title StdV-2 Standards Forecast
  dateFormat YYYY
  axisFormat %Y
  section Beacon
  LEOSAR/GEOSAR (current)  :done, 2024, 2027
  MEOSAR mandatory         :2027, 2030
  section Security
  TLS 1.2                  :done, 2024, 2026
  TLS 1.3 baseline         :active, 2026, 2030

Figure StdV-2 — Standards forecast informs when the receiver and crypto must be upgraded.

Project Viewpoint (PV)

Connects architecture to the programs/projects that deliver it — the acquisition and portfolio bridge.

3 models · PV-1, PV-2, PV-3

PV-1

Project Portfolio Relationships

How the delivering projects relate, organize, and depend on each other.

flowchart TD
  PROG["SAR Modernization Program"]
  PROG --> P1["Project A:
Networked C2"]
  PROG --> P2["Project B:
HA Search Planner"]
  PROG --> P3["Project C:
Multi-GNSS Receiver"]
  P1 -. depends on .-> P3
  P2 -. depends on .-> P1
  classDef p fill:#4f46e5,color:#fff; class PROG,P1,P2,P3 p;

Figure PV-1 — Program/project portfolio and inter-project dependencies.

PV-2

Project Timelines

The schedule/milestones of the projects — when each delivers.

gantt
  title PV-2 Project Timelines
  dateFormat YYYY-MM
  axisFormat %Y
  section Project A — Networked C2
  Design       :a1, 2026-01, 6M
  Build        :a2, after a1, 8M
  Deploy       :a3, after a2, 4M
  section Project B — HA Planner
  Design       :b1, 2027-01, 6M
  Build        :b2, after b1, 10M
  section Project C — GNSS Receiver
  Procure      :c1, 2027-06, 6M
  Integrate    :c2, after c1, 6M

Figure PV-2 — Project timelines with milestones.

PV-3

Project → Capability Mapping

Which project delivers which capability — closing the loop from projects (PV) back to capabilities (CV).

Project ↓ / Capability →	Detect & Locate	Coordinate & Plan	Search
Project A — Networked C2	●	●	●
Project B — HA Planner		●
Project C — GNSS Receiver	●

2 End-to-End Traceability — How It All Connects

The payoff of a data-centric framework: every layer traces to the next, so a decision-maker can follow a thread from vision all the way to a project milestone — and back.

flowchart TD
  CV1["CV-1 Vision"] --> CV2["CV-2 Capabilities"]
  CV2 --> CV6["CV-6 Cap→Activity"]
  CV6 --> OV5["OV-5 Activities"]
  OV5 --> SV5["SV-5 Activity→System"]
  SV5 --> SV1["SV-1 Systems"]
  SV1 --> SV7["SV-7 Measures"]
  SV7 --> SV8["SV-8 Evolution"]
  SV8 --> PV2["PV-2 Projects"]
  PV2 --> PV3["PV-3 Project→Capability"]
  PV3 -.closes loop.-> CV2
  classDef cv fill:#7c3aed,color:#fff; classDef ov fill:#0284c7,color:#fff;
  classDef sv fill:#d97706,color:#fff; classDef pv fill:#4f46e5,color:#fff;
  class CV1,CV2,CV6 cv; class OV5 ov; class SV5,SV1,SV7,SV8 sv; class PV2,PV3 pv;

Figure 2.0 — The golden thread: Vision → Capability → Activity → System → Measure → Evolution → Project → Capability.

With this chain in place, the three Step-1 questions are answered with evidence:

Q1 Faster? SV-7 shows −35% time-to-first-asset, meeting CV-1 Goal 1.
Q2 Coverage? SV-5b shows every activity has a supporting system.
Q3 SPOF? SV-1 / CV-4 expose the single Planner; SV-8 / PV-2 show Project B fixes it.

3 Practical Build Checklist

Use this as your repeatable recipe when starting a real DoDAF effort.

Write AV-1 first — purpose, scope, users (Steps 1–2).
List your questions and map them to models (Step 3). Choose Fit-for-Purpose.
Stand up a repository and define terms in AV-2 as you go (Step 4).
Capability layer: CV-1 vision → CV-2 taxonomy → CV-3 phasing.
Operational layer: OV-1 concept → OV-5 activities → OV-2/3 flows → OV-6 behavior.
Data layer: DIV-1 → DIV-2 → DIV-3 for the exchanges that matter.
Systems/Services layer: SV-1/SvcV-1 → SV-4 functions → SV-5 traceability → SV-7 measures.
Standards: StdV-1 profile → StdV-2 forecast.
Project layer: PV-1 portfolio → PV-2 timelines → PV-3 mapping.
Analyze & present (Steps 5–6): run traceability, measures, SPOF; render per audience.
Iterate — feed new questions back into Step 1.

✓ Remember

DoDAF is data first. Keep one integrated repository, build only the models your decisions need, and let traceability do the heavy lifting.