The TOGAF standard mapped to “Capabilities” in NAF

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 15/10/2017 22:26

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 addresses difficulties people have with the concepts of “application” and “capability”.

Contents

NATO Architecture Framework (NAF) 1

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

System theory concepts in NAF and TOGAF. 2

Mapping the TOGAF standard terms to NAF terms. 4

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

 

NATO Architecture Framework (NAF)

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.

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.

 

NAF is an architecture framework for defining the people, processes and technologies involved in NATO’s Network Enabled Capability (NNEC).

This source (http://www.nato.int/cps/en/natohq/topics_54644.htm) says the NNEC has been merged into the Federated Mission Networking, but its aim remains.

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.

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 The TOGAF standard mapped to Capabilities in Business Architecture.

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.

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.

 

An application is often called a system.

It exists in two forms, at design time and run time.

It has some structures that perform behaviors to meet some aims.

 

A capability can also be seen as system, usually bounded logically rather than physically.

NAF is inconsistent in its use of the term capability (as other sources are).

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 about capability functions

For more on capabilities and functions, read also The TOGAF standard mapped to Capabilities in Business Architecture.

For example, consider the following notes and questions arising, in which you can replace all capability by function.

 

How to form a capability?

A capability is a cohesive group or cluster of lower level or elementary capabilities.

The criteria for clustering capabilities are typically:

·         sharing the same or related goals

·         producing the same or related products/services

·         performing the same or related activities.

 

The common practice is to define one primary capability map – down to 3 or 4 levels.

You can draw different maps – especially where different executives set different goals for an enterprise.

 

When and where to document the features of a capability?

Capabilities that begin as abstract architecture elements morph into organisation units with physical resources (much as roles morph into actors).

In defining the concept of “capability”, authors often include concepts associated with their implementation.

In a simple case, one capability relates to one organisation unit (as in a “functional organisation”), so you might say they share the same and relationships.

But if the relationship is many-to-many, you have to consider when, where and how to record the attributes and relationships of each.

 

For example: consider how to relate goals to capabilities and organisation units.

If you relate goals to a capability, then you have to consider what that means in the real-world business.

In the end, directors must assign goals to the managers of the organisation units that fulfil that capability using resources (men, materials and machinery).

Instead (like TOGAF) you could take a service-oriented view and attach goals to business services.

Then presume those goals are inherited by capabilities and organisation units that provide the services.

 

 

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.