Insight · Frameworks

Defense Systems Acquisition Architecture: Using DoDAF for Procurement Programs

By Sparx Services · January 26, 2026 · 9 min read

Few programs in government are larger 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.

The acquisition architect's job is to show, at every gate, that the operational need, the system design and the technical standards still line up. The upkeep behind that is mechanical and constant: building views, keeping shared definitions in one place, cutting baselines and tracing each requirement through the layers. In AI-augmented work the architect decides what the program must show at the gate, and AI builds and maintains the views and traces in the model. The skill is knowing DoDAF and the acquisition process well enough to say what the architecture must contain, and to review what comes back. The rest of this article is the reference for that, and acquisition policy and the requirements process change, so confirm current DoD policy for your 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 StdV 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.

What each milestone expects
Milestone	Acquisition decision	Primary DoDAF views	Architectural intent
Milestone A	Entry to Technology Maturation and Risk Reduction, after the material solution analysis	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; StdV-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; StdV-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.

Standards Viewpoint (StdV)

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

StdV-1: Technical Standards Profile: the catalog of approved standards (encryption, protocols, data formats, interfaces) that apply.
StdV-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
├── StdV-Views (Standards Viewpoint)
│   ├── StdV-1 Technical Standards Profile
│   └── StdV-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»; StdV-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 program scale

A large combat aircraft program shows the pattern. At the operational level, the aircraft is one node in a much larger joint architecture, operating alongside airborne command and control, surface combatants, ground-based air defense and coalition air forces. Its OV-2 describes the information flows between those entities, including the tactical data links and the command and control flows around them.

At the system level, each platform carries its own architecture: the avionics suite, ground support equipment, the maintenance information system and supply-chain logistics. Each platform’s architecture is a separate SV package, managed by the responsible contractor 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. Variants of the same platform can carry distinct SV-1 architectures 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 → StdV-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 StdV-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

Is DoDAF mandatory for all DoD acquisition programs?

DoDAF is mandated for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) programs through DoDI 5000.02 and the DoD Architecture Registry System (DARS) submission requirement. For Acquisition Category (ACAT) I and II programs, DoDAF artifacts are required at key decision points. For smaller programs (ACAT III and below), DoDAF is not formally mandated but is often required by the program executive office. Sparx EA covers the full view range for mandatory programs while remaining equally useful for producing the relevant subset on smaller ones.

What is the relationship between DoDAF and JCIDS documents?

DoDAF architecture is the graphical and structured representation of what JCIDS documents (ICD, CDD, CPD) capture in prose. The ICD’s operational problem becomes the OV-1; its needline requirements become the OV-2; its performance parameters become OV-6 scenario timing requirements. The CDD’s system-level requirements begin to appear in SV views. That relationship is rarely explicit in program documentation, and building the explicit trace is worth doing.

How is the repository shared between the prime contractor and the government program office?

This is the most common program-management challenge in defense acquisition. The recommended pattern on Sparx EA Pro Cloud Server: the government program office hosts the authoritative repository (on NIPR or a classified network as appropriate); the prime and major subcontractors get role-based access to their respective SV packages; government architects own the OV package and the common data registry. All changes go through the architecture change control board (ACCB), with model locking preventing unauthorized modifications. Sparx Services can advise on specific access-control configurations for your program governance structure.

What are the architecture deliverables for a Critical Design Review (CDR)?

CDR requires the system architecture to be detailed enough to confirm the design can meet performance requirements. Deliverables typically include a final SV-1 (all system interfaces, including internal interfaces to CDR depth), SV-2 (data flows at the interface level), SV-4 (system functions at CDR decomposition depth), SV-7 (system measures, performance parameters assigned to functions), and a finalized StdV-1 standards profile. These are maintained in Sparx EA and exported for the CDR package.

How does DoDAF architecture connect to the Test and Evaluation Master Plan (TEMP)?

The TEMP defines how the program will test that the system meets its requirements. OV-6 operational scenarios, SV-4 system functions, and SV-7 system measures provide the operational and technical context for test event design. In Sparx EA, test scenarios cross-reference the OV-6 scenarios they exercise, and each test event links to the operational activities and system functions it validates, giving the test and evaluation community traceable evidence of full operational coverage.

How does Sparx EA handle security classification in a defense program?

In a NIPR (Unclassified/CUI) environment, Sparx EA Pro Cloud Server’s role-based access controls govern who can view and edit which packages. For classified architectures (SIPR or above), Sparx EA is deployed on the classified network with physical and logical separation from unclassified systems. Classified elements sit in restricted packages with appropriate markings in element notes and diagram headers. Confirm the deployment approach with the program's security authority.

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. For programs standing up their architecture practice, Configure the Solution covers a DoDAF/UPDM-configured Sparx EA repository scoped to your program and its governance structure.

Get your acquisition architecture built and kept current, by your team or by us.

We can teach your architects to build and maintain DoDAF views with AI on your own repository and mentor them until it sticks, or assess the program and plan the architecture build for you and hand it over. Most teams want some of both.

Book a call

Keep reading