DoDAF Explained: An Introduction for Defense Architects Using Sparx EA
DoDAF (Department of Defense Architecture Framework) is the US DoD standard for architecture documentation. It organizes architecture into 8 viewpoints with 46 model types (views). In practice, no program produces all 46. The art is knowing which views your program actually needs — driven by contract requirements, acquisition phase, and what decisions the architecture is meant to support. Starting with a full DoDAF compliance checklist is the fastest way to produce architecture documentation that nobody reads and that does not support the decisions your program faces.
Key Takeaways
- DoDAF has 8 viewpoints and 46 defined views — no program should attempt all 46
- The 10 most commonly required views account for 80% of DoDAF deliverables in acquisition programs
- Sparx EA supports DoDAF 2.0 natively with a built-in MDG profile
- DoDAF and SysML serve complementary purposes in acquisition programs — DoDAF for operational and capability context; SysML for system design
- Scoping DoDAF to the specific decisions and stakeholders your program faces is the most important DoDAF planning decision
What Is DoDAF?
DoDAF is the US Department of Defense’s standard framework for architecture documentation on defense programs. It was originally developed to give the DoD a consistent language for describing the capabilities, systems, operations, and technologies of defense programs — so that architecture products from different contractors, programs, and acquisition offices could be understood, compared, and integrated.
DoDAF 2.0 is the current major version. It is the architecture documentation standard for programs governed by DoDI 5000.02 (the acquisition policy) and is referenced in most major defense solicitations for systems engineering and architecture work.
DoDAF is a framework, not a methodology. It tells you what to document (the view types) and how to organize it (the viewpoints), but not how to develop the architecture. That process is typically governed by the contractor’s SE process, the program’s Systems Engineering Management Plan (SEMP), or a complementary methodology like the Architecture Analysis Method (AAM).
The 8 DoDAF Viewpoints
DoDAF 2.0 organizes views into 8 viewpoints, each addressing a distinct architectural concern:
All Viewpoint (AV) The overarching views that apply across the entire architecture. AV-1 (Overview and Summary Information) and AV-2 (Integrated Dictionary) are produced for every DoDAF architecture package. AV-2 is the data dictionary — the formal definition of every term used in the architecture.
Capability Viewpoint (CV) Describes the capabilities the enterprise or system must have, independent of any specific organization or system that provides them. CVs are used for capability planning, gap analysis, and investment prioritization. CV-2 (Capability Taxonomy) and CV-4 (Capability Dependencies) are the most commonly requested.
Operational Viewpoint (OV) Describes operational scenarios, activities, and information flows — what happens in operations, not what systems support it. OV-1 (High-Level Operational Concept Graphic) is the most visible DoDAF view and is included in almost every program’s architecture package. OV-2 (Operational Resource Flow Description) and OV-5 (Operational Activity Decomposition) are also standard.
Systems Viewpoint (SV) Describes the systems that implement operational activities. SV-1 (Systems Interface Description), SV-2 (Systems Resource Flow Description), and SV-4 (Systems Functionality Description) are the core systems views. For most modern programs, SysML models supplement or replace SV-series views for system design detail.
Services Viewpoint (SvcV) The service-oriented analogue to the Systems Viewpoint, covering service-oriented architectures and net-centric systems. SvcV-1 (Services Context Description) is used when the program involves service-oriented or API-based integration.
Technical Standards Viewpoint (StdV) Describes the applicable technical standards and guidance. StdV-1 (Technical Standards Profile) is required for most programs — it documents which standards govern the system’s interfaces, data formats, security protocols, and other technical constraints.
Data and Information Viewpoint (DIV) Describes the data and information used and produced by the system. DIV-1 (Conceptual Data Model) and DIV-2 (Logical Data Model) are the primary views. These are increasingly important for programs involving data sharing, AI systems, and information architecture.
Project Viewpoint (PV) Describes the projects and activities that deliver the architecture. PV-1 (Project Portfolio Relationships) and PV-2 (Project Timelines) connect architecture to program management. Used primarily in enterprise-level architecture packages for portfolio management.
The 10 Views That Matter Most in Practice
Across acquisition programs, these 10 views account for the majority of DoDAF deliverables that are actually read, reviewed, and used:
| View | Description | Why It Matters |
|---|---|---|
| AV-1 | Overview and Summary | Required everywhere — sets context for the entire architecture package |
| AV-2 | Integrated Dictionary | The data dictionary — defines every term in the architecture |
| CV-2 | Capability Taxonomy | Capability hierarchy — basis for capability-based planning |
| CV-4 | Capability Dependencies | How capabilities depend on each other — gap analysis input |
| OV-1 | High-Level Operational Concept Graphic | The most-read DoDAF view — operational context in one diagram |
| OV-2 | Operational Resource Flow | Information flows between operational nodes |
| OV-5b | Operational Activity Model | What operations occur and how they relate |
| SV-1 | Systems Interface Description | Which systems exist and how they connect |
| SV-4 | Systems Functionality Description | What functions each system performs |
| StdV-1 | Technical Standards Profile | What technical standards apply |
In Sparx EA, each of these views maps to specific diagram types, matrix configurations, and document templates in the DoDAF 2.0 MDG profile.
DoDAF + SysML for Acquisition Programs
DoDAF and SysML serve different but complementary purposes in acquisition programs. DoDAF provides the operational and capability context — why the system exists, what it must do operationally, and what standards it must meet. SysML provides the system design detail — how the system is structured, how its components interact, and what its behavior is.
The standard integration pattern in Sparx EA:
- DoDAF OV-series views reference system capabilities at the operational level
- SysML Use Case Diagrams align to DoDAF OV-5 operational activities
- SysML BDDs and IBDs elaborate the systems described in DoDAF SV-1
- SysML Requirements Diagrams trace to DoDAF CV-2 capabilities
Both are maintained in the same Sparx EA repository with separate top-level packages for DoDAF views and SysML architecture. Cross-references are maintained via trace relationships between the packages.
For programs governed by a model-based Systems Engineering requirement, SysML is the primary technical architecture notation and DoDAF is the compliance reporting layer. The architecture team develops SysML and generates DoDAF-conformant documents and views from the underlying model.
Scoping DoDAF for Your Program
The most important DoDAF decision is not which views to build — it is what decisions and stakeholders the architecture is meant to serve, and which views support those decisions.
The scoping questions:
- What are the contractual DoDAF requirements? (Statement of Work, CDRL items)
- Which acquisition phase is the program in? (Milestone A/B/C, each has different emphasis)
- Who are the primary audiences? (JCIDS review, DAB review, program office, contractors)
- What decisions will the architecture support? (Capability gap analysis, interface control, technology standards, source selection)
A well-scoped DoDAF architecture package for a typical Milestone B program might include: AV-1, AV-2, CV-2, CV-4, OV-1, OV-2, OV-5b, SV-1, StdV-1 — plus SysML for system design. That is a manageable, decision-useful set. The full 46 views is not a realistic or useful target for any single program phase.
FAQ
What is DoDAF and who has to use it? DoDAF is the US Department of Defense Architecture Framework — the standard for architecture documentation on DoD programs. It is required (or referenced) in programs governed by DoDI 5000.02 (the acquisition policy), and is typically specified in Statements of Work for defense systems engineering and architecture contracts. Non-DoD US federal agencies sometimes adopt DoDAF-influenced approaches, and NATO allies may use NAF (NATO Architecture Framework) which shares DoDAF’s conceptual foundations.
What is the difference between DoDAF and NAF? DoDAF is the US DoD standard. NAF (NATO Architecture Framework) is the NATO standard. They share common conceptual foundations (both derived from earlier frameworks like C4ISR Architecture Framework) and have significant overlap in viewpoint structure. NAF 4.0 is closer aligned to ArchiMate than DoDAF. Multinational programs may require both. Sparx EA supports both via MDG profiles.
Which DoDAF views are required for all programs? AV-1 (Overview and Summary Information) and AV-2 (Integrated Dictionary) are the baseline views required for any DoDAF-conformant architecture package. Beyond these, required views are specified in contractual documentation (CDRLs, SOW, Capability Development Document) and vary by program phase and stakeholder requirements.
Does Sparx EA support DoDAF 2.0? Yes. Sparx EA includes a DoDAF 2.0 MDG profile that supports the standard view types. The MDG profile provides element types, relationship types, and diagram configurations aligned to DoDAF 2.0 view definitions. For programs requiring formal DoDAF documentation, the MDG profile is the starting point — with program-specific customization added for stereotype extensions and controlled value lists.
How does DoDAF combine with SysML for acquisition programs? DoDAF provides the operational and capability architecture (OV-series, CV-series, SV-series at the mission level). SysML provides the system design architecture (BDD, IBD, Requirements Diagram at the engineering level). Both are maintained in the same Sparx EA repository with cross-references connecting DoDAF operational activities to SysML use cases, and DoDAF SV-1 systems to SysML BDD blocks. For MBSE-required programs, SysML is the technical authority; DoDAF views are generated from or aligned to the SysML model.
What is the most common DoDAF implementation mistake? Treating all 46 views as required deliverables and attempting to build them all, regardless of program phase, audience, or contract requirements. The result is a large volume of architecture documentation that is not specific enough to support any particular decision and that program stakeholders do not read. DoDAF compliance is not the goal — decision support is. Scope DoDAF to what your program actually needs and build those views well.
DoDAF, SysML, and Defense Architecture Practice
Sparx Services provides Platform Support and Discover engagements for defense programs using DoDAF and SysML in Sparx EA — MDG configuration, repository structure, DoDAF view scoping, and integration with MBSE requirements.
Learn about the DoDAF framework →
