Business functions as capabilities
Copyright 2017 Graham Berrisford.
One of about 300 papers at http://avancier.website. 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.
Contents
Business
architecture concepts in general
How
TOGAF relates functions to capabilities
Capability as an aggregate view
Footnote:
On N-to-N associations between architectural entities
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 Architecture |
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 Architecture |
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. |
|
|
Technology Architecture |
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.
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 |
Capability |
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.
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 |
|||
|
TOGAF & ArchiMate |
Business Services & Processes |
Functions |
Organisation Units |
||
|
Roles |
Actors |
||||
|
Other |
Scenarios & Value Streams |
Capabilities |
|||
|
TOGAF |
IS Services |
Logical Application Components |
Physical Application Components |
||
|
ArchiMate |
Application Services |
Application Interfaces (or Functions) |
Application Components |
||
|
Other |
Use Cases & User Stories |
User Interfaces |
Applications |
||
|
TOGAF |
Platform Services |
Logical Technology Components |
Physical Technology Components |
||
|
ArchiMate |
Technology Services |
Technology Interfaces (or Functions) |
Nodes: System Software & Devices |
||
|
Other |
APIs |
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.
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.
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 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.
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 http://avancier.website 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 avancier.website in whichever social media you use.