Sparx EA with DoDAF/UPDM MDG is the standard modeling environment for major defense acquisition program architecture: supporting the progression from JCIDS capability requirements through Milestone A/B/C decision points to system-of-systems operational views and single-system technical architecture.
Defense acquisition programs are among the largest, most complex, and most heavily governed programs in any government. From the Joint Capabilities Integration and Development System (JCIDS) requirements process that establishes what capability is needed, through Milestone A (solution approach approved), Milestone B (system development contract awarded), and Milestone C (production authorized), every decision point requires architecture artifacts. DoDAF (Department of Defense Architecture Framework) provides the standardized vocabulary and view types for these artifacts: and Sparx EA with the UPDM MDG provides the modeling environment to produce them. This article explains how DoDAF supports the defense acquisition lifecycle, which views are required at which acquisition phase, how Sparx EA manages the architecture across a multi-phase, multi-contractor program, and what a major acquisition program architecture looks like at system-of-systems scale.
Key Takeaways
- DoDAF supports the full defense acquisition lifecycle: JCIDS operational requirements are expressed in OV views; system design is expressed in SV views; technical standards are expressed in TV views.
- Each JCIDS document (ICD, CDD, CPD) has corresponding DoDAF architecture artifacts; Sparx EA manages the version control across acquisition milestones.
- Milestone A, B, and C decision points each have specific architecture deliverables: Sparx EA tracks these requirements and manages view production for each gate.
- System-of-systems architecture at the OV level traces to individual platform system architectures through SV relationships: the F-35 program scale of program architecture management.
- Multi-contractor repository management in Sparx EA requires a governed architecture data authority and integration model.
How DoDAF Supports the Defense Acquisition Lifecycle
The US defense acquisition system is governed by DoDI 5000.02 (Operation of the Adaptive Acquisition Framework) and the associated JCIDS process (CJCSI 3170.01). Architecture plays a role at every stage.
The JCIDS Process: Operational Requirements as Architecture
Before a program is approved for development, the operational need must be documented and validated. The JCIDS process produces a hierarchy of requirements documents:
- ICD (Initial Capabilities Document): Identifies the capability gap between current capabilities and the required capability. The ICD establishes the operational context: the threat environment, the operational scenarios where the capability gap matters, and the performance criteria. In DoDAF terms, the ICD is supported by OV-1 (High-Level Operational Concept), OV-2 (Operational Resource Flow), and OV-3 (Operational Resource Flow Matrix): views that describe the operational context without specifying a technical solution.
- CDD (Capability Development Document): Defines the specific capability requirements to be met by the program, including Key Performance Parameters (KPPs) and Key System Attributes (KSAs). The CDD is supported by more detailed OV views and begins to introduce system-level requirements in SV views.
- CPD (Capability Production Document): Defines the production and fielding requirements, supported by SV and TV views that reflect the validated system design.
In Sparx EA, each JCIDS document generation is a program milestone. The architecture views produced for each document are baselined in the Sparx EA repository at the time of document submission, creating a version history that shows how the architecture evolved from initial capability gap to production system definition.
Milestone A: Material Solution Analysis
Milestone A is the decision point at which the program establishes that a material solution (as opposed to a non-material solution such as doctrine or training changes) is appropriate. The Architecture Alternatives Analysis at Milestone A may include multiple candidate architectures: each represented as a separate Scenario or Package in Sparx EA. The DoDAF views produced for Milestone A are primarily operational (OV-1 through OV-6) and begin to introduce system-level alternatives in SV-1.
Milestone B: Engineering and Manufacturing Development
Milestone B is the most significant acquisition decision point: the award of the system development contract. By Milestone B, the program must have a clear architecture baseline. DoDAF views required at or before Milestone B typically include: OV-1, OV-2, OV-3, OV-5 (Operational Activity Decomposition), OV-6 (Operational Rules, State Transitions, and Event-Trace), SV-1 (System Interface Description), SV-2 (System Resource Flow Description), SV-4 (System Functionality Description), TV-1 (Technical Standards Profile).
Milestone C: Production and Deployment
Milestone C authorizes full-rate production. By this point, the architecture is fully detailed and validated through test. DoDAF views for Milestone C add: SV-5 (Capability to Operational Activity Mapping), SV-6 (System Resource Flow Matrix), SV-7 (System Measures Matrix), SV-8 (System Evolution Description) showing planned upgrades, and TV-2 (Technical Standards Forecast).
DoDAF Views and Their Role in Acquisition
The full DoDAF view set is extensive, but acquisition programs use a subset consistently:
All Viewpoint (AV): AV-1 (Overview and Summary Information) provides the architecture description scope: what program, what time period, what operational context. AV-2 (Integrated Dictionary) is the authoritative lexicon for the program. Every program starts here.
Operational Viewpoint (OV): The OV views describe the operational context and requirements independently of any specific system implementation. They are the architecture of the mission problem:
- OV-1: High-level operational concept diagram: the “big picture” view showing the major operational entities (commanders, forces, friendly and threat elements) and their relationships in the operational scenario. The OV-1 is typically a rich picture or concept diagram, not a strict notation diagram.
- OV-2: Operational Resource Flow Description: nodes (operational entities, organizations, or roles) and the needlines (information requirements) between them. This is the primary document for showing what information must flow between operational entities to accomplish the mission.
- OV-3: Operational Resource Flow Matrix: tabular representation of OV-2 information flows, with sender, receiver, data element, and media.
- OV-5a/5b: Operational Activity Decomposition Tree / Operational Activity Model: hierarchical decomposition of operational activities and their information exchanges.
- OV-6c: Event-Trace Description: swimlane sequence diagram showing the time-ordered sequence of operational events and information exchanges in a specific scenario.
Systems Viewpoint (SV): The SV views describe the systems that implement the operational architecture:
- SV-1: Systems Interface Description: the primary system-level diagram showing system nodes and the system data flows between them. The SV-1 is the system architecture view that traces directly to the OV-2 operational architecture.
- 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 critical cross-viewpoint traceability 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) applicable to the program.
- TV-2: Technical Standards Forecast: how the standards profile is expected to evolve over the program lifecycle.
Sparx EA Architecture: DoDAF/UPDM Configuration
Sparx EA’s UPDM (Unified Profile for DoDAF and MODAF) MDG plug-in configures the tool for DoDAF program architecture:
Package Structure for a Major Acquisition Program:
“ 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 (2025) │ ├── Milestone B Baseline (2027) │ └── Milestone C Baseline (2030) └── Common Data Registry ├── Operational Nodes ├── System Nodes ├── Data Elements └── Standards “
The Common Data Registry is the key to architecture data integrity across a large program. Operational Nodes defined in OV-2 are the same elements used in OV-5 and OV-6: they are defined once in the registry and referenced in multiple views. System Nodes defined for SV-1 are the same elements used in SV-2, SV-4, and SV-5 traceability views. This element reuse (rather than copy-and-paste) ensures that changes to a node definition propagate correctly to all views that use it.
DoDAF Meta-Model (DM2) Compliance: The UPDM MDG configures Sparx EA elements with DM2-aligned stereotypes. OV-2 Needlines are «NeedLine» stereotyped elements. OV-5 Operational Activities are «OperationalActivity» elements. SV-1 System Nodes are «SystemNode» elements. SV-1 System Data Flows are «SystemDataFlow» elements. TV-1 Standards are «TechnicalStandard» elements. This stereotype alignment ensures that the program architecture is correctly structured for DoDAF data exchange and tool interoperability.
System-of-Systems Architecture: F-35 Scale Program Management
The F-35 Lightning II Joint Strike Fighter program is the canonical example of system-of-systems acquisition architecture. At the operational view level, the F-35 is one node in a much larger joint operational architecture: it operates in conjunction with AWACS/E-3, the Navy’s surface combatants, ground-based air defense, and allied coalition air forces. The OV-2 for the F-35 program describes the information flows between these operational 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 various command and control information flows.
At the system view level, each platform has its own system architecture: the F-35 avionics suite (mission systems computer, sensor fusion, electronic warfare, communications), the ground support equipment, the maintenance information system (ALIS/ODIN), and the supply chain logistics system. Each platform’s system architecture is a separate SV package: managed by the respective contractor (Lockheed Martin, Northrop Grumman, BAE Systems): but connected to the program-level OV architecture through SV-5 traceability.
In Sparx EA, this scale of architecture is managed through:
Multi-Package Architecture: Each platform or major subsystem has its own package within the program repository. The F-35A, F-35B, and F-35C variants each have distinct SV-1 architectures (reflecting their different propulsion and airframe configurations) but share the OV-level operational architecture.
Contractor-Managed Packages: In a multi-contractor program, package-level access controls allow each contractor to manage their own SV package while the program office manages the OV package and the cross-cutting architecture governance. Sparx EA Pro Cloud Server’s role-based access and model locking supports this federated architecture management model.
Version Management Across Milestones: Baseline packages preserve the architecture at each milestone. The Milestone B baseline captures the architecture at contract award. Design changes during Engineering and Manufacturing Development are reflected in the live model; when CDR (Critical Design Review) is passed, a new baseline is created. The program office can compare any two baselines to understand what changed architecturally between milestones.
Cross-Viewpoint Traceability: From Capability to System
The most powerful feature of DoDAF architecture in Sparx EA is cross-viewpoint traceability: the ability to trace 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, this traceability chain is:
Capability (from ICD/CDD) → links to OV-5 Operational Activity (via Capability-to-Activity traceability) → links to SV-5 System Function (via SV-5 Activity-to-Function traceability) → links to SV-1 System Node (the system providing the function) → links to TV-1 Technical Standard (the standards governing the system interface or function).
This four-hop traceability chain is entirely navigable in Sparx EA through its element relationship model. A program manager can start from a KPP (Key Performance Parameter) in the CDD and trace to every system function and technical standard that contributes to meeting that KPP. 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 critical path to Capability X?” and the architecture provides the answer.
FAQ
Q1: 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 architecture 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 supports the full view range for mandatory programs while being equally useful for producing relevant views for smaller programs.
Q2: What is the relationship between DoDAF and JCIDS documents? DoDAF architecture provides the graphical and structured representation of the content captured in JCIDS documents (ICD, CDD, CPD). The ICD’s operational problem description becomes the OV-1; its needline requirements become OV-2; its performance parameters become OV-6 scenario timing requirements. The CDD’s system-level requirements begin to appear in SV views. This relationship is not always explicit in program documentation: Sparx Services helps acquisition teams build the explicit traceability between JCIDS document content and DoDAF architecture views.
Q3: How does Sparx EA handle the DoDAF Integrated Architecture data requirements? DoD’s DoDAF Integrated Architecture approach requires that architecture data be stored in a machine-readable format that supports query and cross-program analysis. The DoD Architecture Registry System (DARS) provides the repository for program architectures. Sparx EA exports to the Universal Core (UCOre) XML format supported by DARS for formal submissions. EA GraphLink additionally enables program stakeholders to query the architecture data without requiring DARS access.
Q4: How does program architecture management work when the prime contractor and government program office both need to maintain the repository? This is the most common program management challenge in defense acquisition. The recommended approach with Sparx EA Pro Cloud Server: the government program office hosts the authoritative repository (on NIPR or classified network as appropriate). The prime contractor and major subcontractors have role-based access to their respective SV packages. Government architects manage the OV package and the common data registry. All changes go through the architecture change control board (ACCB) process, with model locking preventing unauthorised modifications. Sparx Services can advise on specific access control configurations for program governance structures.
Q5: What are the architecture deliverables for a DoD program’s Critical Design Review (CDR)? CDR typically requires that the system architecture is sufficiently detailed to confirm the design can meet performance requirements. Architecture deliverables at CDR include: final SV-1 (showing all system interfaces, including internal interfaces to the CDR level), SV-2 (data flows at the interface level), SV-4 (system functions at CDR decomposition depth), SV-7 (system measures: performance parameters assigned to system functions), and TV-1 (finalized technical standards profile confirming all interface standards are specified). These views are maintained in Sparx EA and exported/presented for the CDR package.
Q6: 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 performance requirements. Architecture views: particularly 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 can be cross-referenced to the OV-6 operational scenarios they exercise: each test event links to the operational activities and system functions it validates. This traceability supports the T&E community’s ability to show full operational coverage.
Q7: How does Sparx EA manage architecture security classification in a defense program? In a NIPR (Unclassified/CUI) environment, Sparx EA Pro Cloud Server’s role-based access controls manage who can view and edit which architecture packages. For classified architectures (SIPR or above), Sparx EA is deployed on the classified network with physical and logical separation from unclassified systems. Architecture elements that are classified are placed in restricted packages with appropriate classification markings in element notes and diagram headers. Sparx Services has supported DoD program architecture deployments at appropriate classification levels.
Q8: What does Sparx Services’ Platform Support engagement deliver for a major acquisition program? Platform Support for a major defense acquisition program includes: Sparx EA Pro Cloud Server deployment and administration (whether on-premises, NIPR cloud, or classified enclave), DoDAF/UPDM MDG configuration for the specific program requirements, multi-user access control configuration for the program team and contractor community, architecture baseline management at program milestones, ongoing architecture data quality assurance, and program office training. For programs spanning multiple years, Platform Support provides the continuity of expert Sparx EA administration that government program offices typically cannot maintain in-house.
Work With Sparx Services
Major defense acquisition programs require architecture that keeps pace with the program: from JCIDS operational views through Milestone B SV architecture to CDR-level system interfaces. Sparx Services provides Platform Support for large DoDAF programs and Architect Development training for DoDAF specialist architects.
For programs starting their architecture practice, our Deploy engagement establishes the DoDAF/UPDM-configured Sparx EA repository.
Platform Support | Deploy from $30,000 | Architect Development. Contact us to discuss your acquisition program architecture requirements.