Capability mapped to Function ++

Illustrated by mapping TOGAF 9.1 to NAF

Copyright 2017 Graham Berrisford. One of about 300 papers at Last updated 12/03/2018 12:04

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


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


Preface. 1

EA in general and in the armed forces. 3

Systems in general and in the armed forces. 4

Capabilities in general and in the armed forces. 6

Business capability as business function ++. 7

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

Further reading. 10




General system ideas

The term system is overloaded with different meanings.

It usually means a concrete activity system, composed of actors interacting in the activities that characterise the system.

Read System theory ideas for more about systems in general.


A business capability is the ability of some actors to perform some activities, as may be grouped in business function.

A value stream is an end-to-end flow of activities, as may be sequenced in a business process.

Is it that simple?


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


General system ideas

Business system ideas

Defined in terms of business activities


Business goal

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


Business service

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


A behavior that sequences activities.

Abstract structure


A group of services offered and/or activities performable by an actor.

Business function

A group of services offered and/or activities performable by an organisation.

Concrete structure


A person (or machine?) who realises a role by performing activities in processes.


A managed unit that realises a function’s services by performing activities in processes.


This table list some comparable concepts used software architecture.


General system ideas

Application system ideas

Defined in terms of software activities


Application requirement

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

Behavior (use case)

Application service

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

Application process

A behavior that sequences activities.

Abstract structure

Application interface

A group of services offered and performable by an application component.

Concrete structure

Application component

A deployable unit that realises an interface’s services by performing activities in processes.


What does capability add to the story?

A capability is the ability to be something, do something or achieve something.

So, which of the above is that thing?


A little history

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

EA in general and in the armed forces


EA in general

Enterprise architecture is about business roles and processes that create and use business data.

It is about how business actors cooperate in regular or repeatable business activities by remembering and exchanging information.

So enterprise architecture frameworks address:

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


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.


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.

Systems in general and in the armed forces

NAF is clearly about systems.

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

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


A computer activity system.

A logical system description – names persistent applications and transient use cases.

Concrete system realisations – deployable applications that perform the use cases.


A human activity system – human level.

Logical system description   names persistent roles and transient activities (aka tasks or sub processes).

Concrete system realisations –actors who play the roles by performing the activities.


Business activity system – organisation level.

Logical system description – names persistent business functions and transient processes (aka value streams).

Concrete system realisations – organisation units that fulfil the functions by performing the processes.


This table brings these ideas together in a simple way akin to TOGAF.



Required behaviors

Logical structures

Physical structures


Business Processes

Business Functions

Organization Units

Business Activities



Information Systems

Use Cases

Logical Applications

Physical Applications


Platform Services

Logical Technologies

Physical Technologies


This table generalises system concepts appear in 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 (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.


This table maps core concepts in NAF chapter 3 to 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,




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



Read papers on this system theory page for more on general system theory.

Capabilities in general and in the armed forces

The tern “capability” has become popular in EA frameworks.

The concept called is variously, poorly and ambiguously defined.
Sources are incompatible with each other, and with themselves.


Capability in general

A capability is the ability to be something, do something or achieve something..

And a capability therefore corresponds (1 to 1) to that thing.

But what is that thing?

Is it one goal or several goals? one activity or a group of activities?

Is it a persistent business function, or a one-off process or project?

Is it an organisation unit, or a cross-organisational team?

Is it a subsystem of any kind, human and/or technological?

Is it a complete system in its own its right?


Capabilities in the armed forces

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.

Business capability as business function ++

This section contains practical suggestions on how to interpret capability.


A business capability in general

A function is something to be done or to be achieved.

A capability is the ability to do or achieve something.


If a Function is mapped to cohesive group of required aims

And a Capability is the ability to meet a cohesive group of required aims.

Then the two concepts naturally align in a 1 to 1 correspondence.


If a Function is a cohesive group of required activities.

And a Capability is the ability to perform a cohesive group of required activities.

Then the two concepts naturally align in a 1 to 1 correspondence.


Both Functions and Capabilities can be composed and decomposed as architects and stakeholders see fit.

Both Functions and Capabilities may be mapped to drivers, goals, organisation units, processes, applications etc.


It is normal to define a function hierarchy and/or a capability map.

Such logical structures are supposed to be independent of physical structures.

But a logical function hierarchy and/or a capability map can be mapped to a hierarchical organisation structure.

In a so-called “functional organisation”, each business function is mapped to one organisation unit.


So, how to manage a federated capability?

If need be, a cross-organisational management body can be assembled to oversee the realisation of one capability by several organisations.


A business capability?

A business capability could reasonably be regarded as corresponding to an aggregate of:

·         one business function (a cohesive group of required activities) +

·         one or more goals to be achieved +

·         other architectural entities needed to realise the function and achieve the goal(s)


An application capability?

This table compares logical application components to business functions/capabilities, using TOGAF terms.



A logical application component in TOGAF

A business capability in TOGAF?


is decomposable into other application components

is decomposable into other functions/capabilities


meets requirements of the named application component

meets goals/objectives of the named function/capability


delivers information system services associated with that application component

delivers business services associated with that function/capability


employs the necessary structural resources

notably, some data entities and technologies

employs the necessary structural resources

notably, some organisation units, roles and applications


Implications for an EA framework meta model?

There is no need to include both business capability and business function in an EA meta model.

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

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

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.

Further reading

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

In comparing NAF and TOGAF terms and concepts, this paper exposes some differences.

Read these two papers on the home page at for more on TOGAF.

TOGAF principles - building blocks & services

TOGAF business functions, capabilities & value streams



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.