Functions need capabilities

Resolving the confusion in EA/BA standards

Copyright 2017 Graham Berrisford. One of about 300 papers at Last updated 24/05/2019 14:23

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 papers based on analysis done for the British Computer Society (in research for their professional certificates in enterprise and solution architecture).


Every function needs the corresponding capability. 1

Value streams as end-to-end processes. 3

Conclusion: some things to remember 5


Every function needs the corresponding capability

Managers define organisation hierarchies.

Organisation units are managed groups of actors and activities (physical business components).

Functions/capabilities are logically cohesive groups of the activities/abilities required of an organisation (logical business components).


A function/capability hierarchy may correspond to or clash with the organisation hierarchy (aka management structure).

They correspond in a *functional organisation*.

They clash where the management structure is divided in other ways, e.g. by location, product type or customer type.


Why (since the 1980s) do EAs/BAs draw a logical function/capability hierarchy?

·         To define the activities/abilities of a business in a way that is more stable than and independent of the organisation chart.

·         To assist in discussion of business scope and change.

·         To classify other EA/BA entities - roles, processes and resources.


Function? Capability? What is the difference?

Piano playing can be read as the name of a function (an activity) and of a capability (an ability).

What delivers value to consumers? Is it the piano playing or the piano player? It is both.

The piano player must a) have the ability and b) use that ability to perform the activity.

Now replace “piano playing” by “marketing” or “disaster recovery” and “piano player” by “actors”.

Marketing and disaster recovery can be the names of functions and/or capabilities


After 10 years of asking, I gave up asking people to show me a capability map that differs in appearance or use from a function hierarchy.

In practice, the two diagrams look the same and all have the same possible uses.

Function hierarchies are used for heat mapping, exactly as capability maps are.


Functional Decomposition Diagram (quoted from TOGAF 9.1)

Capability Map

Shows on a single page the organization capabilities relevant to the architecture to be defined and governed.

Helps to quickly model the organization’s capabilities without being dragged into debate on how the organization does it.

Given a basic diagram, it is possible to layer heat-maps on top of it to show scope and decisions.

For example, the capabilities to be implemented in different phases of a change program.

Shows on a single page the organization capabilities relevant to the architecture to be defined and governed.

Helps to quickly model the organization’s capabilities without being dragged into debate on how the organization does it.

Given a basic diagram, it is possible to layer heat-maps on top of it to show scope and decisions.

For example, the capabilities to be implemented in different phases of a change program.


Many misunderstand what a business function is - as in "structured analysis" since the 1980s, and presumed knowledge in TOGAF since version 8.


Imagine all the different atomic activities of a business were listed (they rarely are).

Other architecture entities can be defined in terms of those activities.

·         An organisation unit has a manager who is held accountable for the performance of some of those atomic activities.

·         A process is a sequence of atomic activities that may span several organisation units, functions or capabilities.

·         A business function is a unique group of atomic activities that are cohesive in some way(s) other than sequence.

·         A capability is the ability to perform a group of atomic activities that are cohesive in some way(s).


The ability to perform covers all that is required – knowledge, skills and resources.


Functions and capabilities may be recursive composed and decomposed in hierarchical structures.

At each level of definition in a hierarchy, to realise a function requires a corresponding capability (1 to 1).

So, a function hierarchy necessarily corresponds to a capability hierarchy.


Functions/capabilities are usually arranged in hierarchies decomposed to 3 or 4 levels.

The hierarchy subdivides the activities/abilities of business into relatively discrete units.

A function is supposed to be cohesive internally and loose-coupled externally.


Functions/capabilities can be mapped to behaviors/processes.

Lower level functions (say at a 3rd level) can be mapped to the stages of topmost behaviors (aka value streams).

Functions are rarely decomposed to atomic (say 6th level) activities.

But when they are, those activities may be more formally sequenced in bottommost behaviors (aka procedures).


Functions/capabilities can be mapped to organisation units.

A function can be seen as a logical organisation unit, much like a role can be seen as a logical actor.

A function can be seen as an abstract type realised by one or more individual organisation units.

Much like a role can be seen as an abstract type realised by one or more individual human actors.


Functions/capabilities can be mapped to applications and other resources they need.

The term function is used with different meanings in the application domain/layer

Sometimes it is a process (as in UML) and sometimes it is a logical application component.


Some or all of the function-oriented artefacts in the table below could equally be used in capability-oriented modelling.


Functions <are related to>

Other architectural entities

Artifact discussed in TOGAF

NAF views

Functions <provide>

Services (the external view of a Function)

Business Service/Function catalogue

Capability/services mapping

Functions <are composed of>

Functions (the internal view of a Function)

Functional decomposition

Capability taxonomy

Capability/Operational activities mapping

Functions <serve>

Functions or Roles (with information/material flows)

Node connectivity diagram

Capability Dependencies

Functions <trigger>

Functions (in sequential processes)

Business scenario; Process flow diagram


Functions <are realised by>

Organisation units

Business Interaction (Organisation/Function) matrix

Capability/organisation deployment mapping

Functions <create and use>

Data entities

Data entity/Function matrix


Functions <are served by>


Application/Function matrix



It is crazy to include functions and capabilities as distinct entities in a meta model of architecture entities

Because they both have the same relationships to other entities.


Beware naming lower level functions/capabilities "services".

In Archimate and TOGAF, service is supposed to be a different concept.

It is a discretely requestable behavior, rather than a node in a structural decomposition.

Value streams as end-to-end processes

The term value stream is not new

It has usually been defined as end-to-end business process.

·          a sequence of activities an enterprise undertakes to deliver on a customer request.”

·         an end-to-end collection of activities that create a result for a ‘customer’ who may be the ultimate customer or an internal ‘end user’ of the value stream” Martin (1995).


The table below contains the names used to label value streams in different sources.


Cash management

Inventory management

Environmental liabilities

Hire to retire

Procurement to disposal

Deploy to re-deploy/discard

Prospect to order

Order to cash

Procure to pay

Book airplane seat (journey definition to ticket)

Book holiday (enquiry to booking confirmation)

Claim processing (complaint to refund)

Open a bank account.

Set up a direct debit to pay bills.

Withdraw cash from the account.


The name of a thing doesn’t always reveal whether it is a behavior/process or a structure/function.

Some examples named in the table above don’t sound like a values stream, since they don’t suggest an end-to-end flow.

However, there is no prescription about where a value stream starts or ends, or who its customer is.


TOGAF's generic process concept is infinitely composable and decomposable.

So, you can see “value streams” as corresponding to high-level processes or business scenarios.


Process Flow Diagram (as in TOGAF 9.1)

Value Stream Diagram

Given a product or service of value to be delivered, this presents the necessary activities/steps in sequence.

It may show for the process and each step

·         Trigger events

·         Outputs, and

·         Controls/rules (pre and post conditions).

It may use swim lanes to represent owners, roles or resources associated with process steps.

It can help subject specialists to describe ‘‘how the job is done’’ for a particular function.

Given a product or service of value to be delivered, this presents the necessary activities/stages in sequence.

It may show for the stream and each  stage

·         Objectives and Roles involved

·         Entry criteria: including trigger events

·         Exit criteria: including products generated.

It may associate owners, roles and capabilities with each value stage.

It can help subject specialists to describe ‘‘how the job is done’’ for a particular capability.


Every process has a goal; it is a procedure that terminates in a result of value to some actor or future process.

A whole value stream and each stage within it may be defined in terms of:

·         Aims: achievement , purpose and value added

·         Roles: actors engaged in the value stream/stage

·         External view: encapsulation of the value stream/stage by entry and exit conditions  (as in service contract)

·         Internal view: internal activities (which implies a further level of process decomposition).


A process is a process, be called a business scenario, use case or value stream, or encapsulated behind a service contract.

It is possible to use the same template to document any value stream/stage, process or use case.


“Value stream mapping”

"A lean-management method for analyzing the current state and designing a future state for the series of events that take a product or service from its beginning through to the customer."

At Toyota, it is known as "material and information flow mapping".

One convention is to draw value-adding steps are drawn horizontally across the centre of the map, and draw non-value-adding steps in vertical lines at right angles to the value stream.


“Value stream analysis”

This (again after Lean I believe)  involves measuring process steps, and optimising the process in the light of those measurements.

This might be done in the course of what TOGAF calls business scenario analysis.


Aside on “value chain”

A Porter-style value chain diagram can be read as a first-level functional decomposition, with a hint of end-to-end process.

The value chain concept is usually expressed in a very high, top level, model of an enterprise.

·         a [disaggregation of] a firm into its strategically relevant activities in order to understand the behavior of costs and the existing potential sources of (competitive) differentiation” (Porter, 1985).

·         a high-level orientation view of an enterprise and how it interacts with the outside world. In contrast to the more formal functional Decomposition diagram developed within Phase B (Business Architecture), the Value Chain diagram focuses on presentational impact. TOGAF


Porter’s famous value chain diagram is a compromise between a structural decomposition and process flow.

TOGAF’s “more formal functional decomposition diagram” represents a logical organization structure, with no hint of process flow.

In conclusion, some things to remember

For more detailed research, backing up the above, read


Granularity of system elements

·         The elements in a system model can be composed and/or decomposed according to the scope of the endeavour, and the level of detail required.

·         “The level and rigor of decomposition needed varies from enterprise to enterprise” (TOGAF 9) and from project to project.


Functions (cf. capabilities)

·         A function hierarchy is a logical structure imposed over business activities; each function is a cluster of lower-level functions or atomic activities.

·         A Porter-style value chain diagram can be read as a first-level functional decomposition diagram, with a hint of end-to-end process.

·         A function decomposition hierarchy is independent of the real organisation structure (though they can be aligned in a “functional organisation”).


Processes (cf. value streams)

·         Process flows are sequential or behavioral views of the same atomic activities that are grouped into functions.

·         Longer (end-to-end) processes often coordinate functions (or more accurately, coordinate specific activities with those functions).

·         Shorter processes tend to be contained within a function - but it depends on the level of function decomposition.


Realisation of functions/capabilities and processes

·         Organisations units realize functions/capabilities - by performing activities and demonstrating abilities.

·         Organisation units need the capability to realize a function.

·         The function and capability concepts are widely confused because every function needs a capability (1 to 1)



·         The primary meaning of service in TOGAF (from v1 days) is a requestable behavior, as defined in discrete service contract.

·         The recommendation is to define service contracts that encapsulate/hide internal processes.

·         Beware! Business managers use the term service for what might be scoped in a service level agreement, which may list many discrete services.