View Architecture Framework Comparison


The following is an attempt to try and compare and contrast the DODAF and DODAF-descendant enterprise architecture frameworks. This page looks at the top-level presentation and definition methods and size.

Language / Terminology

Terminology/Language Used to Describe Singular and Collections of Architecture Views
SingularViewSubview Product? ModelViewSubviewViewView

MODAF and NAF have no distinct word for the product of the description of a view/subview. The net result is that colloquially the same term is used for the description of the view/subview and the product of the description.

TRAK uses ‘viewpoint’  for the specification and ‘view’ for the product produced in response to the viewpoint. These terms are defined in ISO 42010.


How the frameworks are specified. Comparison is not so straightforward since the different expressions/types of “defining document” have been produced for different purposes - particularly when you try to compare their metamodels since the size is partly a product of the purpose/target audience.

Framework Specification DNDAF, DODAF and MODAF
Framework DNDAF 1.7DODAF 2 MODAF 1.2
Metamodel DND/CF Architecture Data Model (DADM). A data model rather than a metamodel. Emphasis on populating the data model using the subviews. Used as a schema for the repository (DARRS). Not used to constrain the subview content. Similar in purpose/approach to that used in the CADM underpinning DODAF 1.5. Specified in: DND/CF Architecture Framework (DNDAF) Version 1.7, Volume 3: DND/CF Architecture Data Model (DADM) Designed to be read and implemented by tool manufacturers for implementation in their tools. Navigable model online at
Product Each DNDAF::view/subview has its own descriptive document and a section in a user guide providing information on process and templates. See DNDAF::Common View (CV), DNDAF::Strategic View (StratV), DNDAF::Capability View (CapV), DNDAF::Operational View (OV), DNDAF::System View (SV), DNDAF::Technical View (TV), DNDAF::Information View (IV), DNDAF::Security View (SecV)...Each MODAF::viewpoint has its own descriptive document / guide for the architect which describes each view. See MODAF::Strategic Views Viewpoint, MODAF::Operational Viewpoint, MODAF::Acquisition Viewpoint, MODAF::System Viewpoint, MODAF::Service Oriented View Viewpoint, MODAF::Technical Standards Views Viewpoint, All Views Viewpoint. Descriptions augmented by fragments of simplified form of the M3.
Framework Specification - NATO AF and TRAK
Framework NAF 3.0 TRAK
MetamodelMetamodel (NMM) designed to be read and implemented by tool manufacturers. Issued with product in a single document.TRAK Metamodel - defined to be read and used by architects / modellers. Available online at
ProductEach NAF::subview has its own description. See NAF::NATO Capability View (NCV), NAF::NATO Operational View (NOV), NAF::NATO Programme View (NPV), NAF::NATO System View (NSV)NATO Service-Oriented View (NSOV)NAF::NATO Technical View (NTV), NAF::NATO All View (NAV) Issued together with metamodel in single document.TRAK::viewpoints (specifications for a single architecture view) defined at Follows ISO 42010 guidance wrt content - aims, concerns addressed, definition, consistency rules.

Note: At NAF 4.0 the NMM was removed from the master NAF document.  A statement is made in 6.1:

The meta-model defines the essential modelling elements that can be used to describe the system in an enterprise context and its environment

and at 7.4 Adoption of Industry Meta-Models:

As part of the development of NAFv4 it was agreed that it should make use of commercial architecture meta-models to enable architecting across military and non-military domains. These are described in Chapter 4.

and then in Chapter 4 - Meta-Model:

Chapter 4 of the NATO Architecture Framework identifies the meta-models to be used for creating NAFv4 compliant architectures.

NAFv4 compliant architectures can be creating using the following meta-models; The Open Group®’s ArchiMate® and the Object Management Group®’s Unified Architect Framework (UAF)® Domain Meta-model (DMM)®

The mention of ArchiMate is inconsistent as it is a plain Architecture Description Language - it doesn’t contain a metamodel which defines Architecture Description Elements that may be used in NAF architecture views. For this to happen someone woud have to create a set of types from the ArchiMate metamodel that could be used to represent the NMM element types.

NAF v4 no longer has a metamodel. What remains is an implementation of the NMM in UML for UML modelling tools (UAF profile or UAFP) in the Unified Architecture Framework. That part of the UAFP that implements the NMM now has no master NMM to trace to as it has been removed from the definition of NAF v4 i.e. we have a design implementation but no requirements against which the UAF/UAFP was developed.


Framework Size in Terms of Architecture View Collections
FrameworkDNDAF 1.7DODAF 2.0MODAF 1.2.004NAF 3.1NAF 3.0TRAK
Collection8 views8 viewpoints7 viewpoints7 views7 views5 perspectives
Singular36 subviews52 models47 views49 subviews47 subviews21 views

where each has the following collections of architectural mode/view/subviews:

Framework Architecture View Collection Names and Sizes
Framework: View Collection (Size)
DNDAF Information View (2)DODAF Data and Information Viewpoint (3)   
DNDAF Strategic View (1)DODAF Capability Viewpoint (7)MODAF Strategic Views Viewpoint (6)NATO Capability View (NCV) (7)TRAK Enterprise Perspective (3)
DNDAF Capability View (2)
DNDAF Operational View (11)DODAF Operational Viewpoint (9)MODAF Operational Viewpoint (11)NATO Operational View (NOV) (9)TRAK Concept Perspective (5)
 DODAF Project Viewpoint (3)MODAF Acquisition Viewpoint (2)NATO Programme View (NPV) (2)TRAK Procurement Perspective (3)
 DODAF Services Viewpoint (13)MODAF Service Oriented View Viewpoint (7)NATO Service-Oriented View (NSOV) (5) 
DNDAF System View (13)DODAF Systems Viewpoint (13)MODAF System Viewpoint (17)NATO System View (NSV) (18)TRAK Solution Perspective (7)
DNDAF Technical View (2)DODAF Standards Viewpoint (2)MODAF Technical Standards Views Viewpoint (2)NATO Technical View (NTV) (3)TRAK Management Perspective (3)
DNDAF Common View (2)DODAF All Viewpoint (2)MODAF All Views Viewpoint (2)NATO All View (NAV) (3)
DNDAF Security View (3)    

Philosophy / Approach

There are some slight but significant differences in the philosophy regarding the approach, use and purpose of framework that reflect not only its use but how it is managed and structured.


DODAF aims to populate an underlying data model (was CADM now DADM) and the DODAF views are the means to provide the data.

DODAF 2 introduction:

DoDAF V2.0 focuses on architectural “data”, rather than on developing individual “products” as described in previous versions

DoDAF V2.0 provides a Data Capture Method for each data group of the DM2 to guide architects in collecting and organizing the necessary architectural data.

The core of DoDAF V2.0 is a data-centric approach where the creation of architectures to support decision-making is secondary to the collection, storage, and maintenance of data needed to make efficient and effective decisions.

Data collection and completeness of population is not the same as (good) systems engineering.


TRAK is predicated on ISO 42010 which requires that architecture viewpoints are selected to meet / match the task sponsor’s concerns and only those corresponding views are produced. There is no underlying TRAK data model or single TRAK repository. A modelling tool usually has a repository and therefore whilst it is possible over time that all of the TRAK metamodel is covered by the architecture description this is not the primary aim - the aim is to answer the sponsor’s exam question.

Architecture Description Process / Method


Category:Framework -> Collection



© 2010 Eclectica Systems Ltd.