Business functions as capabilities

Copyright 2017 Graham Berrisford.

One of about 300 papers at Last updated 29/01/2017 19:24


International standards use the terms function and capability in different ways.

This paper is an attempt to pin the terms more securely to concepts, with reference to general system theory.


Business architecture concepts in general 1

TOGAF’s generic meta model 2

How TOGAF relates functions to capabilities. 4

Capability as an aggregate view.. 5

Capability-based planning. 6

Conclusion. 7

Footnote: On N-to-N associations between architectural entities. 7


Business architecture concepts in general

Enterprise architecture (EA) optimises and extends business activities that create and use data.

Enterprise architects respond to business plans, align changes with them, and sometimes influence them

They draw up high-level designs and plans for changes to the three architecture domains in the table below.


Business Planning

Business mission, vision, drivers, strategies and goals.

Mergers, acquisitions, divestments and internal organisation restructurings.

Enterprise Architecture 

(Business Systems Planning)



Business functions/capabilities, roles, processes/value streams and their interrelationships.

The services they provide to each and to entities in the business environment.

Information System


Applications and their interrelationships

The services applications provide to each other and to business activities.

Data stores and data flows, the data structures they contain and the qualities of that data.



Platform technologies and their interrelationships

The services technologies provide to each other and to business applications.


Enterprise architects take a cross-organisational and strategic perspective of the three architecture domains.

They govern lower level solution, software and technical architects working on specific programmes and projects.


EA regards the enterprise as a system.

This table defines some general system theory concepts and illustrates their application in business architecture approaches.

It distinguishes structures from behaviors, and abstract structures from concrete ones.

System theory

Business architecture in BIZBOK®

Business architecture in TOGAF®

Abstract structure node

groups required behaviors/actions


Function, Role

Concrete structure node

is assigned to perform behaviors/actions

Organization unit, Actor

Abstract behavior

sequences required behaviors/actions

Value stream: steps in value creation/delivery

Scenario, Process: steps in service creation/delivery

Abstract action

is an atomic behavior

Process step

Abstract system structure

the network in which nodes interact

Capability/Outcome Network:

Flows between Capabilities.

Node Connectivity Diagram:

Flows between Nodes


EA is about business capabilities that require all of the elements in the table above.

The use of different terms can obscure the generality of the concepts being described.

It helps to recognise where terms relate to the core concepts of general system theory.


Business Processes are logical sequences of process steps, which run from start to end.

You can recursively decompose process steps until you reach elementary processes (aka activities).

In theory (though the practice is rare) you can place every elementary activity at the bottom of a functional decomposition hierarchy.


Business Actors are individual structural components in the organisation structure, each able to perform activities.

An individual human is an actor (as opposed to the abstract active structure element called role).


Business Roles are activities grouped such that they can be assigned to individual actors.


Business Organisation units are nodes of a management structure, each with a manager and resources to perform functions.

You can recursively decompose the organisation structure until you reach human actors.

An individual organisation unit can also be seen as an actor (as opposed to the abstract structural element called function).


Business Functions are logical groups of activities that can be assigned to organisation units.

You recursively decompose functions until you reach elementary functions.

Why draw a logical functional decomposition hierarchy? (Also known as a capability map).

Because it gives you a central EA artefact, explainable to business people, to which other things can be mapped.

This enables you decouple the EA documentation from the volatile organisation structure, in which units are rearranged, and actors come and go.

A generic meta model

This table maps terms commonly used in enterprise architecture to a general structure.

The table is simplistic; you can learn much more in this TOGAF-ArchiMate alignment slide show.

Required behaviours

assigned to

Logical structures

realised by

Physical structures

Run over time

Encapsulate or group behaviours

Do work



Business Services

& Processes


Organisation Units




Scenarios & Value Streams



IS Services

Logical Application Components

Physical Application Components


Application Services

Application Interfaces (or Functions)

Application Components


Use Cases & User Stories

User Interfaces



Platform Services

Logical Technology Components

Physical Technology Components


Technology Services

Technology Interfaces (or Functions)

Nodes: System Software & Devices




Specification by encapsulation of capabilities, systems or components is a fundamental principle.
Service-oriented specification has been a principle of The Open Group since it was formed, and underpins TOGAF.

You can specify a Logical Component by naming it and specifying its Interface, which means listing the discrete Services it offers in its “service portfolio”.

·         A "Logical Technology Component" is specified by the "Platform Services" it offers.

·         A "Logical Application Component" is specified by the "Information System Services" it offers.

·         A business “Function”, “Capability" or “Role” can be specified by the "Business Services" it offers.


EA documentation is usually centred on a logical functional decomposition hierarchy or capability map.

This decouples the logical architecture from the organisation’s management structure.

These additional indirect associations valid, but rarely documented in EA due to the volatility of organisation structures and employees.

·         Business Services/Products <are produced by>Organisation Units

·         Organisation Units <employ>Actors

·         Processes <are performed by> Actors.


One more association, Business Services/Products <are assigned to> Functions, is relevant.

Since Functions can be defined externally by the Services they offer and internally by the sub-Functions they contain.

How TOGAF relates functions to capabilities

This section outlines four principles that underpin TOGAF and its artefacts, and relate functions to capabilities.


Principle 1) processes are flows of activities. Functions group the same activities under a structure. (34.2.1)

Activities shown as elementary business processes (EBPs) may be placed at the bottom of the functional decomposition.


Principle 2) functions/capabilities are defined by services provided

“The purpose of the business service/function catalog is to provide a functional decomposition…

[It] can be used to identify capabilities of an organization…. “(35.6.3)


Business architecture outputs (8.5) include

·         “Business functions — a detailed, recursive step involving successive decomposition of major functional areas into sub-functions.”

·         “Correlation of organization and functions — relate business functions to organizational units in the form of a matrix report.”


In “structured analysis”, in theory, every elementary activity in a process can be placed at the bottom of a functional decomposition hierarchy

In practice the function hierarchy usually stops at a high (3rd or 4th) level, and some process models descend to a lower (5th or 6th) level.


Principle 3) functions are used to describe capabilities

TOGAF says:

·         capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. For example, marketing, customer contact, or outbound telemarketing.” [i.e. the names of functions] (3.26)

·         “function describes units of business capability at all levels of granularity” (34.2.1)

·         “This functional decomposition can be used to identify new capabilities required to support business change.”

·         “The purpose of the functional decomposition diagram is to show on a single page the capabilities of an organization…. “ (35.6.3)


Implication: functions have all the attributes capabilities have - including target qualities


Principle 4) functions/capabilities are defined independently of organisation units

Chapter 32 on capability-Based Planning makes ten references to capabilities being cross-organisational.

Both structured analysis and capability-based planning encourage architects to identify business objectives and required services.

And decompose functions/capabilities into activities before mapping those to organisation units.

capability-based planning is about improving a named function (say, Sales or HR) regardless of which organisation units it is carried out in.


Structured analysis “Identifies the key business functions within the scope of the architecture, and maps those functions onto the organisation units within the business.” (8.4.1)

Business architecture outputs include

·         “Correlation of organization and functions — relate business functions to organizational units in the form of a matrix report.” (8.5)

·         Organization unit:  “A self-contained unit of resources with goals, objectives, and measures.” (34.2.1)


One function/capability may be mapped to one organisation unit, several organisation units, or parts of several.

Those organisation units inherit some or all of any target qualities given to functions/capabilities.

Capability as an aggregate view

Consultants often reinvent business modelling concepts using different names.

For some years now, the relationship between capability and function has been debated.


A required capability can be specified as measureable products or services resulting from processes performed by roles/actors/components.

A required function can be specified as measurable products or services resulting from processes performed by roles/actors/components.


One can imagine replacing all function by capability, and then replacing all functional decomposition by capability decomposition.

But I don’t think it wise, since people use both terms (function and capability) and it would be better to have a coherent way of relating them.

So what to do?


Some use the term capability as a label for top-level functions, which is to reinforce their conceptual similarity

And to introduce arbitrariness, since the topmost function in one person’s scope might be below the top in another person’s scope


Suppose you want terms that are independent of the level of granularity you are working at, and consistent with TOGAF?

Then you can reduce function to the name of the node in the functional decomposition hierarchy.

And use capability for the totality of the function, products or services resulting , processes performed and roles/actors/components employed/deployed.

In short, the recommendation is that Capability = Function + Target Qualities + Resources Needed.


The proposal here is that capability is not a singular architectural entity.

A capability is a view of, or aggregate of, the entities in an enterprise architecture meta model.

Capability = a combination of processes, people and technologies that deliver desired effects.

Capability = a logical encapsulation of those parts of an enterprise or system that deliver required products or services.


A capability is a view rooted in a function (at whatever level of granularity is chosen).

It can encompass as many of the remaining entities as you consider necessary to the capability

In business architecture documentation, capability (say Marketing) = function (Marketing) + quality targets + resources needed


Some capabilities correspond to a function in the primary functional decomposition hierarchy (usually a high-level function).

Other capabilities (e.g. “Disaster handling”) might not appear in the primary function hierarchy.

But you can define several function hierarchies and/or define functions independently of any hierarchical decomposition structure.

In short, a capability is always representable as a function + target qualities + resources needed.


A capability can be seen as a required function + aims + activities and resources needed to deliver the effects desired of the named function.

A capability is an aggregate concept that corresponds to a business function, but is more than a business function.
Or else, it is a transient kind of business function, an endeavour, programme or project to achieve some desired effects.

Either way, capability is a compound concept (rather than singular entity for which ArchiMate and UML symbols have been defined).

Capability-based planning

Capability-based planning is the planning of projects or other endeavours to provide capabilities as defined above.

It provides a context for EA, but the scope of capability-based planning can be much wider.

EA can inform capability-based planning, and elaborate on some parts, but is not responsible for all of it.


Consider marketing, sales, conduct/win a war, counter terrorism, disaster recovery.
All could be the names of capabilities/business functions that managers want capability-based planning improve.
They are typically cross-organisational, but might not be.

What about a more abstract function/capability such as  'continuous improvement'?
Planning for continuous improvement would proceed

1.      define the desired effects to be achieved, and how they will be measured (say by appraisal at CMMI level 5).

2.      define the products/services/outputs needed to achieve 1.

3.      define the processes and activities to produce 2

4.      define the resources needed to perform 3


Which is to follow the normal business system design process (as per conventional system theory, since forever and a day).


Business functions are abstract active structural elements.

They are logical abstractions from real organisation units, and if defined by services offered, can be seen as interface definitions.


Business capabilities correspond to business functions.

But the term capability often implies the function + goals + human and other resources needed to realise the function.

Which is to say – a capability is a business system.

Footnote: On N-to-N associations between architectural entities

Most meta model entities (e.g. Components, Processes, Services and Goals) are composable and decomposable.

Recursive composition and decomposition of these elements means that most associations between them are N-N.


Every Process is a procedural flow that terminates by delivering a result - which is the Goal of the Process.

So every Process has a Goal; that is not a choice you make as an architect or designer, it is a fact of life.


Every Process can be encapsulated by a Service contract (which defines inputs, outputs, pre and post conditions)

So every Process provides a Service; that is not a choice you make as an architect or designer, it is a fact of life.


But those 1-to-1 associations are only a part of the story.

You may choose to relate Services and Processes 1-to-1 in a model you build, but in general,

·         1 higher-level (coarse-grained, long-running) service can be realised/supported/enabled by N lower-level (finer-grained, shorter-running) processes.

·         1 higher-level (coarse-grained, long-running) process can be realised/supported/enabled by N lower-level (finer-grained, shorter-running) services.

So the association is N-to-N.


You can compose and decompose Processes, Goals and Services to your heart's content.

So 1 Process may meet several Goals, and 1 Goal may be met by several Processes.

1 Process may deliver several Services, and 1 Service may require several Processes.

And in a general meta model, Processes, Services and Goals must be related by N-to-N associations.


The same applies to associations between Functions and Services, Functions and Organisation units, etc.



All free-to-read materials at are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to in whichever social media you use.