Mapping TOGAF to Nato Architecture Framework (NAF)

With a focus on “Capability”

Copyright 2017 Graham Berrisford. One of about 300 papers at Last updated 30/12/2018 21:53

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


Since this paper was posted, longer analyses of core and related concepts have been posted.

NAF v.3 quotes above are taken from this source.

Read business functions and capablities in TOGAF for more on the same theme.

For more on business architecture in particular, read

For more on the general system theory that underpins these matters, explore


EA in general 1

EA in the armed forces. 2

Capability in general 3

Systems in general 4

NAF v3. 6

Mapping NAF v.3 terms to TOGAF 9.1 standard terms. 7

Mapping TOGAF 9.1 standard terms to NAF v.3 terms. 8


EA in general

Business directors must respond to business drivers by declaring strategic directions and top-level goals/objectives.

Business planning addresses changes that have been envisioned to one or more of an enterprises’

·         Constitution: mergers, acquisitions and divestments, opening/closing outlets

·         Market: industry domain/sector/segment, customers and suppliers

·         Products: products and services, sales and service channels, prices

·         Relationships: partners, in-sourcing and out-sourcing of operations

·         Resources: people, wages, machines, locations/buildings and other physical asset types.

It may involve predicting demand, sacking or appointing CxOs and restructuring the organisation's management.


Enterprise and solution architects may stimulate or contribute to business planning of that kind.

But their primary concern is business system planning.

They look to optimise, standardise, integrate and innovate in the structures and behaviors of regular business operations.

Partly to enhance current operations, and partly to support goals/strategies/plans that directors declare.


The dawn of the Information Age in the 1970s stimulated efforts to formalise business system planning.

Enterprise architecture emerged in the early 1980s out of thinking how to do this across an organization.

Practices included drawing cross-organizational business architecture artifacts such as:

·         a value chain diagram – which identifies top-level core and support functions of a business (after Porter, 1985)

·         a functional decomposition diagram - that is independent of the enterprise’s organization structure

·         a value stream diagram - which represents activities in the end to end flow of a business process (after Martin, 1995 if not before)

·         a data entity/business function matrix – which shows which data is created and used by which functions (not by organization units).


TOGAF version 9.2 describes business architecture as capturing architectural models of:

business operations, factors that motivate the enterprise, how the enterprise is organizationally structured, and what functional capabilities the enterprise has.”

This table lists maps this definition to some core business architecture entities.

Business architecture as defined in TOGAF 9.2

Typical business architecture entities

“Business operations


“factors that motivate the enterprise”

Drivers and Goals

“how the enterprise is organizationally structured”

Organization units and Actors

“what functional capabilities the enterprise has”

Business functions and Roles

EA in the armed forces

In many ways, the armed forces are like other businesses.

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

It needs recruitment, payroll, and other back office/administration/ support functions.

It organises and runs regular training programmes and other routines.


So, most of NAF is not peculiar to the armed forces; it is general to all systems in every describable enterprise.

E.g. the following architecture elements (in chapter 3 of NAF) are universal.

“In order to describe an NNEC architecture correctly and sufficiently the following architecture elements need to be captured:

Actor: who are the parties responsible for executing tasks?

Operational objective: what are the essential goals that need to be reached?

Capability: what abilities are required for conducting operations in order to reach desired effects?

Operational object: what entities are needed to reach the objectives?

Information object: what facts about the operational objects are relevant?

Process: what operational processes are needed and how are they orchestrated in order to deliver a desired an end state?

Location: where do all the processes, services and activities take place?

Information requirement: what information is needed?

Business rule: what are the conditions and constraints while delivering the end state?

Information product: what are the information deliverables?

Information flow: What is the end to end chain of information between the parties?

User: who are the parties that require functionality of applications?

Service: what is the delivery of (information) products and functionality?

Component: What is the construction of services?

Component collaboration: How do the components interact?”


However, the armed forces are special in some ways.

A standing army must prepare to do things it might never do in earnest.

The peace-time organisation must develop the capability to join up its forces to achieve one or more goals not yet declared.

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

The mission-time organisation needed to achieve some goal(s) may be called a capability.

It will draw resources from one or more peacetime organisations to achieve given goals.


This may explain why “capability” and “capability-based planning” are so prominent in prominent in architecture frameworks of the armed forces.

Beware that the same terms may be used differently in other sources and methodologies concerned with regular business operations.

Capability in general

Dictionaries define a capability as “the ability to do something or to achieve something”.

The trouble is:

·         The something could be of many different kinds

·         Whatever it is, the capability is in 1-to-1 correspondence with it

·         To disambiguate one must refer to the something directly.


For example, a business capability could be the ability to:

·         perform a business process

·         perform the activities grouped into a business function or role

·         perform the services required of an organization unit

·         achieve a goal, objective or purpose.


Capability-based planning must start by defining the something to be done or achieved.

Then proceed by defining resources with the required capability.

Those resources may include some or all of people, machines, computers, databases, networks, and procedures that actors must follow.

(They might even include people trained to find whatever resources they need to achieve some ad hoc aim.)


Some speak of a capability as though it is the resources that have the ability.

“A capability is composed of some resources interacting in repeatable value streams to meet some given purpose(s).”

But that is to equate a capability with system.

Since a business system is composed of actors interacting to perform repeatable activities to meet some aims.


In short, the “capability” concept is a chameleon.

And the resources that make the capability deployable are of various kinds.


The term is used freely by management consultants and enterprise architects.

This flexibility makes the term appealing and convenient in discussion with business people.

On the other hand, it makes it difficult to pin down its meaning, and place the concept in a meta model.

Different kinds of capability may be related to different, or all, entities in an EA meta model.


The more you strip a capability of the physical resources it needs, the closer it gets to a logical process or function.

A concrete capability is defined in terms of people, processes, data and technologies.

It is a physical business system to be constructed and delivered.

By contrast an abstract capability is defined independent of people, processes, data and technologies.

It usually if not always corresponds to a logical business function in a functional decomposition hierarchy.

Systems in general

This table list some concepts used in defining business activity systems and software activity systems.

General system ideas

Business system ideas

Defined in terms of business activities

Application system ideas


Business goal

A testable target for the outcome(s) of activities.

Software requirement


Business service

A contract defining the request for and result/outcomes of required activities.

Application service


A behavior (e.g. use case) that sequences activities.

Application process

Abstract structure


A group of services or activities performable by an organisation/actor/component.

Application interface

Business function

Concrete structure


A deployable managed unit that realises services by performing activities in processes.

Application component



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

And it exists in two forms, in logical specification at design time and in concrete operation at run time.


Persistent structures


Transient behaviors

Business organisation

In logical specification

business functions

are specified as acting in

business processes (aka value streams).

In concrete operation

organisation units

realise functions

by performing business processes.

Business people

In logical specification


are specified as acting in

activities (aka tasks or sub processes).

In concrete operation


realise the roles

by performing the activities.

Business applications

In logical specification


are specified as acting in

use cases or user stories.

In concrete operation

deployed software

realises the applications

by directing the use cases or user stories.


This table brings these ideas together using terms in TOGAF.


Required behaviors

Logical active structures

Physical active structures


Business Services

Business Processes

Business Functions


Organization Units


Information Systems

Application/IS Services

Logical Application Components

Physical Application Components


Platform Services

Logical Technology Components

Physical Technology Components


This table generalises business architecture entities that appear in EA frameworks (like TOGAF and NAF) and modelling languages (like ArchiMate and UML).

Business architecture entities

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 behavior performable by a business component that produces a result of value to its consumer.

An external view, a logical contract, that encapsulates whatever process(es) are need to deliver the desired result.


A sequence of activities performed by the actors in a business in the course of delivering a business service.

A process may occur within one organization or function, or coordinate activities in several organizations or functions.

Logical structures

groups of behaviors that are assignable to active structures


A logical business component.

A node in a business structure that represents a subdivision and group of its logical activities and capabilities.

It is describable externally by services provided and internally by activities assignable to organisation units.


A business function performable by one or more actors with the requisite capabilities.

It is describable externally by services provided and internally by activities assignable to an actor.

Active structures (who)

things that perform behaviors

Organisation unit

A real business component, capable of realising one or more logical functions.

A node in a management structure that subdivides and groups its physical actors, and perhaps resources also.

Note: in the special case of a “functional organization”, each organization unit realises one business function.


An entity capable of realising one or more roles; typically assigned to a bottom-level organization unit.

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, created and used in the course of performing behaviors.

Location (where)

A place where actors, components or entities are found and work is done.


Aside: in UML, roles are called actors.

In the ArchiMate standard, both people and organisation units are called actors

The table above separates people (actors) from organisations and roles.

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

NAF v3

This paper compares terms and concepts in NAF v3 and TOGAF 9.1.

Not so much for their own sake, but to support discussion of the “capability” concept.

The update below doesn’t affect the discussion of general system theory concepts in this paper.

It doesn’t affect the conclusion that people can and do relate business capability to business function in a 1 to 1 association.


UPDATE November 27, 2017

“The Object Management Group® (OMG®) announced that the NATO Consultation, Command and Control Board (NATO C3B)

adopted both the OMG Unified Architecture Framework™ (OMG UAF®) and The Open Group Archimate (TOG Archimate).

as approved metamodels for the NATO Architecture Framework, Version 4.

The UAF standard is aimed at improving strategic gaps in communications and interoperability of complex systems of systems among coalition partners uncovered in critical operations such as Afghanistan.”


NATO Consultation, Command and Control (C3) released NAF v3 into the public domain.

It was created as an architecture framework for NATO’s people, processes and technologies.

The aim was 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”, was to initiate a culture change that begins with people.

Helping people to interact and share information will help them reach better situational awareness and faster decision making.

Ultimately this will saves lives, resources and improve collaboration between nations.


The original context was NATO’s Network Enabled Capability (NNEC).

The NNEC has been merged into the Federated Mission Networking.

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

In social systems thinking, the term “system of systems” is often applied to a large and diverse organisation with one overarching board of directors.

To some, federation means distribution of control (as in “a group of states with a central government but independence in internal affairs”).

To others, federation means centralisation of control (as in “the action of forming states or organizations into a single group with centralized control”).

The NNEC federation will need at least some top-down direction if its parts are to reach a common goal.


Putting the centralisation/distribution debate to one side, NAF is clearly about EA, systems and capabilities.

The armed forces background is less important here than the nature of EA, systems and the nature of capabilities.

For more background, you may find this of interest <>


NAF appears 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”.

Which 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.

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

Other examples show capabilities related to activities, to services and to organisation units (much as TOGAF does).


“For the concept of the ability to deliver a specified type of effect the most common approaches for defence all use the term capability.”

However, different names are used for different kinds of capability.

It appears that operational capability is the same as C3’s military capability

And equipment capability is the same as a C3’s system capability

“The architecture element capability covers both aspects... elements of operation (capabilities of actors) and elements of technology (C3 system capabilities).”

Which is to say, a capability sounds like a whole system.

Mapping NAF v.3 terms to TOGAF 9.1 standard terms


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,




Operational service, Information service, Application service



Business service, IS service, Platform technology service

Process, Scenario

Active structures

Capability, Actor, User

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


Data Component, Data Entity


Mapping TOGAF 9.1 standard terms to NAF v.3 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.

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.



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.