Defense Systems Acquisition Architecture: Using DoDAF for Procurement Programs

Few programs in government are larger, slower-moving, or more heavily governed than a major defense acquisition. Every gate from concept to full-rate production turns on evidence, and a sizable share of that evidence is architecture. DoDAF — the Department of Defense Architecture Framework — supplies the standardized vocabulary and view types, and Sparx EA with the UPDM MDG supplies the environment to produce and maintain them across a multi-year, multi-contractor program.

How DoDAF supports the defense acquisition lifecycle

The US defense acquisition system is governed by DoDI 5000.02 (Operation of the Adaptive Acquisition Framework), with capability requirements set through the JCIDS process under CJCSI 5123.01. Architecture has a role at every stage — not as a deliverable bolted on at the end, but as the connective tissue between what was asked for and what is being built.

The JCIDS process: operational requirements as architecture

Before a program is approved for development, the operational need has to be documented and validated. JCIDS produces a hierarchy of requirements documents, each with a corresponding architecture footprint:

• ICD (Initial Capabilities Document) identifies the gap between current and required capability. It establishes the threat environment, the operational scenarios where the gap bites, and the performance criteria — without specifying a technical solution. In DoDAF terms, the ICD is backed by OV-1 (High-Level Operational Concept), OV-2 (Operational Resource Flow), and OV-3 (Operational Resource Flow Matrix).
• CDD (Capability Development Document) defines the specific requirements the program must meet, including Key Performance Parameters (KPPs) and Key System Attributes (KSAs). It is backed by more detailed OV views and starts to introduce system-level requirements in SV views.
• CPD (Capability Production Document) defines production and fielding requirements, backed by SV and TV views that reflect the validated system design.

In Sparx EA, each JCIDS document submission is a program milestone. The views produced for it are baselined at the moment of submission, building a version history that shows how the architecture evolved from an initial capability gap to a production system definition.

What each milestone expects

The three major decision points carry distinct architecture obligations. The table below summarizes the typical view set and the architectural intent at each gate.

Milestone	Acquisition decision	Primary DoDAF views	Architectural intent
Milestone A	Material Solution Analysis — confirm a material solution is the right path	OV-1 through OV-6; SV-1 (alternatives)	Operational context is defined; candidate architectures are modeled as separate scenarios or packages for trade analysis.
Milestone B	Engineering & Manufacturing Development — award of the system development contract	OV-1, OV-2, OV-3, OV-5, OV-6; SV-1, SV-2, SV-4; TV-1	A clear architecture baseline exists. The operational-to-system trace is established before development money is committed.
Milestone C	Production & Deployment — authorize full-rate production	Adds SV-5, SV-6, SV-7, SV-8; TV-2	Architecture is fully detailed and validated through test, including capability-to-activity mapping and planned evolution.

Milestone B is the one that concentrates risk. It commits the development contract, so the program must walk in with a defensible baseline rather than a sketch — which is why the operational architecture (OV) and its trace into the system architecture (SV) both need to be solid by that gate, not after it.

DoDAF views and their role in acquisition

The full DoDAF view set is extensive, but acquisition programs lean on a consistent subset organized by viewpoint.

All Viewpoint (AV)

AV-1 (Overview and Summary Information) sets the scope — which program, which time period, which operational context. AV-2 (Integrated Dictionary) is the authoritative lexicon. Every program starts here, because everything downstream references it.

Operational Viewpoint (OV)

The OV views describe the mission problem independently of any system implementation:

• OV-1: the “big picture” concept diagram — major operational entities (commanders, forces, friendly and threat elements) and their relationships. Typically a rich picture rather than a strict notation diagram.
• OV-2: Operational Resource Flow Description — nodes and the needlines (information requirements) between them. This is the primary view for what information must flow between entities to accomplish the mission.
• OV-3: Operational Resource Flow Matrix — the tabular form of OV-2, with sender, receiver, data element, and media.
• OV-5a/5b: Operational Activity Decomposition Tree and Model — the hierarchy of operational activities and their information exchanges.
• OV-6c: Event-Trace Description — a swimlane sequence showing the time-ordered events and exchanges in a specific scenario.

Systems Viewpoint (SV)

The SV views describe the systems that implement the operational architecture:

• SV-1: Systems Interface Description — system nodes and the data flows between them. This is the system view that traces directly back to OV-2.
• SV-2: Systems Resource Flow Description — detailed data flows between system interfaces.
• SV-4: Systems Functionality Description — what functions each system performs.
• SV-5a/5b: Operational Activity to Systems Function Traceability — the cross-viewpoint link showing which system functions support which operational activities.

Technical Viewpoint (TV)

The TV views define the technical standards that govern the program:

• TV-1: Technical Standards Profile — the catalog of approved standards (encryption, protocols, data formats, interfaces) that apply.
• TV-2: Technical Standards Forecast — how that profile is expected to evolve across the program lifecycle.

Configuring Sparx EA for DoDAF and UPDM

Sparx EA’s UPDM (Unified Profile for DoDAF and MODAF) MDG Technology configures the tool for DoDAF program architecture. A workable package structure for a major program separates the viewpoints, the program-management baselines, and a shared data registry:

Program Architecture Repository
├── AV-Views (All Viewpoint)
│   ├── AV-1 Program Description
│   └── AV-2 Integrated Dictionary
├── OV-Views (Operational Viewpoint)
│   ├── OV-1 High-Level Concept
│   ├── OV-2 Operational Resource Flow
│   ├── OV-3 Operational Resource Flow Matrix
│   ├── OV-5 Operational Activities
│   └── OV-6 Operational Rules and Scenarios
├── SV-Views (Systems Viewpoint)
│   ├── SV-1 Systems Interface Description
│   ├── SV-2 Systems Resource Flow
│   ├── SV-4 Systems Functionality
│   └── SV-5 Activity-to-Function Traceability
├── TV-Views (Technical Viewpoint)
│   ├── TV-1 Technical Standards Profile
│   └── TV-2 Technical Standards Forecast
├── Program Management
│   ├── Milestone A Baseline
│   ├── Milestone B Baseline
│   └── Milestone C Baseline
└── Common Data Registry
    ├── Operational Nodes
    ├── System Nodes
    ├── Data Elements
    └── Standards

The Common Data Registry is what keeps a large program coherent. Operational Nodes defined in OV-2 are the same elements used in OV-5 and OV-6; System Nodes defined for SV-1 are the same elements used in SV-2, SV-4, and SV-5. Defining each element once and referencing it everywhere — rather than copy-and-pasting — means a change to a node definition propagates correctly to every view that uses it.

DM2 compliance: the UPDM MDG configures elements with DoDAF Meta-Model (DM2)–aligned stereotypes. OV-2 needlines are «NeedLine»; OV-5 activities are «OperationalActivity»; SV-1 system nodes are «SystemNode»; SV-1 data flows are «SystemDataFlow»; TV-1 standards are «TechnicalStandard». That alignment is what makes the architecture correctly structured for DoDAF data exchange and tool interoperability.

System-of-systems architecture at F-35 scale

The F-35 Lightning II Joint Strike Fighter program is the canonical example of system-of-systems acquisition architecture. At the operational level, the F-35 is one node in a much larger joint architecture — operating alongside AWACS/E-3, surface combatants, ground-based air defense, and coalition air forces. Its OV-2 describes the information flows between those entities: the Link 16 tactical data link, MADL (Multifunction Advanced Data Link) for F-35-to-F-35 and F-35-to-F-22 communication, and the command and control flows around them.

At the system level, each platform carries its own architecture: the F-35 avionics suite (mission systems computer, sensor fusion, electronic warfare, communications), ground support equipment, the maintenance information system (ALIS, now transitioning to ODIN), and supply-chain logistics. Each platform’s architecture is a separate SV package, managed by the responsible contractor (Lockheed Martin, Northrop Grumman, BAE Systems) but connected to the program-level OV architecture through SV-5 traceability.

In Sparx EA, that scale is held together three ways:

• Multi-package architecture. Each platform or major subsystem gets its own package. The F-35A, F-35B, and F-35C variants each carry distinct SV-1 architectures — reflecting their different propulsion and airframe configurations — while sharing the OV-level operational architecture.
• Contractor-managed packages. Package-level access controls let each contractor manage their own SV package while the program office manages the OV package and cross-cutting governance. Sparx EA Pro Cloud Server’s role-based access and model locking support this federated model.
• Baselines across milestones. Baseline packages preserve the architecture at each gate. The Milestone B baseline captures the architecture at contract award; design changes during development land in the live model, and a fresh baseline is cut when Critical Design Review (CDR) is passed. The program office can compare any two baselines to see exactly what changed architecturally between them.

Cross-viewpoint traceability: from capability to system

The most valuable property of DoDAF architecture in Sparx EA is end-to-end traceability — the ability to follow a capability requirement from the JCIDS document, through the operational architecture, to the specific system function and technical standard that satisfies it. In Sparx EA the chain runs:

Capability (from ICD/CDD) → OV-5 Operational Activity → SV-5 System Function → SV-1 System Node → TV-1 Technical Standard.

That four-hop chain is fully navigable through the tool’s element relationship model. A program manager can start from a KPP in the CDD and trace to every system function and standard that contributes to meeting it. A requirements manager can start from a TV-1 standard and trace to every operational activity it ultimately supports. An acquisition official can ask “which systems are on the critical path to Capability X?” and the architecture answers it — which is the whole point of building it as a connected model rather than a folder of disconnected diagrams.

Frequently asked questions

Where Sparx Services fits

Major defense acquisition programs need architecture that keeps pace with the program — from JCIDS operational views, through Milestone B system architecture, to CDR-level interfaces. Sparx Services provides ongoing support for large DoDAF programs and training for DoDAF specialist architects. For programs standing up their architecture practice, we help you configure the solution — a DoDAF/UPDM-configured Sparx EA repository, scoped to your program and its governance structure.