Table of Contents

Understanding DODAF: The Foundation for OV and SV Diagrams

The Department of Defense Architecture Framework (DODAF) provides a structured methodology for designing, assessing, and communicating complex systems within the defense and aerospace sectors. Established to ensure that architecture descriptions are consistent, reusable, and aligned with stakeholder needs, DODAF is organized into six viewpoints: All Viewpoint (AV), Capability Viewpoint (CV), Operational Viewpoint (OV), Project Viewpoint (PV), Systems Viewpoint (SV), and Standards Viewpoint (StdV). Among these, the OV and SV are the most widely used for linking operational needs to technical system solutions.

The Operational View (OV) describes the operational concepts, activities, tasks, and information flows necessary to accomplish missions. It focuses on what needs to be done, by whom, and with what information. The Systems View (SV) in turn documents the physical and logical systems, their interfaces, and the exchanges that support the operational activities. A critical insight for architects is that the SV must trace directly back to the OV; every system function should exist to satisfy at least one operational activity. This traceability is formalized through matrices such as the Operational Activity to Systems Function Traceability Matrix (SV‑5).

Developing OV and SV diagrams correctly enables stakeholders to understand dependencies, identify capability gaps, evaluate alternatives, and inform acquisition decisions. The following sections provide a deep dive into the products within each view and a practical, step‑by‑step methodology for building them.

The Operational View (OV) in Depth

DODAF defines seven standard OV products, each serving a distinct purpose. While not every project requires all products, a mature architecture typically includes at least OV‑1, OV‑2, OV‑5, and OV‑6.

OV‑1: High‑Level Operational Concept Graphic

The OV‑1 is a pictorial representation of the operational concept. It shows the main operational nodes (e.g., headquarters, sensor platforms, command centers), their geographic or logical arrangement, and the high‑level information exchanges. Primary stakeholders—senior decision‑makers and non‑technical sponsors—use OV‑1 to quickly grasp mission scope and the roles of participating entities. A well‑constructed OV‑1 uses clear icons, labels, and a context narrative to tell the operational story without requiring deep technical knowledge.

OV‑2: Operational Resource Flow Description

OV‑2 adds detailed information flows between operational nodes. It identifies the specific resources (information, materiel, personnel) that flow across interfaces. For each flow, the architect documents the producer and consumer nodes, the frequency, and the nature of the resource (e.g., sensor data, logistics orders, situational awareness reports). This product becomes the foundation for later SV‑1 and SV‑2 diagrams, ensuring that system interfaces implement exactly the required operational exchanges.

OV‑3: Operational Resource Flow Matrix

OV‑3 is a tabular representation of the information contained in OV‑2. It lists every resource flow row‑by‑row, specifying source, destination, data format, quality attributes, and security classification. This matrix supports detailed analysis such as data‑flow balancing, throughput calculations, and security classification audits.

OV‑4: Organizational Relationships Chart

OV‑4 depicts the command structure, relationships, and lines of authority among the operational nodes. It answers: who is in charge, who reports to whom, and what coordination mechanisms exist? The chart can be hierarchical (organizational breakdown) or more dynamic (liaison relations, task‑organized teams).

OV‑5a and OV‑5b: Operational Activity Models

OV‑5a (Operational Activity Decomposition Tree) breaks down the top‑level mission into lower‑level activities. OV‑5b (Operational Activity Model) shows the sequence, inputs/outputs, and performers of each activity. Together they describe the functional behavior of the operation. When developing OV‑5, use standard action‑oriented language (noun‑verb pairs) and ensure that each activity can be linked to at least one system function later in the SV.

OV‑6a, OV‑6b, OV‑6c: Operational Rules, State Transitions, and Event‑Trace Models

OV‑6 products capture behavioural constraints and dynamics. OV‑6a documents business rules and operational constraints (e.g., “If aircraft approaches within 10 nautical miles, issue warning”). OV‑6b (State Transition Description) models the possible states of operational nodes and allowed transitions. OV‑6c (Event‑Trace Description) uses sequence diagrams to show time‑ordered exchanges between nodes. These models are essential for validating operational logic and for specifying system behaviour in the SV‑10 series.

The Systems View (SV) in Depth

The Systems View comprises at least ten products, from SV‑1 through SV‑10c. The SV must demonstrate how systems realize the operational activities and resource flows defined in the OV.

SV‑1: Systems Interface Description

SV‑1 is the structural backbone of the system architecture. It depicts systems (hardware, software, databases) as nodes and shows the logical and physical interfaces between them. Each interface is labeled with the resources that flow across it, which should correspond to resource flows documented in OV‑2. Architects use SV‑1 to identify missing interfaces, single points of failure, and unnecessary redundancy.

SV‑2: Systems Resource Flow Description

SV‑2 adds additional detail to each interface shown in SV‑1. It specifies protocol stacks, data‑link types, bandwidth, and quality of service attributes. For example, an interface between a ground control system and a UAV might be described as “Link 16, 1 Mbps, encrypted, with 200 ms maximum latency”. This product feeds directly into systems engineering trade studies and interoperability assessments.

SV‑3: Systems‑Systems Matrix

SV‑3 is a matrix that shows which pairs of systems have interfaces, and optionally the nature of those interfaces (e.g., two‑way, one‑way, radio frequency, wired). The matrix helps architects quickly identify interface gaps or excessive coupling.

SV‑4: Systems Functionality Description

SV‑4 decomposes each system into its functions. Unlike OV‑5 which focused on operational activities, SV‑4 focuses on what the system does: e.g., “compute fire‑control solution”, “manoeuvre sensor”, “maintain link”. Functions in SV‑4 should be traceable to activities in OV‑5 via SV‑5.

SV‑5: Operational Activity to Systems Function Traceability Matrix

SV‑5 is one of the most critical products for consistency. It maps each operational activity in OV‑5a to one or more system functions in SV‑4. A complete SV‑5 ensures every operational need is satisfied by some system capability. Gaps indicate that a required function is missing from the system design. Redundant mappings may suggest opportunities for consolidation.

SV‑6: Systems Resource Flow Matrix

SV‑6 is the systems‑oriented counterpart of OV‑3. It lists all resource flows between systems, tying each to the interfaces defined in SV‑1. Maintain consistency: every flow in OV‑3 that is automated should have a corresponding flow in SV‑6.

SV‑7: Systems Measures Matrix

SV‑7 documents performance parameters such as throughput, reliability, latency, processing speed, and capacity. These measures are linked to system functions and enable quantitative trade‑offs. For instance, a radar function may have a measure of “detection range: 500 km at 90% probability”. Alignment with stakeholder‑defined performance objectives is a key analysis activity.

SV‑10a, SV‑10b, SV‑10c: Systems Rules, State Transitions, and Event‑Trace Models

These products mirror OV‑6 but at the system level. SV‑10a defines system‑level business rules or constraints. SV‑10b models the state machines for each system or function. SV‑10c uses sequence diagrams to illustrate time‑ordered message exchanges between system interfaces. Together they validate that the collective system behaviour satisfies the operational dynamics described in OV‑6.

A Step‑by‑Step Methodology for Developing OV and SV Diagrams

The following method blends top‑down decomposition with stakeholder‑driven refinement. It is designed to produce consistent, validated diagrams that support both analysis and communication.

Step 1: Define the Purpose and Scope

Before drawing any diagram, answer three questions: What is the mission or problem that the architecture addresses? What is the intended use of the architecture (e.g., acquisition support, gap analysis, interoperability evaluation)? What are the boundaries—organizational, geographic, temporal? Define these in the Architecture Description (AV‑1). This prevents scope creep and ensures that later diagrams remain focused.

Step 2: Identify Stakeholders and Their Concerns

Stakeholders include operational commanders, system engineers, program managers, and acquisition officials. Each has specific concerns: commanders need to see operational flexibility; engineers require detailed interface definitions; managers want risk and cost implications. Document these concerns and map them to the OV and SV products that address them. This mapping becomes the basis for your diagram selection.

Step 3: Build the High‑Level Operational Concept (OV‑1)

Create the OV‑1 graphic using a simple drawing tool or a model‑based environment. Place the primary operational nodes (e.g., Joint Task Force, Surface Ship, Unmanned Aerial Vehicle, Satellite) and show the high‑level information exchanges. Add a textual description that captures the operational scenario. Review with operational stakeholders to validate the narrative. The OV‑1 is often revised multiple times as later steps reveal missing elements.

Step 4: Model Operational Activities and Resource Flows (OV‑2, OV‑5a/b)

Using the OV‑1 as a skeleton, decompose each operational node into its activities using a functional decomposition (OV‑5a). For each activity, determine inputs and outputs. Then add the resource flows between nodes in OV‑2. For example, if the activity “Formulate Response” in one node produces a “Response Plan”, that plan must flow to another node. Document each flow’s characteristics (frequency, data volume, security). Validate these flows with subject matter experts.

Step 5: Define Organizational Relationships (OV‑4)

Add the authority and reporting lines among nodes. This can be straightforward (hierarchy) or complex (coalition partners with shared command). OV‑4 helps to identify which nodes are authorized to request or receive which resources—information often critical for access control rules in SV‑10a.

Step 6: Establish Behavioural Models (OV‑6)

For critical operational threads, create state diagrams (OV‑6b) and sequence diagrams (OV‑6c). For example, a “not ready” state may transition to “ready” after receiving an authorization message. The sequence diagram can show the exact messages between nodes over time, including conditions and exceptions. These models are the formal specification of operations and will be directly used to drive system design.

Step 7: Develop Systems Interface Descriptions (SV‑1)

Now shift to the system domain. Identify the systems that implement the operational nodes. For each operational node, list the systems or system components (e.g., C2 software suite, radio, server). Draw the systems as nodes in SV‑1 and connect them with interfaces that correspond to the operational resource flows in OV‑2. Label each interface with its implementing system(s) and the resources it carries. At this step, you may discover that a single operational flow must be split across multiple system interfaces (e.g., voice and data sent over separate links).

Step 8: Detail Systems Functionality and Traceability (SV‑4, SV‑5)

Decompose each system into its functions (SV‑4). For example, the “Ground Control Station” system may include functions such as “Receive Telemetry”, “Update Track Database”, and “Transmit Commands”. Then create the SV‑5 matrix by linking each SV‑4 function to one or more OV‑5 activities. This step is where traceability gaps become evident. If a required operational activity has no supporting system function, you must either add a function or argue that the activity is manual. Conduct this review with both operations and engineering stakeholders.

Step 9: Model Systems Resource Flows and Dynamics (SV‑2, SV‑10)

Refine each interface in SV‑1 with detailed technical attributes in SV‑2 (protocol, security, performance). Then develop system‑level state and sequence models (SV‑10b/c) that mirror the operational behaviours from OV‑6. For example, the same sequence diagram from OV‑6c should now be extended at the system level, showing message names, data formats, and timing requirements. The SV‑10a rules can document system constraints such as “reception of invalid data shall not cause a system failure”.

Step 10: Validate, Refine, and Manage Configuration

Hold review sessions with the original stakeholders and additional subject matter experts. Walk through the OV and SV products in order, starting with OV‑1, and confirm that every OV element is addressed in the SV, and that the SV solution is feasible and compliant with standards (StdV). Use that feedback to update diagrams, and then baseline the architecture. Once baselined, implement version control using a model‑based configuration system. Any changes to operational requirements must propagate through to the SV products; use SV‑5 as the primary traceability anchor.

Best Practices and Common Pitfalls

Best Practices

  • Use a model‑based tool. Tools like Cameo Systems Modeler, MagicDraw, or Sparx Enterprise Architect with UPDM/UAF profiles enforce consistency, enable automated report generation (including matrices), and facilitate traceability across OV and SV products.
  • Maintain a standard notation. The Unified Profile for DoDAF/MODAF (UPDM) or the Unified Architecture Framework (UAF) provides standard stereotypes and diagram types. This improves communication between teams and reduces misinterpretation.
  • Start with the operational need. Even experienced system engineers should resist jumping directly to SV diagrams without a solid OV foundation. OV‑5 and OV‑2 are the most valuable starting points.
  • Keep diagrams useful, not complete. It is better to have a well‑organized set of five OV products that are reviewed and accurate than to generate all 30 standard products with minimal quality. Tailor the product set to stakeholder concerns.
  • Document assumptions and decisions. Every diagram should be accompanied by a narrative that explains why a certain flow exists, why a function is assigned to a particular system, and what assumptions were made about the operational environment.

Common Pitfalls

  • Ignoring cross‑view consistency. The most frequent problem in DODAF architectures is orphan functions or flows. A system function in SV‑4 that has no parent operational activity in OV‑5 is a waste, while an operational activity with no traced function indicates an incomplete system design. Use automated validation rules in your modeling tool to detect these issues.
  • Overcomplicating OV‑1. Some teams try to pack too much detail into the high‑level concept graphic, making it unreadable. Keep OV‑1 to one page; use OV‑2 and OV‑5 for detail.
  • Neglecting performance measures (SV‑7). Many projects define interfaces and functions but never attach measures. Without SV‑7, it is impossible to evaluate whether the system will meet operational requirements.
  • Creating diagrams in isolation. If the OV team and SV team do not regularly synchronize, the SV will drift from the operational reality. Joint reviews at each step are essential.
  • Using the wrong level of granularity. Too coarse a decomposition misses key details; too fine a decomposition makes the architecture unwieldy. A good rule of thumb: each activity or function should represent a single, cohesive behavior that can be assigned to a single performing node or system.

Tools and Techniques for DODAF Diagram Development

While it is possible to create DODAF diagrams with generic drawing tools (e.g., Microsoft Visio), the complexity of traceability and cross‑referencing makes model‑based tools strongly recommended. The following tools support DODAF 2.02 and UAF:

  • Dassault Systèmes Cameo Systems Modeler (formerly MagicDraw) – widely used in defense programs, supports UPDM/UAF, provides automated matrix generation (SV‑3, SV‑5, OV‑3), and can generate web‑based architecture reports.
  • Sparx Systems Enterprise Architect – offers a mature UAF add‑in, supports profile‑based modeling, and has a lower cost point suitable for smaller teams.
  • IBM Engineering Rhapsody – strong in systems engineering with SysML support and can be configured for DODAF viewpoints.

When choosing a tool, evaluate its ability to enforce traceability, generate SV‑5 matrices, handle version control, and export to standard formats (e.g., HTML, XMI, PDF). Regardless of tool, the key technique is to define the meta‑model early: what are the types of nodes, flows, and functions you will use; what relationships (assignment, trace, interface) are allowed; and what attributes will be captured. This upfront effort significantly reduces rework.

For teams new to DODAF, consider starting with a pilot project using only OV‑1, OV‑2, OV‑5, SV‑1, and SV‑5. Master these before adding behavioural and dynamic models.

Conclusion

Developing DODAF OV and SV diagrams is a systematic process that bridges operational requirements with technical system design. By following a structured methodology—from defining scope and building operational models, to tracing system functions and validating with stakeholders—architects produce diagrams that are accurate, comprehensive, and actionable. The effort invested in creating high‑quality OV and SV products pays dividends during system acquisition, integration, and lifecycle management. Decision‑makers gain a clear understanding of how systems support the mission, and engineers have a precise specification to guide development. For defense organizations and system integrators, mastering OV and SV development is an essential competency for delivering successful, interoperable capabilities.

For further reading, refer to the official DoD Architecture Framework site, the Unified Architecture Framework (UAF) specification, and the SEI’s guidance on DODAF architecture development.