Sparx EA is the primary delivery tool for NAFv4 architecture programs: supporting NATO’s ISO-aligned viewpoint structure, the MODEM meta-model, and the full range of NATO architecture diagram types through a purpose-built NAFv4 MDG extension that configures the tool for NATO program requirements from day one.
The NATO Architecture Framework version 4 (NAFv4) is the architecture framework required for NATO programs, UK MoD projects subject to the 2024 Defense Architecture Framework update, and interoperability work requiring STANAG 7085 compliance. Built on DODAF principles but aligned to ISO/IEC/IEEE 42010 as its meta-standard, NAFv4 represents the current state of practice in defense architecture. Sparx EA’s NAFv4 MDG extension configures the tool to produce NAFv4-compliant architecture artifacts: viewpoints, views, and the MODEM (Meta Object model for Defense) element types: making it the practical choice for defense architecture teams working on NATO programs. This guide explains NAFv4’s structure, how Sparx EA implements it, when NAFv4 is required rather than DoDAF, and what configuration is needed to stand up a NAFv4-capable Sparx EA environment.
Key Takeaways
- NAFv4 is built on ISO/IEC/IEEE 42010 (the international standard for architecture description) and the MODEM meta-model: distinguishing it from DoDAF’s older structural approach.
- NAFv4 defines seven viewpoint grids: Concepts (C), Service (S), Operational (O), Systems (Sy), Technical (Tr), Program (P), and Architecture (A).
- Sparx EA’s NAFv4 MDG extension provides MODEM-aligned element types, NAFv4 diagram types, and a package structure appropriate for NATO programs.
- NAFv4 is required for NATO programs, UK MoD projects under the 2024 Defense Architecture Framework, and STANAG 7085 compliance requirements.
- The key difference from DoDAF: NAFv4 uses a viewpoint-based framework aligned to ISO 42010, while DoDAF uses a product-based framework: both are supported in Sparx EA’s UPDM plug-in.
What NAFv4 Is: and Where It Fits
NAFv4 was developed by NATO under the leadership of the NATO C3 Board, building on the NATO Architecture Framework (NAF) which itself drew from the US DoDAF and UK MoD Architecture Framework (MODAF). The version 4 rewrite was significant: rather than simply iterating on the product-based structure of earlier NAF versions and DoDAF, NAFv4 adopted ISO/IEC/IEEE 42010 (Systems and Software Engineering: Architecture Description) as its meta-standard. This alignment to an international ISO standard gives NAFv4 a more rigorous theoretical foundation and better interoperability with ISO-aligned architecture frameworks used in civil sectors.
ISO/IEC/IEEE 42010 defines the concepts of Architecture Description, Viewpoint, View, and Correspondence: the formal vocabulary that NAFv4 uses to describe and organize architecture. An Architecture Description contains a set of Views, each produced according to a Viewpoint. Viewpoints specify the concerns, the stakeholders who hold those concerns, and the types of models used to address them. Correspondences define the relationships between elements across different views.
MODEM (Meta Object Model for Defense) is the NAFv4 meta-model: the ontology of element types that can appear in a NAFv4 architecture. MODEM is expressed in OWL (Web Ontology Language) and provides a rigorous formal definition of the entities, relationships, and attributes used in NAFv4 architecture. Key MODEM entity types include: ArchitecturalDescription, Capability, EnvironmentalFactor, Functionality, ImplementedCapability, IndividualOrganisation, LocationWhole, NaturalResource, Node, Performer, Phase, Post, Protocol, Resource, Service, ServiceInterface, and many more.
NAFv4 Viewpoints
NAFv4 organizes its views into seven viewpoint grids, each addressing a different set of concerns:
Concepts (C) Viewpoints: Address the overarching concepts and constraints of the architecture. C1 (Capability Taxonomy) defines the capabilities relevant to the architecture. C2 (Enterprise Vision) describes the high-level strategic intent. C3 (Capability Dependencies) shows how capabilities depend on each other. C4 (Standard Relationships) documents the standards and doctrine applicable. C7 (Performance) defines capability performance criteria.
Service (S) Viewpoints: Address the service-oriented aspects of the architecture: what services are provided and consumed. S1 (Service Taxonomy) classifies services. S3 (Service Interfaces) documents service interfaces. S4 (Service Functions) describes what each service does. S8 (Service Policy) documents service behavior rules.
Operational (O) Viewpoints: The workhorses of NAFv4: describing operational scenarios, information flows, and the operational activities of the architecture. O1 (High-Level Operational Concept) provides the narrative operational description. O2 (Operational Scenario) describes time-ordered sequences of events. O3 (Operational Activity) models the activities and information exchanges. O4 (Organisational Relationships) shows command and organisational structures. O5 (Operational Activity to Service Traceability) links operational activities to the services that support them. O6 (Operational Connectivity) documents operational nodes and their connections.
Systems (Sy) Viewpoints: Address the systems that implement the operational and service architecture. Sy1 (System Interface Description) documents system interfaces. Sy2 (Systems Communication Description) shows system communication paths. Sy3 (Systems Data Exchange) documents data exchanges between systems. Sy4 (Systems Functionality) describes system functions.
Technical (Tr) Viewpoints: Document the technology standards and implementation constraints. Tr1 (Technical Standards Profile) catalogs applicable technical standards. Tr2 (Technical Standards Forecast) shows how standards are expected to evolve.
Program (P) Viewpoints: Address the program management aspects: projects, milestones, and resource allocation. P1 (Program Portfolio Relationships) shows relationships between programs and capabilities. P2 (Program Timelines) documents program schedules. P3 (Project Dependencies) shows project interdependencies.
Architecture (A) Viewpoints: The meta-level views that describe the architecture framework itself: how the architecture is structured, who the stakeholders are, and what concerns the architecture addresses. A1 (Meta-data Definition) documents the architecture framework. A2 (Architecture Products) inventories the architecture artifacts. A8 (Lexicon) defines terms.
Sparx EA NAFv4 Configuration
Sparx EA supports NAFv4 through its UPDM (Unified Profile for DoDAF and MODAF) plug-in, which has been extended to include NAFv4 diagram types and MODEM-aligned element stereotypes. The NAFv4 MDG provides:
MODEM Element Stereotypes: Sparx EA’s UML and SysML element types are extended with MODEM stereotypes. A MODEM Capability element is modeled as a UML Class with the «Capability» stereotype from the NAFv4 MDG. A MODEM Node is a UML Class with the «Node» stereotype. MODEM IndividualOrganisation is a UML Class with the corresponding stereotype. Each stereotype carries the MODEM-defined attributes as tagged values.
NAFv4 Diagram Types: The MDG toolbox presents NAFv4 view types as diagram type templates. When an architect creates a new diagram, the NAFv4 view types (C1, O3, Sy1, Tr1, etc.) are available as diagram templates with the appropriate diagram frame, notation conventions, and element palette for that view type.
Package Structure: A NAFv4 program repository follows a standard package structure:
“ NAFv4 Architecture Repository ├── A-Views (Architecture Meta) │ ├── A1 Meta-data Definition │ └── A2 Architecture Products ├── C-Views (Concepts) │ ├── C1 Capability Taxonomy │ ├── C2 Enterprise Vision │ └── C3 Capability Dependencies ├── O-Views (Operational) │ ├── O1 High-Level Operational Concept │ ├── O2 Operational Scenarios │ └── O3 Operational Activities ├── S-Views (Service) ├── Sy-Views (Systems) ├── Tr-Views (Technical) ├── P-Views (Program) └── Common Data ├── Capabilities Registry ├── Nodes Registry ├── Services Registry └── Organizations Registry “
The Common Data packages hold the canonical element definitions that are reused across views: a Capability defined once in the Capabilities Registry is referenced in C1, O5, Sy views, and P1. This reuse-through-reference approach, enforced by Sparx EA’s element relationship model, is the MODEM-aligned approach to architecture data integrity.
Correspondences: ISO 42010 Correspondences: relationships between elements across different views: are modeled in Sparx EA as directed relationships with a «NAFv4 Correspondence» stereotype. Correspondences between Operational Activities (O3) and Services (S4) are particularly important: they trace the operational requirement to the service that satisfies it.
When NAFv4 Is Required
NAFv4 is the required framework in three principal contexts:
NATO Programs: Any program procured through NATO (ACT: Allied Command Transformation, NCIA: NATO Communications and Information Agency, or national contributions to NATO capability targets) must produce architecture artifacts in NAFv4. The NATO Architecture Capability Statement (ACS) process and the Federated Mission Network (FMN) spiral requirements both mandate NAFv4.
UK MoD Projects: The UK Ministry of Defense 2024 Defense Architecture Framework (DAF) adopts NAFv4 as the preferred framework for UK defense architecture, replacing the older MODAF. UK defense contractors, primes, and system integrators working on MoD programs under the 2024 DAF must produce NAFv4-compliant architecture.
STANAG 7085 Compliance: NATO Standardization Agreement 7085 (Interoperability Requirements for NATO Communications and Information Systems) requires architecture documentation in NAFv4. Platforms and systems seeking STANAG 7085 compliance must produce the relevant NAFv4 views, particularly in the Sy (Systems) and Tr (Technical) viewpoints.
NAFv4 vs DoDAF: Choosing the Right Framework
For defense architects working across NATO and US programs, the choice between NAFv4 and DoDAF (or UPDM, which harmonizes them) is driven by customer requirements. Key differences:
Structural approach: DoDAF is product-based (defining specific Architecture Data products: OV-1, SV-1, etc.). NAFv4 is viewpoint-based (following ISO 42010, defining viewpoints and the concerns they address). The viewpoint-based approach is more flexible but requires more interpretation by the architect.
Meta-model: DoDAF uses the DoDAF Meta-Model (DM2). NAFv4 uses MODEM, which is expressed in OWL and is formally more rigorous. MODEM and DM2 have significant overlap: most core concepts exist in both.
Standards alignment: NAFv4 is ISO-aligned (ISO/IEC/IEEE 42010). DoDAF is a US DoD standard, not an ISO standard. For programs with European nations or NATO partners, ISO alignment is preferred.
Practical guidance: DoDAF has more extensive architect guidance and case study material (due to its longer history and larger US defense market). NAFv4 architect guidance has improved significantly with NAFv4 but is less extensive.
In Sparx EA, both frameworks are supported through the UPDM plug-in. A UPDM installation includes both DoDAF and NAFv4/MODAF diagram types and stereotypes, allowing architects to produce views in either framework: or to cross-reference between frameworks on programs that span NATO and US customer requirements.
FAQ
Q1: Does Sparx EA ship with NAFv4 support out of the box? NAFv4 support in Sparx EA is provided through the UPDM (Unified Profile for DoDAF and MODAF) MDG plug-in, available from Sparx Systems. The UPDM plug-in is not included in the base Sparx EA installation: it must be separately installed and licensed. Sparx Services configures the UPDM plug-in alongside NAFv4-specific MDG customisations (MODEM attribute completeness, program-specific stereotypes) as part of the Deploy engagement.
Q2: Is MODEM required for all NAFv4 architecture work, or is it optional? MODEM is the normative data model for NAFv4: it defines the element types and their relationships. For formal NAFv4 architecture submissions (NATO program boards, MoD architecture reviews), MODEM alignment is required. In practice, architecture teams often work at a level of abstraction that does not require full MODEM ontological precision: the view types and their conventions are more important than strict MODEM OWL compliance. Sparx EA’s NAFv4 MDG provides sufficient MODEM alignment for practical program work.
Q3: Can NAFv4 architecture be produced in Sparx EA for a UK MoD program starting today? Yes. The 2024 UK MoD Defense Architecture Framework adopts NAFv4 and specifies Sparx EA as a supported modeling tool. A Sparx EA environment configured with the UPDM plug-in and Sparx Services’ NAFv4 MDG configuration is ready to produce MoD DAF-compliant architecture artifacts. The DAF also specifies specific mandatory and optional view sets for different program phases: Sparx Services can configure the Sparx EA environment with the DAF view requirements pre-loaded.
Q4: How many architects can work on a NAFv4 program repository simultaneously in Sparx EA? Sparx EA’s Pro Cloud Server supports multi-user concurrent access with model locking at the package and element level. Large program repositories with dozens of architects are supported: the architecture is partitioned into packages (C-Views, O-Views, Sy-Views, etc.) with designated architects owning specific packages. Concurrent access with conflict resolution is managed by Pro Cloud Server’s locking mechanism. Sparx Services’ Deploy engagement configures the multi-user environment with appropriate access controls for program team structures.
Q5: What is the relationship between NAFv4 and the Federated Mission Networking (FMN) architecture? Federated Mission Networking (FMN) is NATO’s framework for enabling mission-specific, federated networking between coalition partners. FMN Spirals define the specific services, standards, and architectures required for each increment of FMN capability. NAFv4 is the architecture framework for documenting FMN compliance: FMN architects produce NAFv4 S-Views (Service) and Tr-Views (Technical) documenting how their national contributions implement FMN Spiral services. Sparx EA is commonly used by NATO member nations for FMN architecture documentation.
Q6: How does NAFv4 handle classified architecture elements? Classification handling in Sparx EA is managed through access controls and package-level security rather than within the modeling language itself. Classified elements (SECRET, TOP SECRET) are placed in restricted packages with access limited to cleared users. In practice, many NATO program architectures are produced at the UNCLASSIFIED or NATO RESTRICTED level, with classified supplements maintained in separate restricted repositories. Sparx Services can advise on appropriate classification handling for specific program security requirements.
Q7: Can the same Sparx EA model support both NAFv4 and DoDAF views for a program with both NATO and US DoD customers? Yes. UPDM (Unified Profile for DoDAF and MODAF) is specifically designed to support multi-framework architecture from a single model. The common element definitions in the model’s data registry can be referenced by both NAFv4 and DoDAF views: an Operational Activity modeled once can be used in both an NAFv4 O3 view and a DoDAF OV-5b view. Correspondence relationships in the model map between the two view sets. This dual-framework approach is particularly valuable for programs with US and NATO customers requiring different framework compliance.
Q8: What does the Deploy engagement deliver for a NAFv4 program? Sparx Services’ Deploy engagement for NAFv4 delivers: a Sparx EA Pro Cloud Server deployment, UPDM plug-in installation and configuration, a NAFv4-specific MDG extension with MODEM-aligned stereotypes, a program repository package structure aligned to the seven NAFv4 viewpoint grids, a Common Data registry for capabilities, nodes, services, and organizations, access control configuration for the program team structure, and initial training for program architects. For UK MoD programs, the package structure is configured against the 2024 DAF mandatory and optional view sets.
Work With Sparx Services
NAFv4 program architecture requires a configured Sparx EA environment, not a blank slate. Sparx Services’ Deploy engagement delivers a NAFv4-ready Sparx EA repository: UPDM configuration, MODEM-aligned MDG, program package structure, and multi-user access controls: that your architecture team can use from the first program phase.
Platform support for large NAFv4 programs (multi-contractor, multi-phase) is available as an ongoing engagement.
Deploy from $30,000. Contact us to discuss your NAFv4 program requirements.
