Mapping TOGAF to Nato Architecture Framework (NAF)

With a focus on “Capability”

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 02/08/2018 14:55

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, there is now a newer paper on business functions and capablities in TOGAF.

Contents

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

Further reading. 9

 

EA in general

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

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

·         products: products and services, sales and service channels

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

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

 

Business system planning addresses the structures and behaviors of regular business operations.

A business system is composed of some actors interacting to perform some repeatable activities to meet some given aims.

Business system planning is given direction by business planning, and also informs it.

 

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

Processes

“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

Wikipedia (11/4/2018) defines a capability as “the ability to perform or achieve certain actions or outcomes.”

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

By definition, a capability is in 1-to-1 correspondence with something to be done or achieved.

 

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

So, a business capability could be the ability to:

·         perform a business process (at a chosen level of decomposition)

·         perform the activities grouped into a business function or role (at a chosen level of decomposition)

·         perform the services required of an organization unit (at a chosen level of decomposition) or

·         achieve a goal, objective or purpose (at a chosen level of decomposition).

 

Capability-based planning must proceed by defining resources with the required capability.

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

(Resources 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. For example:

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

Which is to equate a capability with a system, since.

·         A business system is composed of some actors interacting to perform some repeatable activities to meet some given aims.

 

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

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

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

The flexibility of the term makes it appealing and convenient in discussion with business people.

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

 

Conclusion: different capabilities may be related to different, or all, entities in an EA meta model.

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

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

Aim

Business goal

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

Software requirement

Behavior

Business service

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

Application service

Process

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

Application process

Abstract structure

Role

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

Application interface

Business function

Concrete structure

Actor

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

Application component

Organisation

 

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

roles

are specified as acting in

activities (aka tasks or sub processes).

In concrete operation

actors

realise the roles

by performing the activities.

Business applications

In logical specification

applications

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

Business Services

Business Processes

Business Functions

Roles

Organization Units

Actors

Information Systems

Application/IS Services

Logical Application Components

Physical Application Components

Technology

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

Service

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.

Process

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

Function

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.

Role

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.

Actor

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 <http://www.nato.int/cps/en/natohq/topics_54644.htm>

 

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

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

Location

Data Component, Data Entity

Location

Mapping TOGAF 9.1 standard terms to NAF v.3 terms

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

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.

Further reading

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

Many other related papers can be found on the home page at http://avancier.website.

 

 

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.