Frameworks
NAFv4: NATO Architecture Framework version 4: is the architecture framework governing defense and government enterprise architecture work across NATO member nations. It is the successor to both MOD Architectural Framework (MODAF) version 1.2 and NATO Architecture Framework version 3, published in 2018 as a harmonized successor framework.
NAFv4 is formally aligned to ISO/IEC/IEEE 42010:2011, the international standard for architecture description. This alignment means NAFv4 viewpoints, views, and architecture descriptions are structured according to a rigorous international standard rather than a proprietary convention: which matters for interoperability across national defense programs.
NAFv4 replaced MODAF as the framework of record for UK MoD programs in 2018. For architects previously working in MODAF, NAFv4 represents a substantial reorganisation of viewpoints and the adoption of the MODEM (MOD Enterprise Data Meta-model) as the underlying ontology: though much of the conceptual content will be familiar.
NAFv4 organizes its views into seven viewpoint groups. Each group addresses a distinct dimension of an architecture. In ISO/IEC/IEEE 42010 terms, each viewpoint is defined by the concerns it addresses, the stakeholders those concerns belong to, and the model kinds (diagram types) that constitute a conformant view.
The Concepts viewpoint group addresses the conceptual-level architecture: the ideas, terms, and relationships that define the problem space before any solution is proposed. C views are the most abstract in the framework.
The Service viewpoint group addresses the services that implement capabilities: what the architecture provides to its consumers, independent of the systems that provide those services.
The Operational viewpoint group describes the operational tasks and activities the architecture supports: the business or military operations, independent of any system implementation.
The Systems viewpoint group addresses the physical systems and how they implement operational and service requirements. For defense programs, this is where platform, equipment, and system specifications connect to the operational architecture.
The Technical viewpoint group describes the technical standards, profiles, and constraints that govern the architecture. This is the standards-compliance dimension.
The Program viewpoint group addresses program management considerations: projects, timelines, and the transition between current and target architecture states. This is the dimension most relevant to acquisition and program management stakeholders.
The Architecture viewpoint group is the meta-level: it describes the architecture framework itself as applied to this specific architecture project.
The MODEM (MOD Enterprise Data Meta-model) is the ontology that underpins NAFv4. It defines the classes, properties, and relationships that NAFv4 views describe. The MODEM is the NAFv4 equivalent of the DoDAF Meta-Model (DM2): a formal specification of the data model that makes NAFv4 views machine-readable and interoperable.
The MODEM is expressed in OWL (Web Ontology Language) and defines approximately 350 classes covering:
When Sparx EA implements NAFv4 through the UPDM/NAFv4 MDG profile, the element stereotypes in that profile map to MODEM classes. An OperationalNode element in Sparx EA corresponds to a specific class in the MODEM ontology, carrying the properties and relationships that class defines. This mapping is what enables NAFv4 architecture descriptions to be processed, validated, and exchanged across program boundaries.
NAFv4 is relevant in a specific set of program contexts. It is not a general-purpose enterprise architecture framework: it is a defense and government architecture framework with specific applicability conditions.
Any capability development or acquisition program conducted under NATO governance: whether joint multinational programs or national programs contributing to NATO capability commitments: is expected to produce architecture documentation conformant with NAFv4.
UK Ministry of Defense programs replaced MODAF with NAFv4 from 2018. New programs are required to use NAFv4; existing MODAF-based programs may continue in MODAF until major review points. Architects advising UK MoD programs should be working in NAFv4 unless explicitly operating under a legacy MODAF regime.
Several NATO STANAGs (Standardisation Agreements) reference NAFv4 or MODEM-aligned architecture descriptions as inputs or outputs. Programs subject to these STANAGs have explicit NAFv4 compliance requirements.
The Five Eyes intelligence community (US, UK, Canada, Australia, New Zealand) has ongoing architecture interoperability work. NAFv4 and DoDAF are maintained in alignment: both reference the same foundational ontological concepts, with the MODEM and DM2 designed to be interoperable. Programs requiring Five Eyes interoperability typically need architects fluent in both NAFv4 and DoDAF.
Some UK government programs outside of MoD: particularly those with national security, emergency services, or critical national infrastructure dimensions: use NAFv4 or NAFv4-aligned approaches as their architecture standard.
Sparx EA provides native support for NAFv4 through the UPDM/NAFv4 MDG profile: a model-driven generation extension that implements the NAFv4 viewpoints, MODEM stereotypes, and NAFv4-specific diagram types within the standard Sparx EA modeling environment.
The Unified Profile for DoDAF and MODAF (UPDM) has been extended for NAFv4 alignment. To activate in Sparx EA, navigate to Specialize → Technologies → Manage Technologies and enable the appropriate UPDM/NAFv4 technology. The profile is available from the Sparx Systems MDG repository and from Sparx Systems resellers for programs requiring the full MODEM-aligned implementation.
When NAFv4 is active in Sparx EA, the recommended package structure follows the viewpoint group organization:
Architecture [root]
├── A Views
│ ├── A1 - Meta-Data Definitions
│ └── A2 - Architecture Products
├── C Views
│ ├── C1 - Overview
│ ├── C2 - Capability Taxonomy
│ └── ...
├── O Views
├── S Views
├── Sy Views
├── T Views
└── P Views
Each package contains the diagrams and element instances corresponding to its viewpoint group. MODEM-typed elements are created within their appropriate package and reused across diagrams: the fundamental Sparx EA principle of single-element-multiple-views applies fully in NAFv4 implementations.
The UPDM/NAFv4 profile adds NAFv4-specific diagram types to the New Diagram dialog. These include:
Each diagram type has a profile-configured toolbox that constrains available element types to those appropriate for the viewpoint, reducing modeling errors.
The NAFv4 profile enforces MODEM-compliant relationship constraints. Not all connection types are valid between all element stereotypes. This constraint enforcement is important for program compliance: an architecture that violates MODEM relationship rules may fail formal architecture review.
NAFv4 and DoDAF (US Department of Defense Architecture Framework) are frequently compared because they share conceptual origins and have been maintained in alignment. The differences matter significantly for program compliance.
DoDAF uses “viewpoints” with the prefix “AV” (All Views), “OV” (Operational Views), “SvcV” (Services Views), “SV” (Systems Views), “DIV” (Data and Information Views), “TV” (Technical Standards Views), and “PV” (Project Views). NAFv4 uses the C/O/S/Sy/T/P/A naming structure. The conceptual equivalences are close but not identical: an DoDAF OV-2 (Operational Resource Flow Description) is conceptually similar to an NAFv4 O2 (Operational Node Connectivity) but not a direct translation.
DoDAF uses the DM2 (DoDAF Meta-Model); NAFv4 uses the MODEM. Both are OWL-based ontologies covering similar conceptual territory, and the development teams have maintained alignment at the conceptual level. However, the class names, property names, and some structural choices differ. An architecture exchange between a DoDAF program and an NAFv4 program requires ontology mapping, not just viewpoint renaming.
DoDAF is governed by the US Department of Defense and is the mandatory framework for US DoD programs. NAFv4 is governed by NATO and is the mandatory framework for NATO and UK MoD programs. A architect advising a joint US-UK program needs to understand both frameworks and the mapping between them.
There are no widely recognized framework-specific certifications for NAFv4 or DoDAF analogous to TOGAF certification. Architects show NAFv4 competence through program experience and through vendor (Sparx EA) platform proficiency.
NAFv4 implementations in Sparx EA are most commonly delivered as a Deploy engagement: Sparx Services’ offering for establishing a configured, governed Sparx EA repository for a specific program or organisational context.
A Deploy engagement for NAFv4 includes:
Deploy engagements start at $30K for straightforward configurations and scale to $130K+ for complex multi-program or multi-national implementations with bespoke MODEM extensions.
What is NAFv4 and who uses it?
NAFv4 (NATO Architecture Framework version 4) is the architecture framework governing defense and government EA work across NATO member nations. It replaced MODAF for UK MoD programs in 2018 and is the standard for NATO procurement programs, UK government programs with national security dimensions, and Five Eyes intelligence community interoperability programs. It is aligned to ISO/IEC/IEEE 42010:2011 and uses the MODEM (MOD Enterprise Data Meta-model) as its underlying ontology.
What is MODEM and why does it matter?
MODEM (MOD Enterprise Data Meta-model) is the OWL-based ontology that underpins NAFv4. It defines the approximately 350 classes, properties, and relationships that NAFv4 views describe: capabilities, operational activities, services, systems, resources, and the relationships between them. MODEM matters because it is what makes NAFv4 architecture descriptions machine-readable and interoperable across program boundaries. Sparx EA’s NAFv4 profile maps its element stereotypes to MODEM classes.
Does Sparx EA support NAFv4 natively?
Yes. Sparx EA provides NAFv4 support through the UPDM/NAFv4 MDG profile, which implements NAFv4 viewpoints, MODEM-aligned stereotypes, and NAFv4-specific diagram types. The profile adds NAFv4 diagram types to the New Diagram dialog, enforces MODEM-compliant relationship constraints, and provides viewpoint-specific toolboxes. Sparx Services configures and validates the profile for program-specific compliance requirements.
What is the difference between MODAF and NAFv4?
NAFv4 is the formal successor to MODAF (MOD Architectural Framework). It reorganised MODAF’s viewpoints into the C/O/S/Sy/T/P/A structure, replaced MODAF’s underlying data model with the full MODEM ontology, and aligned the framework to ISO/IEC/IEEE 42010:2011. For architects, the conceptual territory is similar but the viewpoint naming and formal structure differ significantly. UK MoD programs have been required to use NAFv4 since 2018.
How does NAFv4 differ from DoDAF?
NAFv4 and DoDAF share conceptual origins and have been maintained in alignment, but differ in viewpoint naming (C/O/S/Sy/T/P/A vs. AV/OV/SvcV/SV/DIV/TV/PV), underlying ontology (MODEM vs. DM2), and governance (NATO vs. US DoD). A architect advising a joint US-UK program needs both. The frameworks are conceptually interoperable at the ontology level but are not directly translatable: view names that appear equivalent often have different scope and content requirements.
Which NAFv4 views are mandatory and which are optional?
NAFv4 does not mandate a fixed set of views for all programs. The appropriate view set is determined by the program’s type, phase, and stakeholder concerns. A capability development program will typically focus on C and O views; a systems acquisition program on Sy, S, and T views; a program management review on P views. The A1 view (Meta-Data Definitions) is always required as it documents the architecture’s governance. Sparx Services helps programs identify their required view set during scoping.
Can NAFv4 and ArchiMate coexist in the same Sparx EA repository?
Yes, though this requires careful package governance. Defense programs sometimes use ArchiMate at the enterprise layer (for capability maps and business architecture) while using NAFv4 views for program-specific operational and systems architecture. In Sparx EA, this is managed through distinct package hierarchies with each governed by its appropriate MDG profile. Sparx Services has experience configuring repositories that support both notations without cross-contamination.
What does a Sparx Services Deploy engagement for NAFv4 involve?
A Deploy engagement for NAFv4 covers program scoping (identifying the required NAFv4 view set), UPDM/NAFv4 profile configuration, package structure establishment with access controls, diagram template and toolbox configuration, architect onboarding, and production of the A1 governance view. Deploy engagements start at $30K for straightforward configurations and scale to $130K+ for complex multi-program or multi-national implementations. Contact Sparx Services to discuss scoping for your program.
NAFv4 programs require a correctly configured Sparx EA repository from the outset. Retrofitting NAFv4 governance to an incorrectly structured repository is substantially more expensive than configuring it correctly at program start.
Sparx Services delivers Deploy engagements that establish NAFv4-governed Sparx EA repositories for defense and government programs: from UK MoD capability programs to NATO joint procurement architecture work.
Talk to Sparx Services about a NAFv4 Deploy engagement
Deploy engagements start at $30K. Scoped for your program’s specific view requirements.
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.