DoDAF Explained: An Introduction for Defense Architects Using Sparx EA

A defense architect's job is to give program leaders and reviewers the architecture views they need to make a decision, and to keep those views consistent with the system design. Much of the work is mechanical: building views, keeping them aligned with the SysML model and regenerating them for each review. In AI-augmented work the architect decides the scope and what each view must show, and AI builds and maintains the views in the model. The skill this asks for is knowing DoDAF and the contract well enough to scope the package and to review what comes back. The rest of this article is the reference for that.

What is DoDAF?

DoDAF is the US Department of Defense's standard framework for architecture documentation on defense programs. It was created to give the DoD a consistent language for describing the capabilities, systems, operations, and technologies of a program: so that architecture products from different contractors, programs, and acquisition offices could be understood, compared, and integrated rather than reinvented each time.

DoDAF 2.0 is the current major version. It is the 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.

One distinction trips up newcomers: DoDAF is a framework, not a methodology. It tells you what to document (the model types) and how to organize it (the viewpoints), but not how to develop the architecture. That process is governed by the contractor's systems-engineering process, the program's Systems Engineering Management Plan (SEMP), or a complementary method.

The 8 DoDAF viewpoints

DoDAF 2.0 organizes its models into 8 viewpoints, each addressing a distinct architectural concern:

All Viewpoint (AV), the overarching views that apply across the architecture. AV-1 (Overview and Summary Information) and AV-2 (Integrated Dictionary) are produced for every DoDAF package; AV-2 is the data dictionary that formally defines every term used.

Capability Viewpoint (CV), describes the capabilities the enterprise or system must have, independent of who provides them. 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 appears in almost every program's package; OV-2 and OV-5 are also standard.

Systems Viewpoint (SV), describes the systems that implement operational activities. SV-1 (Systems Interface Description), SV-2 (Systems Resource Flow), and SV-4 (Systems Functionality) are the core systems views. For most modern programs, SysML models supplement or replace the SV-series for system-design detail.

Services Viewpoint (SvcV), the service-oriented analog to the Systems Viewpoint, covering service-oriented and net-centric architectures. 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 interfaces, data formats, security protocols, and other constraints.

Data and Information Viewpoint (DIV), describes the data and information the system uses and produces. DIV-1 (Conceptual Data Model) and DIV-2 (Logical Data Model) are primary, and 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 mainly in enterprise-level packages for portfolio management.

The 10 views that matter most in practice

Across acquisition programs, these ten views account for the majority of DoDAF deliverables that get read, reviewed, and used. In Sparx EA, each maps to specific diagram types, matrix configurations, and document templates in the DoDAF 2.0 MDG profile.

The 10 views that matter most in practice

View	Description	Why it matters
AV-1	Overview and Summary	Required everywhere, sets context for the whole 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	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

DoDAF and SysML in acquisition programs

DoDAF and SysML serve complementary purposes. DoDAF supplies the operational and capability context: why the system exists, what it must do operationally, and which standards it must meet. SysML supplies 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 requirement diagrams trace to DoDAF CV-2 capabilities

Both live in the same Sparx EA repository, with separate top-level packages for DoDAF views and SysML architecture and cross-references maintained via trace relationships. For programs governed by a model-based systems-engineering requirement, SysML is the primary technical notation and DoDAF is the compliance reporting layer: the team develops SysML and generates DoDAF-conformant documents and views from the underlying model.

Scoping DoDAF for your program

The most important DoDAF decision comes before the choice of views: which decisions and stakeholders the architecture is meant to serve. The views follow from that. 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 emphasize different views)
• 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 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, and StdV-1, plus SysML for system design. That is a manageable, decision-useful set. Attempting all 52 models is neither realistic nor useful for any single program phase.

Frequently asked questions

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 and is typically specified in Statements of Work for defense systems-engineering and architecture contracts. Some non-DoD US federal agencies adopt DoDAF-influenced approaches, and NATO allies may use NAF, 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 foundations and overlap heavily in viewpoint structure, and NAF 4.0 aligns more closely with ArchiMate than DoDAF does. 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 for any conformant package. Beyond those, required views are specified in contractual documentation (CDRLs, SOW, Capability Development Document) and vary by program phase and stakeholder needs.

Does Sparx EA support DoDAF 2.0? Yes. Sparx EA supports DoDAF 2.0 through an MDG Technology profile that provides the element types, relationship types, and diagram configurations aligned to DoDAF 2.0. For formal documentation, the 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-, CV-, and mission-level SV-series); SysML provides the system-design architecture (BDD, IBD, requirement diagrams). Both live in one repository with cross-references connecting DoDAF operational activities to SysML use cases and DoDAF SV-1 systems to SysML blocks. For MBSE-required programs, SysML is the technical authority and DoDAF views are generated from or aligned to it.

What is the most common DoDAF implementation mistake? Treating all 52 models as required deliverables and attempting to build them regardless of phase, audience, or contract. The result is a large volume of documentation too unfocused to support any particular decision. Scope DoDAF to what your program needs and build those views well.

DoDAF, SysML, and defense architecture practice

Sparx Services works with defense programs using DoDAF and SysML in Sparx EA on MDG configuration, repository structure, DoDAF view scoping and integration with MBSE requirements. Start with Paralysis to a Plan for an assessment and roadmap, or see how we support MBSE practitioners.