MOD Architecture Framework

The MOD Architecture Framework (MODAF) is a set of rules that support defence planning and change management activities.

This guidance was withdrawn on

MODAF has been replaced with the NATO Architecture Framework (NAF) V4.

NAF V4 can be found on the NATO website.


The Ministry of Defence Architecture Framework (MODAF) is an internationally recognised enterprise architecture framework developed by the Ministry of Defence (MOD) to support defence planning and change management activities. It does this by enabling the capture and presentation of information in a rigorous, coherent and comprehensive way that aids the understanding of complex issues.

Who should use this guidance

This guidance is intended for anyone with an interest in MODAF. This audience includes:

  • Enterprise architects, the principal customers for MODAF views, who need to both correctly interpret standard MODAF views provided to them and to specify and control the tasks required to create new views
  • Architectural modellers who need guidance on the creation and interchange of MODAF views (including for example: architecting principles, view coherence rules and tool selection criteria)
  • Tool developers and engineers who are implementing architectural data repositories for storing and manipulating MODAF architecture data elements
  • Trainers and educators who require reference material in order to appropriately train and support the previous types of MODAF users
  • MODAF users who wish to contribute to the development of MODAF
  • Managers who need to understand what views are required to answer their particular questions

MODAF guidance

Documentation supporting the MODAF.

MODAF provides a coherent set of rules and templates, known as ‘views’, that, when populated, provide a graphical and textual visualisation of the business area being investigated.

Each view offers a different perspective on the business to support different stakeholder interests.

The views are divided into 7 categories:

  1. Strategic views (StVs) define the desired business outcome, and what capabilities are required to achieve it
  2. Operational views (OVs) define (in abstract rather than physical terms) the processes, information and entities needed to fulfil the capability requirements
  3. Service oriented views (SOVs) describe the services, (i.e. units of work supplied by providers to consumers), required to support the processes described in the operational views
  4. Systems views (SVs) describe the physical implementation of the operational and service orientated views and, thereby, define the solution
  5. Acquisition views (AcVs) describe the dependencies and timelines of the projects that will deliver the solution
  6. Technical views (TVs) define the standards that are to be applied to the solution
  7. All views (AVs) provide a description and glossary of the contents of the architecture

To ensure the coherence between the views, MODAF is underpinned by a model which defines the relationship between all the data in all the views. This model is called the MODAF.

Meta model, also known as the ‘M3’. The M3 also provides a technical standard to enable the exchange of data between architectures developed in different modelling (software) applications.

Meta Model (M3): an introduction

MODAF supports the application of rigour to requirements capture

The use of MODAF provides a defacto element of rigour to requirements capture because the population of the views requires the application of a structured analytical approach that leads the user from desired outcome to solution options.

MODAF supports the modelling of options

There are a number of commercially available tools that support the use of MODAF. As well as allowing the presentation of the views, these tools also provide a repository in which the architecture can be stored and enable the modelling of different change options to support decision making.

MODAF supports interoperability

The use of MODAF as the standard architecture framework enables the coherent sharing of architectural information which helps identify gaps and overlaps between operating processes and the systems that support them.

MODAF has pedigree

MODAF was developed by MOD from the US Department of Defense Architecture Framework (DoDAF) version 1.0, but has been extended and modified to meet MOD requirements. MODAF is now itself internationally recognised as a best practice for enterprise architecting, and provided the template against which NATO Architecture Framework version 3.0 was developed.

MODAF has been adopted by organisations outside MOD

As well as MOD, MODAF is widely used by its industry partners, such as BAE Systems, Thales, Lockheed Martin, Boeing and Serco. It is also used by other government departments, such as GCHQ, and external bodies, such as the National Air Traffic Services. MODAF was recently adopted for use by the Swedish armed forces.

Viewpoints and Views

This section provides an overview of the different viewpoints used in the MODAF.

MODAF architectures are developed as coherent, contiguous models that when viewed as a whole present a complete picture of the enterprise. MODAF defines a rich selection of relationships which can be used to integrate the various architectural elements.

Producing an enterprise architecture is rarely the work of one person and it is sometimes useful to be able to logically divide an architecture into domains, each concerned with one aspect of how the enterprise works. This also proves useful when publishing an architecture to different stakeholders. For this reason, MODAF defines a set of standard viewpoints.

Each Viewpoint takes a different perspective upon the architectural model; for instance, the Operational Viewpoint considers the operaional nodes (logical ‘actors’ that may be realised by one or more resources) that interact in certain ways in order to achieve a desired outcome.

The MODAF views

Each Viewpoint consists of several views, which highlight slightly different details within the particular Viewpoint. For instance within the Operational Viewpoint, OV-1 provides a high level conceptual graphic, whilst OV-2 considers the interactions between operational nodes and OV-3 details the information flows.

Whilst the data within each view adds more richness to the overall description of an architecture, it is not necessary for all of the MODAF views to be completed at any particular point in time during the MOD’s acquisition life cycle. Indeed, each group of users within the MOD will have different needs and will only populate and exploit those MODAF Views that are of relevance to them. This means that most of the MOD’s communities of interest (COIs) will only be dealing with the population and exploitation of a subset of MODAF views, and few will need to understand and deal with all of the available MODAF views.

Interactions between views and interactions between architectures

It is expected that the StVs cover more than one operational architecture, i.e. the capabilities defined in the StVs are re-used across a number of architectures. It may also be the case that the architect wishes to conduct an architectural trade study, i.e. there may be multiple possible solutions for a given requirement in the OVs.

These relationships are covered in more detail in the guidance for each viewpoint and in the document ‘MODAF layers and viewpoint linkages’.

Views summary documents

Documents summarising the MODAF views and viewpoints.

View summary is intended to help choose the most appropriate MODAF views. It provides a list of all views and details what each view is used for and what data elements they contain.

View summary

Layers and viewpoint linkages provides a top level view of how MODAF views relate to each other.

There is also a downloadable version of the ‘Viewpoints and views’ homepage.

Views Home Downloadable

All views viewpoint

A description of and guidance for the use of the MODAF all views viewpoint.

The AVs provide an overarching description of the architecture; its scope, ownership, timeframe and all of the other metadata that is required in order to effectively search and query architectural models. They also provide a place to record any findings arising from the architecturing process.

The AVs include a dictionary of the terms used in the construction of the architecture, which helps others fully understand its meaning at a later date.

AV viewpoint

Strategic view viewpoint

A description of and guidance for the use of the MODAF strategic view viewpoint.

StVs support the process of analysing and optimising the delivery of military capability in line with the MOD’s strategic intent.

The StVs achieve this by capturing the capability policy/concepts, decomposing this into a capability taxonomy supported by appropriate measures of effectiveness that can be used for capability audit and gap/overlap analysis.

StV viewpoint

Operational View viewpoint

A description of and guidance for the use of the MODAF operational view viewpoint.

The OVs define the logical aspects of the architecture. A suite of OV products may be used to describe a requirement for a to-be architecture in logical terms, or as a simplified description of the key behavioural and information aspects of an as-is architecture.

The OVs reuse the capabilities defined in the StVs and put them in context of an operation or scenario. The OVs can be used at a number of points through the MOD lifecycle including the development of user requirements, capturing future concepts and supporting the operational planning process.

A number of stakeholders will develop and exploit OVs during the MOD acquisition lifecycle.

More details on the OVs and information exchange requirements (IERs) are contained in the document IERs in MODAF.

OV viewpoint


System view viewpoint

A description of and guidance for the use of the MODAF system view viewpoint.

The SVs are a set of views that describe resources that realise capability.

The SVs describe resource functions and interactions between resources and can also provide detailed system interface models. Note that these views address the involvement of humans in both the operation of systems and in carrying out functions in their own right.

The SVs can be used to specify solutions to requirements specified in the OVs, or simply to provide more detail to the logical OV architecture.

SV viewpoint

Technical standards view viewpoint

A description of and guidance for the use of the MODAF technical standards view viewpoint.

The TVs are tabular views containing standards, rules, policy and guidance applicable to aspects of the architecture.

The contents of the TVs do not necessarily need to be of a technical nature and can apply just as much to operational activities (eg) doctrine, standard operating procedures and tactics, techniques and procdures) as they do to systems (eg standards and protocols).

The content of TVs will come from a number of sources including the policy setting organisations in MOD and core interoperability standards from ‘the sponsor’.

TV viewpoint

Acquisition view viewpoint

A description of and guidance for the use of the MODAF acquisition view viewpoint.

The AcVs describe programmatic details, including dependencies between projects and capability integration across the defence lines of development (DLODs).

The Views identify interaction between programmes and projects, and integrate acquisition activities across all of the DLODs. The AcVs provide important programmatic information for those involved in capability management and acquisition.

Since they also address the maturity across all of the DLODs to deliver an integrated military capability, the AcVs also form an important interface between the acquisition IPT and its lead user community.

AcV viewpoint

Service oriented view viewpoint

A description of and guidance for the use of the MODAF service oriented view viewpoint.

The SOVs are a set of views that specify services that are to be used in a service-oriented architecture (SOA).

In MODAF terms, services are an implementation-independent specification of a packaged element of functionality. The views describe the specification of these services, how services are orchestrated together for a purpose, the capabilities that services deliver and how services are implemented.

Note that the views do not focus on the detailed design of the service, rather on the requirement the service fulfils.

SOV viewpoint

MODAF meta model and MODAF ontological data exchange mechanism

MODAF meta model

The MOD Architecture Framework (MODAF) meta model (M3) is the information model for MODAF, defining the structure of the underlying architectural information that is presented in the views. The goal is that MODAF tools are “model driven” ie the views that are presented to the user are snapshots of underlying architectural data which is stored in the tool or in a repository.

Version 1.2.004 of the M3 of M3 is provided in the PDF file below.

MODAF Meta Model 3

MODAF ontological data exchange mechanism

The MODAF ontological data exchange mechanism (MODEM) is an evolution of the M3, based on the ‘international defence enterprise architecture specification’ (IDEAS) foundation model. It contains all the MODAF elements currently in M3, but has been built from first principles to support enterprise architecture whereas M3 was a profile that extended UML.

Like the M3, MODEM is primarily aimed at the developers of software tools to enable them to implement a MODAF compliant profile. However, it is recognised that M3 is also used by architects to help them understand the relationships between the organisations, processes, and systems that they are modelling. MODEM provides both these stakeholder groups with a more logical construct to work against.

MODEM was developed by the Swedish armed forces working with MOD staff, and is seen as a key component contributing to the development of the Unified Architecture Framework (UAF), a proposed convergence of the individual frameworks currently used by Canada, UK, US, and NATO. MODEM will be the last major MODAF deliverable, as the focus will now be on the development of UAF.

MODEM is provided here, to give MODAF stakeholders early visibility of its capability, ahead of the development of a migration plan.


Use and examples of MODAF

The MODAF architecting process

There are many different approaches to architecting which can be taken depending on the situation. MODAF does not prescribe an ‘official’ architecting process. However, for someone new to architecting with MODAF, some direction is helpful.

Uses and examples

The documents present a number of examples of how MODAF can be used to support activities associated with the delivery of military capability.

The MODAF architecting process

MODAF support to gap analysis

Frequently asked questions

The following links provide information on ontologies and their use in the MODAF, a glossary and abbreviations list and frequently asked questions.

Ontologies and their use in MODAF

MODAF glossary

Coherency across models with MODAF

Sharing architecture data

Other frequently asked questions

Is there a MODAF manual?

A PDF download to act as a manual or reference guide fo the MODAF practitioner.

MODAF documentation: configuration control policy and version history

Details on major, minor and editorial revisions.

MODAF 1.2 Version History V1.0

MODAF 1.2 004 Change Log

Contact details


International Defence Enterprise Architecture Specification (IDEAS) Group

NATO Architcture Framework (NAF)

Updates to this page

Published 12 December 2012
Last updated 7 August 2020 + show all updates
  1. Updated attachments that are extant.

  2. First published.

Sign up for emails or print this page