What is a Capability?

With a comparison of TOGAF 9.1 to NAF

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

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

Contents

What is a Capability?. 1

EA in general 2

EA in the armed forces. 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. 8

Further reading. 9

 

What is a Capability?

The term capability is used freely by business people, and is popular in management consulting and enterprise architecture practices.

“A capability is the ability to perform or achieve certain actions or outcomes.” Wikipedia, 11/4/2018

 

A capability is a pulling together of whatever is needed to do or achieve something.

What is pulled together may include any or all of human actors, machines, computers, databases, networks, and procedures that actors must follow.

 

A capability is associated 1-1 with the thing to be done or achieved.

The capability to achieve a goal or outcome is in 1-1 correspondence with it.

The capability to perform a business process or to complete a project is in 1-1 correspondence with it.

The capability to realize a business function (or deliver services to a service level agreement) is in 1-1 correspondence with it.

 

Capabilities are not mutually exclusive.

Some of the capability needed to do/achieve one thing can also be part of a different capability to do/achieve another thing.

 

A capability might be assembled in an ad hoc way.

It might include people sufficiently able and well-trained they are expected to acquire whatever else they need to do /achieve the thing – if and when needed.

 

In other words, capability is a chameleon, fitted to the thing that must be done/achieved.

It is not an entity type like the many more specific entity types it may pull together.

It is a looser aggregate concept - composed of different things on different occasions. It could be a system involving everything else in an EA meta model.

Conclusion: each capability is a particular view of an EA meta model rather than an entity in it.

 

What about what people call a business capability?

A business capability is the ability to do something or achieve one or more outcomes.

A business process is sequence activities that lead to an outcome.

A business function encapsulates activities to achieve several outcomes.

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

 

A business capability is often contrasted with a value stream, much as a business function is contrasted with a business process.

And in practice, business capability maps resemble functional decomposition diagrams so closely that their appearance, purpose and practical use are the same.

Conclusion: a business capability may reasonably be defined as the ability to realize a business function.

 

However useful the term “capability” is in management consulting and enterprise architecture practices, it is not well placed as distinct entity in the meta model – in addition to business function and process.

 

What about what people call an application capability?

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

 

System

A business capability in TOGAF?

A logical application component in TOGAF

Parts

is decomposable into other functions/capabilities

is decomposable into other application components

Aims

meets goals/objectives of the named function/capability

meets requirements of the named application component

Behaviors

delivers business services associated with that function/capability

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

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.

 

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.

 

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

 

General system ideas

Business system ideas

Defined in terms of business activities

Aim

Business goal

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

Behavior

Business service

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

Process

A behavior that sequences activities.

Abstract structure

Role

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

Actor

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

Organisation

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

Aim

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.

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

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

Business Processes

Business Functions

Organization Units

Business Activities

Roles

Actors

Information Systems

Use Cases

Logical Applications

Physical Applications

Technology

Platform Services

Logical Technologies

Physical Technologies

 

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

Service

a discrete requestable behavior that produces a result of value to a consumer, describable in a contract that encapsulates internal processes

Process

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

Function

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

Role

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.

Actor

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.

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.

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

Read these two papers on the home page at http://avancier.website 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.