The TOGAF standard mapped to NAF

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 19/11/2017 00:02

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

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.

Contents

NATO Architecture Framework (NAF) 1

Capabilities in the armed forces. 1

Mapping NAF business architecture views to the TOGAF standard artefacts. 3

System theory concepts in NAF and TOGAF. 4

Mapping the TOGAF standard terms to NAF terms. 5

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

More…... 8

 

NATO Architecture Framework (NAF)

According to sources including this one <http://www.nato.int/cps/en/natohq/topics_54644.htm>

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.

Mapping NAF business architecture views to the TOGAF standard artefacts

The business architecture approach and artifacts in the TOGAF standard are based on “structured analysis”.

It takes 30 to 45 minutes in a training course to explain and illustrate this, but here are a few key elements.

 

Structured analysis defines at least one logical business function structure, independent of the organisation/management structure.

This function structure relates functions by composition and decomposition in a hierarchical “tree”.

Any function (at any level you choose) can be related in a matrix or diagram artefact to other architectural entities.

The breadth and depth of the analysis varies from situation to situation.

 

Functions <are related  to>

Other architectural entities

TOGAF artefact types

NAF views

Functions <provide>

Services  (the external view of a function)

Business service/function catalogue

Capability/Services mapping

Functions <are composed of>

Functions/activities (the internal view of a function)

Functional decomposition

Capability taxonomy

Capability/Operational activities mapping

Functions <serve>

Functions/external Roles (with information/material flows)

Node connectivity diagram

Capability Dependencies

Functions <trigger>

Functions (in sequential processes)

Process flow diagram

Process

Functions <are fulfilled by>

Organisation units (which perform activities)

Organisation/function matrix

Capability/Organisation deployment mapping

Functions <create and use>

Data entities

Data entity/function matrix

 

Functions <are served by>

Applications

Application/function matrix

 

 

You may be wondering – what aren’t functions related to goals?

For further discussion of business architecture, read Business architecture in TOGAF.

For more about the TOGAF standard, read Architecture levels, sevice-orientation etc.

System theory concepts in NAF and TOGAF

A system is bounded – distinct from the world outside the system.
The boundary across which things flow is often logical rather than physical.

Nothing in the universe is a bounded system until it is named and described as such.
When you look for them, describable systems can be found everywhere, interrelated, nested and overlapping.

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 has some structures that perform some behaviors to meet some aims.

A system can be described in terms of aims (why), behaviors (how and when), structures (who and what) and the locations where structures are found.

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

 

Business architecture concepts

General definitions

Aims

motivations for behavior

Goal or Objective

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

Behaviors

performances over time that change the state of a system or its environment

Service

a discrete requestable behavior that produces a desired result (output or effect), and is definable in a contract.

Process

a sequence of activities that leads to the provision of a service or other result.

Active structures

entities that perform behaviors

Function

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

Role

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

Organisation unit

a real world business division given the responsibility of fulfilling one or more logical functions.

Actor

a real world person or system given the responsibility of fulfilling one or more logical roles.

Passive structures

entities 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 a physical or logical entity or event, which is created and used in the course of performing behaviors.

Location

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 that whereas a human actor is a unique biological individual, a software actor is a replicable logical 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

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

 

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. (SEE NEXT SECTION)

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.

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.

System

A business capability

An application

Whole

corresponds to one named function

corresponds to one named application component

Parts

is decomposable into other functions

is decomposable into other application components

Aims

meets goals/objectives of the named function

meets requirements of the named application component

Behaviors

delivers business services associated with that function

delivers information system services associated with that application component

Structures

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.

More…

For further discussion of business architecture, especially capabilities and functions, read Business architecture in TOGAF.

 

 

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.