The TOGAF standard mapped to NAF

Copyright 2017 Graham Berrisford. One of about 300 papers at Last updated 11/12/2017 15:37

ArchiMate®, The Open Group®, TOGAF®, UNIX®, are registered trademarks, and Boundaryless Information Flow™ and IT4IT™,  are trademarks of The Open Group.


This is one of several popular papers on the TOGAF standard that are posted on the home page at

This paper maps terms used in the TOGAF standard to terms used in the NATO Architecture Framework (NAF).

It compares NAF and TOGAF on the generic terms and concepts they do, near enough, share

And exposes some differences where people might otherwise consider them to be identical.


TOGAF capabilities, functions and value streams. 1

NATO Architecture Framework (NAF) 1

Capabilities in the armed forces. 2

System theory concepts in NAF and TOGAF. 3

Mapping the TOGAF standard terms to NAF terms. 4

On applications and capabilities as systems - which aggregate different entity types. 6


TOGAF capabilities, functions and value streams

Before reading this paper, it is strongly recommend you read at least the first half of this other paper.

TOGAF business architecture: capabilities, functions and value streams

NATO Architecture Framework (NAF)

According to sources including this one <>

NAF is an architecture framework for defining the people, processes and technologies involved in NATO’s Network Enabled Capability (NNEC).

The aim is to federate NATO capabilities at all levels, military (strategic to tactical) and civilian, through an information infrastructure.

The main objective, illustrated by the slogan “Share to Win”, is to initiate a culture change that begins with people.

Interacting with each other and sharing information will lead to better situational awareness and faster decision making.

And this ultimately saves lives, resources and improves collaboration between nations.

And since NAF was created, the NNEC has been merged into the Federated Mission Networking.


I am not sure the background context above is important to this paper.

The nature of armed forces and their “capabilities” is probably more important.

Capabilities in the armed forces

Beware this section is written as an outsider looking in!


Every army, navy and air force has some regular business operations.

They need recruitment, payroll, and other back office/administration/ support functions.

There are regular training programmes and other routines.


And all enterprise architecture is about business roles and processes that create and use business data.

It involves talking to business people about how they use technologies to exchange information.


And at the level of abstraction in an architecture framework, one business looks like another.

If you look at the DODAF meta model, or the MODAF artifacts, you'll see they have nothing to do with the armed forces in particular.

They are general to all systems in every describable enterprise.


So, like all other architecture frameworks, NAF addresses:

·         roles played by people

·         processes they follow

·         information created and used in those processes

·         technologies (software and hardware) used to create, use and share information.


However, the armed forces are special in some ways.


Capabilities in the armed forces

Why is capability-based planning so prominent in the armed forces?

And the concept of “capability” so central in DODAF, MODAF and NAF?


A standing army prepares to do things it does not do on a regular business – and might never do.

It must develop the capability to join up its forces to achieve a goal not yet declared.

The goal may be to win a war, or perform a one-off mission of some other kind.

The mission-time organisation needed to pursue this project may be called a capability.

It will draw resources from the peacetime organisation to achieve the given goal.


Unfortunately, definitions of "capability" in different sources, and even in the same source, are many and various.

At different times, a capability appears to be:

·         what is traditionally called a "function" (as in a logical functional decomposition structure), or

·         a one-off process or project.

·         an organisation

·         a cross-organisational team.

·         any or all of the above

·         defined so loosely that it could be something else, an application for example.


It is not easy to fit the concept of capability into a methodology designed to model regular business operations.

So, bear in that in mind in what follows.

System theory concepts in NAF and TOGAF

NAF says “The NNEC will be a federation of systems rather than a system of systems.”

The message is a political one; system theory terms however, a federation of systems is a system.


Every designed system can be described in terms of structures that perform some behaviors to meet some aims.

This table generalises from how these concepts appear in standard frameworks like TOGAF and NAF, and modelling languages like ArchiMate and UML.


Business system concepts

General definitions

Aims (why)

motivations for behavior

Goal or Objective

a target to be achieved, a motivation or reason to perform behaviors.

Behaviors (how and when)

things that happen over time and change the state of a system or its environment


a discrete requestable behavior that produces a result of value to a consumer, describable in a contract that encapsulates internal processes


a sequence of activities that leads to the production of a desired result (a state change, product or output flow).

Logical structures

groups of behaviors that are assignable to active structures


a logical system component, describable externally by services provided and internally by activities assignable to one or more organisation units.


a logical system component, describable externally by services provided and internally by activities assignable to one or more actors.

Active structures (who)

things that perform behaviors

Organisation unit

a named business division, which can be given the responsibility of realising one or more logical functions.


a named person or machine, which can be given the responsibility of realising one or more logical roles.

Passive structures (what)

things that are acted on

Physical entity

a concrete entity type that a business creates and/or uses in the course of performing behaviors.

Data entity

a record type that describes the attributes of an entity or event, which is created and used in the course of performing behaviors.

Location (where)

a place in space where a structure can be found.


Aside: in UML, roles are called actors; in the ArchiMate standard, both people and organisation units are called actors; the table above separates people from organisations and roles.

And note the curiosity that whereas every human actor is a unique individual, every software actor is a replicable individual.


This table classifies the core concepts defined in NAF chapter 3, along with roughly corresponding terms in the TOGAF standard.


System theory

NAF terms

TOGAF standard terms

Levels of






Logical components or Architecture Building Blocks

Physical components or Solution Building Blocks


Operational objective, Business rule, Information requirement

Goal, Objective, Requirement


Service, Operational service, Information service, Application service, Process

Service, Business service, Information system service, Platform technology service, Process, Scenario

Active structures

User, Actor, Capability, Component, Application component,

Technical infrastructure component, Component collaboration, Information flow

Function, Organisation Unit, Role, Actor, Application component, Technology component

Passive structures

Operational object, Information object, Information product, Location

Data Component, Data Entity, Location

Mapping the TOGAF standard terms to NAF terms

There are some reasonably good matches and some mismatches.







Required behaviours: services and processes.


the required functionality of the system: what people need to be able to do, what services they need from applications.

Logical structures: functions, roles, logical components.


how the functionality should be constructed: may refer to technology types, but not actual technology products.

Physical structures: organization units, actors, physical components.


what solution is implemented: including actual technology products and the consequences of their adoption.



Goal or Objective

Operational objective

the intent of authority to reach a certain end state.

A pre or post condition of a Service

Business rule

a constraint that determines the behaviour of an enterprise while achieving its goals and objectives.

A Requirement expressed as an output

in a Business or IS Service contract.

Information requirement

a statement of what an actor needs to know about objects in order to fulfil his tasks in the mission space.





an implementation independent specification of the deliverables that has added value to the consumer of that service

in accordance with the consumer’s goals and objectives.

Business service

Operational service

a service providing an observable outcome which fulfils an operational need.

Business service or IS service

Information service

a service providing data which fulfils information requirements.

IS service or Platform technology service

Application service

a service delivering automated functionality which fulfils the needs and requirements of the user, provided by an automated application.

Process or Scenario


a composition of activities that are triggered by an event and transforms a specific input into a meaningful output.



Role - in connection with an application


a person or a group of persons representing one or more actors using the same functionality of an automated application.

Role or Function


an implementation independent unit of responsibility that performs an action to achieve an effect that contributes to a desired end state.

 (SEE NEXT SECTION) Function or other?


the ability to deliver a specified type of effect or a specified course of action. (SEE NEXT SECTION)

Architecture Building Block

in the Application and Technology domains


the logical construction element of an elementary application service.

Logical application component

or Logical technology component

Application component


Logical technology component (hardware only)

Technical infrastructure component


Phase B: node-connectivity diagram

Phase C: application communication diagram

Phase D: (several diagram types)

Component collaboration

the necessary cooperation of two or more components in order to provide a required functionality.

Phase B: node-connectivity diagram

Phase C: application communication diagram

Information flow

the full chain of end-to-end information delivery from capturing, processing, and storing of data

by one set of actors to processing, distributing and using information by another set of actors.



Data entity

Operational object

a thing or entity that occurs in the real world and of which information is required about the facts that need to be known.

It can be a tangible object, like military equipment, an event such as an operation or a concept like a directive.

Data entity

Information object

an implementation independent representation of the facts that need to be known about objects and their coherence

in order to turn the set or representation into information.

An output in a Business or IS Service contract.

Information product

a meaningful output comprising an implementation independent representation of required information

for the achievement of goals and objectives.



a geographical spot, e.g. a place represented by spatial coordinates.

On applications and capabilities as systems - which aggregate different entity types

Every designed system has some structures that perform some behaviors to meet some aims.

But note that it exists in two forms, at design time and run time.

There is an abstract system description – composed of interrelated types.

There are zero, one or more concrete system realisations – each composed of objects which instantiate the abstract types and relationships.


E.g. An application is often called a system.

It has some structures that perform behaviors to meet some aims.

And it exists in two forms, at design time and run time.


E.g. A capability may be seen as a system or subsystem that is bounded logically rather than physically.

In architecture frameworks, it may be seen as a function rather than an organisation unit.


NAF is inconsistent in its use of the term capability.

It defines a capability as the ability to deliver a specified type of effect or a specified course of action.

That sounds like the ability to perform a single behaviour or process.

Yet NAF gives examples that are related to several effects and courses of action.

And NAF speaks of "capability functions" and of mapping capabilities to systems.


Some NAF example capabilities are named as a goal that summarises what a function or system is expected to do.

Beyond having one or more goals, NAF examples show capabilities related to activities, to services and to organisation units.

Which is exactly as functions are described in the "structured analysis" that underpins business architecture in the TOGAF standard.


This table shows both business capabilities and applications can be regarded as systems, which are aggregates of other concepts in TOGAF.


A business capability

An application


corresponds to one named function

corresponds to one named application component


is decomposable into other functions

is decomposable into other application components


meets goals/objectives of the named function

meets requirements of the named application component


delivers business services associated with that function

delivers information system services associated with that application component


employs the necessary structural resources

notably, some organisation units, roles and applications

employs the necessary structural resources

notably, some data entities and technologies


In NAF, O-BA and other sources, capability is a somewhat ambiguous concept.

However, it seems a capability could reasonably be regarded as an aggregate of

·         one function 

·         + all other architectural entities mentioned in the table above 

·         + some more.


So, to fully describe a capability would be to enter the model/schema on a function, access many other related entities and extract a complex aggregate view.

As a system, as an aggregate of relatively normalised entities, capability does not sit well in a meta model that defines the entity types within a system.


There is no need to include both application and application component as entity types in TOGAF’s meta model.

And somewhat similarly, there is no need to include both business capability and business function.

If you try to include both, you end up duplicating some or all of their attributes and relationships – as discussed below.



All free-to-read materials on the http://avancier,web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.