Mapping TOGAF to Nato Architecture Framework (NAF)

With a focus on “Capability”

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 are taken from this source.

Contents

EA in general 1

EA in the armed forces. 1

A simple mapping of NAF v.3 to TOGAF 9.2. 1

On the various concepts called “capability”. 1

Some notes on NAF v3. 1

A more detailed mapping of TOGAF to NAF. 1

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.

Concepts used in the documentation of business activity systems

Enterprise and business architecture are concerned with the services provided by a business

And with how those services are delivered by processes that refer to and advance the state of the business.

This paper focuses on the modelling of business activities rather than business data.

You don’t have to model every business activity that could possibly be documented.

You model what you need to understand, then choose what to communicate to others - simplifying as need be.

Imagine however that you were asked to analyse everything a business does in its regular operations.

And you begin by listing all the atomic activities that are regularly performed by the actors in the business.

Where atomic means the shortest activities that you consider worth identifying and naming.

It is possible to define other business architecture entities in terms of those activities.

For example, the table below maps the definition of business architecture in TOGAF 9.2 to its business architecture entities.

Then defines each entity in terms of how it groups a selection of business activities.

Business architecture in TOGAF 9.2	Entities	Definable in terms of activities thus
“Business operations,	Processes and Roles	A process sequences activities that lead to a result of value (spanning one or more organisation units). A role groups the activities that one actor is responsible for performing (in one or more processes).
“factors that motivate the enterprise ,	Goals	A goal is a motivation for one or more activities
“how the enterprise is organizationally structured	Organization units	An organisation unit is accountable for the performance of a selection of activities.
“and what functional capabilities the enterprise has”	Business functions and Capabilities	A business function groups activities that are cohesive in some way(s) to be discussed below. A capability is the ability to perform a group of activities that are cohesive in some way(s) to be discussed below.

EA and BA regard the enterprise as a system definable in terms of actors (in roles and organisation units) performing activities (in processes) to meet aims (or goals) of the business.

(For other things implied by general system theory, see EA as applied system theory.)

EA in the armed forces

The armed forces are a peculiar kind of business.

A standing army must train and prepare itself to do things it might never actually have to do.

The peace-time organisation must develop the capability to achieve some specific goal(s) yet to be declared.

The mission-time organisation may draw resources from several peacetime organisations to achieve some specific goal(s).

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 are used somewhat differently in other sources and methodologies concerned with regular business operations.

On the other hand, the armed forces are like other businesses in many ways.

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

A simple mapping of NAF v.3 to TOGAF 9.2

This table presents a simple mapping.

System theory

NAF terms

TOGAF standard terms

Levels of

abstraction

Functionality

Construction

Implementation

Requirements

Logical components or Architecture Building Blocks

Physical components or Solution Building Blocks

Aims

Operational objective,

Business rule, Information requirement

Goal, Objective,

Requirement

Behaviors

Service

Operational service, Information service, Application service

Process

Service,

Business service, IS service, Technology service

Process, Value Stream 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

Location

Data Component, Data Entity

Location

The following sections present a more detailed analysis, beginning with some discussion of “capability”.

On the various concepts called “capability”

Dictionaries (surveyed in writing this) typically define a capability as “the ability to do something or to achieve something”.

In other words, the ability to perform one or more activities and/or meet one or more aims.

A business system may be observed in operation as a set of actors performing some activities to meet some aims.

An ordinary business needs the ability to perform activities such as “sales”, “disaster recovery” or (much more fine-grained) “wheel replacement”.

The armed forces need the ability to do such things as “win a battle”, or “rescue friendly forces from enemy territory”.

A dozen definitions of “capability” referred to in DoDAF are listed and analysed in The science of business architecture.

The definitions are not entirely consistent.

Two of them limit the concept of capability by relating it to a "course of action" - which is to say, a process or service.

By contrast, when used by the military, the term capability can refer to concrete set of human and technological resources.

Suppose we discard outlying definitions of capability.

Here is an attempt to draw a consensus definition from those in DoDAF and NAF.

· A capability is an ability (of actors) to perform activities, achieve aim(s) or provide service(s).

· It is an ability that is abstractly defined, whether for development or use.

In DoDAF, an aim is called “a desired effect” meaning “the result, outcome, or consequence of an action”.

It defines “capability” as “the ability to achieve a desired effect under specified standards and conditions through combinations of ways and means to perform a set of activities.”

But singular associations (like 1 capability to 1 desired effect) are always questionable, and can be needless constraints.

If capabilities/abilities are composable and decomposable, then desired effects and activities must also be composable and decomposable.

Better, NATO’s Architecture Framework defines “capability” as “the abilities required for conducting operations in order to reach desired effects”.

Here, 1 capability relates to one or more desired effects.

Abstract capabilities as functions

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

To begin with, a capability can be named abstractly as activities to be performed or aims to be met.

E.g. MoDAF speaks of an abstract capability as akin to a goal such as “Manned Interplanetary Travel”.

And TOGAF defines an abstract capability independently of people, processes, data and technologies – much as a business function might be defined.

An abstract Capability is a general attribute of one or other business architecture entity – a Goal, Service, Function or whatever.

Concrete capabilities as systems or managed entities

A concrete Capability is an aggregate entity - the whole of a system or subsystem - including all its resources and processes.

DoDAF speaks of a capability as entity that "occupies space and time" - a physical business system in operation, using a set of resources.

It embraces every resource required to perform required activities – knowledge, skills, energy, materials and other resources.

The resources may include people, machines, computers, databases, networks, and procedures that actors must follow.

Might they even include people trained to find whatever resources they need to achieve ad hoc aims?

Some speak of a capability as though it acts – it is the actors or resources that have the ability to act.

But that is to equate a business capability with a business system – a system of actors performing activities to meet aims.

Or possibly a managed entity - an organisation unit or project.

Mapping capabilities to aims and other things

EA frameworks typically define a business architecture in terms of actors in roles, activities in processes and aims or goals.

This table shows the capability concept can be attached to those and other entities in the TOGAF business architecture set.

Business architecture in TOGAF 9.2	The business needs
“Business operations,	The Capability to play each The Capability to perform each	Role Process or Service
“factors that motivate the enterprise,	The Capability to meet each	Goal
“how the enterprise is organizationally structured and	The Capability to manage each	Organization unit
“what functional capabilities the enterprise has”	The Capability to realise each	Business function

So, here is a hypothesis about business architecture:

Everything classified by one modeller as the name of a capability might - alternatively - be classified by another modeller as the name of a goal, role, service, process, function or organisation unit.

In short, the concept called "capability" is a chameleon, which different people attach to different ideas- – a Goal, Service, Function or whatever.

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

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

But makes it difficult to pin down its meaning and its relationships to other architectural entities.

So, introducing it into a meta model of business architecture entities is problematic.

For more analysis, read The science of business architecture.

Some notes on NAF v3

This paper compares terms and concepts in NAF and TOGAF 9.

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

The update above has no significant impact on the more general points made in this paper.

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 save lives, resources and improve collaboration between nations.

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

You may find this of interest <http://www.nato.int/cps/en/natohq/topics_54644.htm>.

The NNEC has since 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.

Federations can mean

· distribution of control (as in “a group of states with a central government but independence in internal affairs”).

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

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.

A more detailed mapping of TOGAF to NAF

There are some reasonably good matches and some mismatches.

TOGAF	NAF	NAF DEFINITION
	LEVELS OF ABSTRACTION
Required behaviours: services and processes.	Functionality	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.	Construction	how the functionality should be constructed: may refer to technology types, but not actual technology products.
Physical structures: organization units, actors, physical components.	Implementation	what solution is implemented: including actual technology products and the consequences of their adoption.
	MOTIVATION ELEMENTS
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.
	REQUIRED BEHAVIORS
Service	Service	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 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	Process	a composition of activities that are triggered by an event and transforms a specific input into a meaningful output.
	ACTIVE STRUCTURE ELEMENTS
Role - in connection with an application	User	a person or a group of persons representing one or more actors using the same functionality of an automated application.
Role or Function	Actor	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?	Capability	the ability to deliver a specified type of effect or a specified course of action.
Architecture Building Block in the Application and Technology domains	Component	the logical construction element of an elementary application service.
Logical application component or Logical technology component	Application component	a software component. (INCLUDES PLATFORM TECHNOLOGY APPLICATIONS)
Logical technology component (hardware only)	Technical infrastructure component	a hardware component. (EXCLUDES PLATFORM TECHNOLOGY APPLICATIONS)
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.
	PASSIVE STRUCTURE ELEMENTS
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.
Location	Location	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.