Direct Answer: Sparx EA supports DoDAF 2.0, MODAF, and NAF 4.0 natively via built-in MDG profiles. Defense and government architecture teams use these frameworks for capability planning, systems integration, and acquisition support: and Sparx EA is one of the most widely deployed tools for that work. The choice between DoDAF, MODAF, and NAF is driven by organizational mandate, not tool capability: DoDAF for US organizations, MODAF for legacy UK MOD programs (now largely superseded), NAF 4.0 for NATO and aligned nations. If you are operating in a defense context and not running Sparx EA with a properly configured MDG profile and a governed repository structure, your architecture data is not providing the analysis value your stakeholders are paying for.
Key Takeaways:
DoDAF 2.0 organizes architecture views into eight viewpoints. Each viewpoint addresses a different architectural concern. The table below maps viewpoints to their views, purpose, and primary Sparx EA artifacts.
| Viewpoint | Views | Purpose | Primary EA Artifacts |
|---|---|---|---|
| All Viewpoint (AV) | AV-1, AV-2 | Overview and integrated data dictionary | Project overview element; Data dictionary package |
| Capability (CV) | CV-1 through CV-7 | Capability taxonomy, dependencies, and roadmap | Capability elements; Roadmap timeline diagrams |
| Operational (OV) | OV-1 through OV-6c | Operational concepts, activities, and information flows | Activity diagrams; Operational node elements; Information exchange elements |
| Systems (SV) | SV-1 through SV-11 | Systems and their interconnections and functions | Component elements; Interface elements; System function elements |
| Services (SvcV) | SvcV-1 through SvcV-10 | Service-oriented architecture and service interactions | Service elements; SOA diagrams; Service function elements |
| Technical Standards (StdV) | StdV-1, StdV-2 | Standards applicable to the architecture and forecast | Standards catalog elements; Standards roadmap |
| Data and Information (DIV) | DIV-1 through DIV-3 | Conceptual, logical, and physical data architecture | Data entity elements; Class diagrams; Data schema elements |
| Project (PV) | PV-1 through PV-3 | Project portfolio, timelines, and relationships | Project elements; Milestone elements; Gantt-style timeline views |
Not all views are required for every program. DoDAF guidance specifies that view selection is driven by the architecture’s intended use: an acquisition architecture for a specific system will require different views than a strategic capability planning exercise. The common mistake in defense EA programs is producing all views because the framework defines them, rather than producing the views that address the program’s actual analytical needs.
The AV-2 is the integrated dictionary: it defines the terms used across all other views. In Sparx EA, this is typically implemented as a glossary package with consistent element definitions cross-referenced by other packages. Teams that skip the AV-2 early in a program pay for it later when different architects use the same terms to mean different things across views.
The OV-1 is the one view most stakeholders actually read. It is a graphical depiction of the operational context: systems, actors, and their interactions in the operational environment. In Sparx EA, this is typically a custom diagram with iconic representations of nodes and information flows. The OV-1 is your architecture’s cover page. Invest accordingly.
MODAF (Ministry of Defense Architecture Framework) was the UK MOD’s adaptation of DoDAF. It was broadly parallel in structure: operational, systems, service, and technical viewpoints with UK-specific adaptations. MODAF was a significant framework in its time and many existing UK defense programs still have MODAF-based architecture repositories.
NAF 4.0 (NATO Architecture Framework, version 4) superseded MODAF for UK MOD use and became the mandated framework for NATO and allied nations. NAF 4.0 is structurally different from MODAF: it uses a grid-based architecture where aspects (lines) cross with eight nature categories (columns) to define views. The NAF grid is more systematic than the DoDAF/MODAF viewpoint approach and is designed to support model-based architecture: not just documentation.
The eight NAF aspects: Concepts, Service, Operational, Systems/Technical, Personnel, Standards, Program, and Enterprise.
In all cases, verify the specific views required by your program’s architecture documentation requirements (ADR) or contract. Framework selection is a contract compliance matter, not a tool preference.
The most common Sparx EA configuration for defense acquisition programs combines DoDAF (or NAF) with SysML in a single repository. This is not a workaround: it is the intended pattern for programs that need both capability/operational architecture and systems engineering models.
Both the DoDAF MDG profile and the SysML MDG profile must be active in the same repository. Neither should override the other. Toolbox configuration should give each user community access to the element types relevant to their work: systems engineers should not be navigating through DoDAF toolboxes, and capability planners should not be confronted with SysML parametric diagram options.
Package structure matters: DoDAF views and SysML models should be in separate package hierarchies with cross-package traceability links. Mixing them in the same package tree creates navigation problems and access control headaches.
The primary integration value: operational requirement traceability. An OV-6c operational activity defines what the system must do. An SysML system requirement (in the REQ diagram) captures the derived technical requirement. A SysML block satisfies that requirement. An SysML test case verifies it. The full chain: from operational need to verified capability: lives in a single Sparx EA repository that any authorized team member can navigate.
Defense organizations operate under data governance frameworks: data classification levels, accreditation requirements, network isolation mandates: that create specific constraints for AI integration with EA repositories. The standard commercial AI API approach (sending data to a cloud service for processing) is typically not acceptable for architectures containing classified or controlled information.
EA GraphLink integration in defense contexts typically requires Azure OpenAI deployment, where the AI model runs within an Azure government cloud tenancy (or national sovereign cloud equivalent) and data does not leave the accredited environment. Azure OpenAI’s FedRAMP High and CMMC-aligned deployment options address the US federal compliance requirements. UK and NATO programs have equivalent options via Azure UK Government and similar sovereign cloud infrastructure.
The implication: EA GraphLink deployment for a defense architecture team is not a default configuration. It is a deliberate deployment decision that requires data classification review, network architecture planning, and alignment with the organization’s accreditation boundary.
Before any EA repository content is exposed via MCP (Model Context Protocol) to AI tools: whether Cursor, Claude Code, or other AI-assisted development environments: a classification review is required. Not all architecture data is equally sensitive. An OV-1 operational concept diagram and a DIV-3 physical data model for a classified communications system have distinct handling requirements.
The practical approach: identify which packages or views are candidates for AI-assisted analysis, verify their classification level, and configure EA GraphLink to expose only the approved scope. This is an architecture decision, not a configuration afterthought.
Defense programs using Sparx EA’s Pro Cloud Server for team collaboration may operate in network-isolated environments where internet connectivity is restricted or absent. EA GraphLink deployment in these environments requires on-premises or private cloud AI model hosting. Azure OpenAI supports private endpoint configurations that satisfy most network isolation requirements. Sparx Services has experience designing these deployments: they are not standard but they are achievable.
What is the difference between DoDAF, MODAF, and NAF?
DoDAF (Department of Defense Architecture Framework) is the US military and federal government standard for architecture documentation. MODAF (Ministry of Defense Architecture Framework) was the UK equivalent, broadly parallel to DoDAF in structure. NAF 4.0 (NATO Architecture Framework) superseded MODAF for UK MOD and NATO contexts, introducing a grid-based view structure that is more systematic and better suited to model-based architecture. All three are supported by Sparx EA’s built-in MDG profiles. Your choice is determined by your customer’s mandate, not by tool capability.
Which DoDAF views are required for all programs?
No views are universally required: DoDAF guidance specifies that view selection is driven by the architecture’s intended use and the stakeholder questions it must answer. In practice, the AV-1 (overview), AV-2 (integrated dictionary), and OV-1 (high-level operational concept) are produced for almost every defense architecture. Beyond that, required views are specified in your program’s Architecture Documentation Requirements (ADR) or equivalent contract deliverable specification. Producing views that nobody will use is a common waste in defense EA programs.
Does Sparx EA support DoDAF 2.0 out of the box?
Yes. Sparx EA includes a built-in MDG profile for DoDAF 2.0 that provides the element types, stereotypes, and diagram types required for DoDAF view production. You do not need a third-party add-on. However, the built-in profile gives you the notation: it does not give you a governed repository structure, consistent naming conventions, or program-specific extensions. Those require MDG customization.
How do I create a DoDAF AV-2 Integrated Dictionary in Sparx EA?
The AV-2 is implemented in Sparx EA as a glossary or data dictionary package containing element definitions with consistent attributes. The most effective approach: create a dedicated package for the AV-2, define each term as an element with a description, source, and associated views, and cross-reference those elements from the packages where they are used. Sparx EA’s built-in glossary feature can also be used, though for large programs a structured package approach gives better control and report generation options.
Can I use DoDAF and SysML in the same Sparx EA repository?
Yes, and for acquisition programs this is the standard pattern. Both MDG profiles can be active simultaneously. Package structure and toolbox configuration should separate the two modeling worlds so each user community has a clear working environment. Traceability links between DoDAF operational elements and SysML system elements are the analytical value of the combined repository.
What is NAF 4.0 and when should I use it instead of DoDAF?
NAF 4.0 is the NATO Architecture Framework, version 4, published by NATO and adopted by UK MOD for new programs. It uses a grid-based structure where eight architectural aspects (Concepts, Service, Operational, Systems/Technical, Personnel, Standards, Program, Enterprise) are the organizing principle. Use NAF if your program is NATO-mandated, UK MOD-mandated for new programs, or if you are working in a multinational defense context where NATO interoperability documentation is required. Use DoDAF if your customer is US federal or US military.
How do I generate DoDAF view reports from Sparx EA?
Sparx EA supports report generation from DoDAF models via its built-in document template system and the RTF/DOCX report generator. Specific view reports: an OV-5a activity table, an SV-1 systems interface description: require templates that query the repository for the relevant element types and relationships. Some templates are available from the Sparx community; program-specific report requirements typically need custom templates. The investment in quality report templates pays off over a multi-year program where the same views are regenerated repeatedly for reviews.
What MDG configuration is needed for DoDAF beyond the built-in profile?
The built-in DoDAF MDG handles notation. Program-specific extensions typically include: required attributes for specific element types (confidence level for capability elements, data classification for information elements, approval status for views), naming conventions enforced by validation scripts, custom toolbox configurations that expose only the element types relevant to each user role, and cross-reference conventions for traceability links. The scope of customization should be proportional to your program’s size and lifecycle length.
How does data classification affect EA repository AI integration in defense contexts?
Any AI integration that involves sending repository content to an AI model requires that content to be handled at an appropriate classification level. For unclassified architecture content, commercial Azure OpenAI meets standard requirements. For controlled unclassified information (CUI) or classified content, the AI model must operate within an accredited environment: typically Azure Government Cloud or an on-premises deployment. A data classification review scoping which repository content is eligible for AI-assisted analysis is a prerequisite for any defense EA AI integration. This is not optional compliance overhead: it is fundamental to avoiding security incidents.
Can EA GraphLink work with defense architecture data?
Yes, but deployment must be configured for your security context. EA GraphLink’s MCP-based approach to repository intelligence is compatible with Azure OpenAI private endpoint configurations that keep data within your cloud tenancy. The capability is real; the deployment configuration for a defense context is more complex than a commercial deployment and requires explicit planning. Sparx Services has designed these configurations and can scope the deployment requirements for your environment.
Defense architecture programs operate under constraints: data governance, acquisition timelines, stakeholder review cycles: that generic EA consulting does not account for. Sparx Services brings Sparx EA expertise to programs that need more than a training course or a vendor helpdesk.
Platform Support provides ongoing Sparx EA expertise for defense architecture teams: MDG governance, Pro Cloud Server configuration for secure environments, repository health, and AI integration planning that accounts for your data classification requirements.
Discover is the right entry point for programs assessing their current repository state and AI readiness. An MDG readiness assessment tells you specifically what your governance gaps are and what they mean for acquisition reporting and AI integration.
Learn more about how SysML and MBSE integrate with defense architecture frameworks in Sparx EA: SysML and MBSE in Sparx EA
Talk to Sparx Services about your defense architecture program
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.