The science of
business architecture
What TOGAF, DoDAF, BIZBOK and BABOK
don’t tell you
Copyright 2017 Graham Berrisford. One of about 300 papers at
http://avancier.website. Last updated 19/05/2020 22:56
ArchiMate®, The Open Group®, and TOGAF®,
are trademarks of The Open Group.
There is some science about what can be documented of a business architecture.
Yet many in the enterprise/business architecture and TOGAF communities seem unaware of it.
“Very good analysis thx!”
“A very detailed and useful work.”
“A breath of fresh air! I’ve been
struggling to pin down the capability concept and fit it into my mental
model of a business.”
You don’t have to document everything about a business that could be documented.
And the aim here is not to promote any particular approach or diagram style.
The aim is to explain and relate the core concepts that underpin many business architecture approaches – in consistent and coherent way.
“I always enjoy [your material], always coherent and
consistent to an overarching conceptual framework.”
Business architects model human activity systems – be they observed or envisaged.
General system theory abstracts concepts and principles from how systems are modelled in different scientific domains.
So the business architecture concepts discussed below depend in no way on IT.
They are the basis of the approach to modelling a business in TOGAF versions 8 and 9.
This article updates some of the research done in 2008 for the British Computer Society’s professional certificates in enterprise and solution architecture.
And
it is a companion to The practice of business architecture
on the business architect role and concepts used in a
variety of standards and frameworks.
Contents
The
evolution of businesses and their architectural ingredients
Hierarchical
catalogs of things
Capability
hierarchies that correspond to function hierarchies
What
else to know about function/capability hierarchies?
Capabilities
that correspond to services: a case study
Where
else does Capability fit?
Relating
things to each other – in matrices or diagrams
“Service-Oriented
Structured Analysis”
Some
other realisation relationships
Some
other assignments of behaviors to structures
On
processes and value streams
In
conclusion, some things to remember
Footnote
1: On “capability” in other business architecture sources
Footnote
2: On the science of hierarchical structures
Footnote
3: Do we model services or flows? Notes for ArchiMate diagram drawers
Footnote
4: On systems in general
The
evolution of human society depended on people’s oral communications and
internal memories.
The
written word enabled communications to be recorded in a persistent and publicly
shareable form.
Standardising
the messages needed to trade in goods and services enabled business processes
to be repeated in a regular way.
Four
millennia have passed since the dawn of civilization and the formalisation of
business systems.
Only
four decades have passed since Enterprise and Business Architecture
approaches emerged.
For
example, Duane Walker’s Business System Planning, and James Martin’s Enterprise
Engineering.
Business
architects look, across the breadth of an organisation, to improve, integrate
and innovate business processes.
Most approaches start
with some strategic analysis of the business processes that create and use business data.
In 2006, the popular
book "EA as Strategy" urged enterprises to define their business
operating model in terms of core business processes and information.
Modern
business roles and processes depend on the use of IT to store and transmit
business data.
So
EA can’t ignore IT; however, it remains focused on supporting and enabling
business roles and processes.
Business architects model "regular, repeatable or determinate" behaviors, which can be realised and tested in the real world.
They are concerned with the services provided by a business.
And with how those services are delivered by processes that refer to and advance the state of the business.
The services are behaviors that deliver results of value to actors with a stake in the business.
E.g. Take out a loan. Complete a tax return. Direct an airplane take off. Conduct a research project.
A business architect can identify service improvements and innovations.
The processes
are sequences of activities that a business must perform to complete
services.
A business architect can define process improvements and innovations.
The state of a business is represented in information in the data structures of messages and memories.
A business architect can improve and innovate in data capture and use.
This article focuses on modelling business activities rather than business data.
You don’t have to model every business activity that could possibly be documented.
You model what you need to understand, then
choose what to communicate to others - simplifying as need be.
Enterprise and business architects are said to regard the enterprise as “a system of systems”.
In general system theory, a system may be defined as collection of actors performing some activities to achieve some aims.
In business architecture, actors in roles and organisation units perform activities in processes to meet the aims or goals of the business.
This table shows how an architect may approach the description of a business, or of a required business change.
|
A simple
approach |
A simple illustration |
|
1) What are the goals
of the business? |
Attract more
customers to the hotel |
|
2) What services
will the business offer/provide to achieve those goals? |
Valet parking
of a car |
|
3) What processes
must be performed to deliver those services? |
Park and
retrieve a customer’s car |
|
4) What roles are
needed to perform the activities in the processes? (And how many actors in
each role?) |
Valet (3) |
|
5) What organisation
structure is needed to manage the actors? |
Front desk
management |
|
6) What are the locations
where the processes are performed? |
Hotel entrance
and car parks |
You can find corresponding concepts in many standards and sources on business architecture.
E.g. The SFIA standard’s definition of the
business architect role refers to goals, functions, services, processes, information, roles and organisation.
And this table classifies core concepts in the meta models of business architecture you can find in TOGAF and ArchiMate, adding interfaces.
|
|
Behavioral view of activities |
Structural view of activities |
|
|
Consumer
view |
Business Services |
Business Interfaces |
|
|
Implementation
view |
Processes |
Functions & Roles |
Logical Components |
|
Organisation Units & Actors |
Physical Components |
Sources
refer also to value streams and capabilities.
As will be explained later:
· Value streams are end-to-end business processes
· Capabilities are the abilities of an organisation.
Watch your language!
To be regarded as a profession, business architecture needs a domain-specific vocabulary.
It is not enough to define each concept in a sentence and/or name some examples.
One has to differentiate the concepts and define their relationships to each other – as discussed below.
Beware
there is terminology torture out there, and that these three
vocabularies don't always coincide:
·
how business
people speak of business architecture concepts
·
how concepts
are named in a business architecture meta model (as in TOGAF and DoDAF)
·
how concepts
are named in diagrammatic modelling languages (like BPMN or ArchiMate).
So, you cannot assume business people will use terms as you find them in a domain-specific vocabulary for business architecture.
Structured Analysis involves cataloguing business architecture entities under hierarchical structures.
It dates back to the early 1990s, if
not before, and was presumed knowledge in TOGAF version 8.
One approach is tabulated in the section called "Business Architecture process in TOGAF 8 and 9" in The practice of business architecture.
Catalogs
Most EA frameworks expect business architects to catalog the
ingredients of business architecture, for example:
· Goals: each being a motivation or target, ideally measurable and timebound, for business activity.
· Processes: each arranging activities sequentially so as to end in the production of result(s) or desired effect(s) that contribute to goal(s).
· Organisation units: each being a managed group of actors and activities (it might be called a physical business component).
· Locations: each being a place, area or address where business activities are carried out.
There is no fixed level of
granularity; the concepts are applicable to modelling a business or component
building block of any size.
So, to understand and manage the
complexity of a whole enterprise, architects usually organise the items in a
catalog under a hierarchical structure.
This involves using the basic
systems analysis and design techniques of hierarchical decomposition and
composition.
· Decomposition: dividing larger/longer things into smaller/shorter things
· Composition: grouping smaller/shorter things into larger/longer things.
Hierarchies
The real world is network of interrelated things – including
goals, processes and organisation units.
We impose hierarchical structures on those things to help us
understand and manage them.
In a hierarchical structure, every node (apart from the top
one) has one parent/owner node.
E.g. each organisation unit has one wider parent/owner
organisation unit.
EA regards a business, holistically, as a system of systems
designed to meet business goals.
The whole is composed of subsystems (aka building blocks)
that perform behaviors (perform processes and deliver services to each other).
Further structural decomposition reveals successively smaller subsystems.
The whole system may be required to perform several end-to-end processes (aka value streams).
Each activity in a high-level process can in turn be elaborated as a process composed of shorter activities.
Further behavioral decomposition reveals successively shorter behaviors
Most EA frameworks feature hierarchical catalogs such as
these.
|
Category
of system element |
Hierarchy
of business architecture entities |
|
|
Motivations |
Goal/objective hierarchy |
a cascade of goals, as in
a strategy map or a balanced score card. |
|
Physical active structure |
Organization hierarchy |
dividing people and
resources for management purposes. |
|
Logical active structure |
Function and/or capability hierarchy |
dividing larger/wider
functions or capabilities into smaller/narrower functions or capabilities. |
|
Behaviors |
Process hierarchies |
elaborating each activity
in a long-running process (or value stream) as a shorter process. |
Beware that how business architecture entities relate to each other is complicated by the fact that each entity can be hierarchically composed and decomposed.
Numbers
constrain what is practical
The breadth of a hierarchy is as wide (even an entire business) or as narrow as you choose it to be.
For the depth, there are some numeric rules of thumb.
Suppose each node is decomposed into 7 subordinate nodes (“the Miller number”).
|
Level of decomposition |
Number of nodes |
|
1 |
7 |
|
2 |
49 |
|
3 |
343 |
|
4 |
2,401 |
|
5 |
16,087 |
|
6 |
117,649 |
|
7 |
823,543 |
The numbers in the table explain why few architects can maintain a hierarchy more than 3 or 4 levels deep.
Perhaps the only practical way to maintain a deep hierarchy is to make it self-populating.
To distribute the responsibility for adding, modifying and deleting nodes to people around the enterprise.
E.g. An organisation hierarchy can be maintained if every employee maintains the name of their manager in that hierarchy.
And a goal hierarchy can be maintained every manager maintains the list of goals given to each person they manage.
The terms function and capability are used in many ways, often in correspondence.
The term “capability” originated in the military.
e.g. the US military’s strategic capability to fight two major wars at the same
time, which dates back to WWII. Armies spend years preparing and training to be
able to do things they may never actually do. What they do currently on a
day-to-day basis – drills, training and exercises - is one thing. What they are
able to do in the future - fight two major wars at once - is another.
The potential of an enterprise includes its current business functions and what it could or should do in the future. However, in EA we model both current systems and future systems using the same concepts. The systems of interest feature actors performing activities to meet aims.
A capability is the ability of one or more
actors (current or yet to be defined) to:
· do something
(activity) or achieve something (aim)
· do what can,
could or should be done (perform activities and/or meet aims)
· meet a goal (aim) produce an outcome or perform a function (activity).
A function can be
· As in the UML standard, a process that transforms input into
output. E.g. an algorithm to calculate the area of a circle from its radius.
· As in ArchiMate’s application domain, a logical application
component.
· As
in ArchiMate’s business domain, a cohesive group of activities E.g. the
functions of a national government are to maintain order, provide national
security, provide economic security, provide public services and economic
assistance.
The table below compares function and capability hierarchies.
Others ways of looking at capabilities are explored in later sections.
|
A function hierarchy - structures the activities of an organisation |
A
capability hierarchy - structures the abilities of an organisation |
|
What is a (business) function? A business function is a logical
division or component of a business. It
is a group of business activities that are cohesive in some way. It
may group activities needed to achieve a goal or closely-related goals. Or
group activities that need related abilities or other resources. Examples may include “Sales”,
“Procurement”, “Disaster recovery”. Also “Control of the air space over a
territory” and aspirations like “Manned interplanetary travel”. |
What is a (business) capability? A capability is the ability to
complete some activity(s) or achieve some aim(s). It is usually named in terms of those
activities or aims. A business capability is
a logical division of the total abilities of a business. It groups abilities needed to achieve
a goal or closely-related goals. Examples may include “Sales”,
“Procurement”, “Disaster recovery”. Also “Control of the air space over a
territory” and aspirations like “Manned interplanetary travel”. |
|
When to extend an existing function or create a new function? When
the business identifies it has a new goal, or must offer a new service. Or
perhaps it envisages a new process or project. Or
it identities several of the above. |
When to extend an existing capability
or create a new capability? When the business identifies it has a
new goal, or must offer a new service. Or perhaps it envisages a new process
or project. Or it identities several of the
above. |
|
What is a function hierarchy? Functions
are abstractions – independent of physical resources. An
organisation structure imposes a hierarchical management structure over the
actors of a business. A
functional decomposition imposes a more abstract hierarchical structure over
the activities of a business. It groups atomic activities, and then
narrower, lower-level, functions under wider, higher-level, functions. Ideally,
the result is a normalised structure; meaning no atomic activity appears
under more than one bottom-level function in the hierarchy. |
What
is a (hierarchical) capability map? In most modern sources, capabilities
are abstractions – independent of physical resources. An organisation structure imposes a
hierarchical management structure over the actors of a business. A capability map imposes a more abstract
hierarchical structure over the abilities of a business. It groups narrower, lower-level,
capabilities under wider, higher-level, capabilities. |
|
Why define a function hierarchy? To
define the scope and logical structure of a business in
a way that is more stable than, and independent of, the
organisation/management structure. To
assist in discussion of business scope and change. To
group and classify other EA/BA entities and resources. |
Why define a capability map? To
define the scope and logical structure of a business
in a way that is more stable than,
and independent of, the organisation/management structure To assist in discussion of business
scope and change. To group and classify other EA/BA
entities and resources. |
|
How is a function hierarchy presented
and used? TOGAF
9.2 says that its Functional Decomposition Diagram: “Shows on a single page the
organization capabilities relevant to the architecture to be defined and
governed. Helps to quickly model [those]
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.” |
How is a capability map presented and
used? A capability map can: Show on a single page the
capabilities relevant to the architecture to be defined and governed. Help to quickly model those
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. |
|
How to build a function hierarchy? A hierarchy can be built from the top
down (decomposition) or bottom up (composition). There
is a process for composing a business function hierarchy systematically. Understanding
this helps to explain the concept, even if you never do it. 1)
Define the organisation
structure of interest down to bottom level units 2)
List the regular activities
performed (or to be performed) in each unit 3)
Deduplicate that list of
activities 4)
Cluster them into groups
using a cohesion criterion of your choice 5)
Cluster the groups into
higher groups, and so on until you reach the top of a hierarchy. You
may cluster activities and functions using any cohesion criteria you
choose. E.g.
cluster activities and functions that: ·
meet the same aim(s) or
contribute to the same measure(s) to be reported ·
need related abilities or
skills ·
create and use data in the
same “bounded context” or using the same “domain-specific language”. |
How to build a capability map? A capability map can be built from
the top down (decomposition) or bottom up (composition). There is a process for composing a
business capability map systematically. Understanding this helps to explain
the concept, even if you never do it. 1) Define the
organisation structure of interest down to bottom level units 2) List the
competencies/abilities that are used/needed in each unit 3) Deduplicate that
list of competencies/abilities 4) Cluster those
that meet the same aim(s) or contribute to the same measure(s) to be reported
5) Cluster the
groups into higher groups, and so on until you reach the top of a hierarchy. Note that the abilities of an
existing organisation are sometimes called competencies. There is a short discussion of
capability, competence and capacity later in this article. |
|
How numbers constrain what is
practical The
breadth of a function hierarchy is as wide (even an entire business) or as
narrow as you choose it to be. However,
few can maintain a function hierarchy more than 3 or 4 levels deep. And many limit decomposition to what
can be shown on one page. The high degree of abstraction means
you will rarely need to change the function hierarchy when there are changes
to processes documented at the level of fine-grained activities. You’d
need to work in a remarkably (impossibly?) stable business to maintain a
function hierarchy to 6 or 7 levels. |
How numbers constrain what is
practical The breadth of a capability map is as
wide (even an entire business) or as narrow as you choose it to be. However, few can maintain a
capability map more than 3 or 4 levels deep. And many limit decomposition to what
can be shown on one page. This high degree of abstraction means
you will rarely need to change the capability map when there are changes to
processes documented at the level of fine-grained activities. |
The function and capability concepts are different
However, there is a logical reason why capabilities may correspond
to functions.
To perform particular activities, you
must develop the corresponding abilities.
E.g. To play a game of chess, you
must develop the ability to play chess.
A function groups some activities of an organisation; a capability groups some abilities of an organisation.
To perform the activities in a
function, a business must develop the abilities that add up to a corresponding
capability.
E.g. to perform a Procurement
function, a business must develop a Procurement capability.
This surely explains why functional decomposition
diagrams and business capability maps look the same and
are used in same ways
You will find this is true in industry
standards, in examples on
the internet, and probably also in practices you can observe.
So, you might conclude the concepts of function and capability are interchangeable in a meta model of business architecture.
But no - it isn’t that simple –
as explained in later sections.
Aside: the artifact definitions in TOGAF are variously interpretable, and several of them may be used to present a view of functions
In the table below, you might reasonably replace Function by Capability, and use the NAF view in place of the TOGAF artefact.
|
Functions <are related to> other
architectural entities |
Artifact mentioned in TOGAF |
NAF
views |
|
Functions
<provide> Services (consumer view) |
Business
Service/Function catalogue |
Capability/services mapping |
|
Functions <are
composed of> Functions |
Functional decomposition
diagram |
Capability taxonomy Capability/Operational activities mapping |
|
Functions <serve> Functions
or Roles (with info/material flows) |
Node connectivity
diagram |
Capability Dependencies |
|
Functions
<participate in> Processes |
Value stream diagram,
Scenario, Process flow diagram |
Process |
|
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> Applications |
Application/Function
matrix |
|
Three things you ought to know, though teachers may not discuss them.
Duplicate
hierarchies of different elements
Successively
grouping cohesive activities or abilities implies also successively grouping
the cohesion factor.
And
therein lies a challenge that arises in modelling system elements in
hierarchical catalogs.
Basing
one hierarchical structure on another makes documenting both unnecessary, or at
least questionable.
Suppose you align a business function or capability hierarchy with the business goal/objective hierarchy.
Then to document both introduces a redundancy into your architecture definition.
Documenting both hierarchies only becomes of interest when the structures are different.
(See
the footnote on the science of corresponding and clashing structures.)
Parallel hierarchies of the same elements – a function
forest and the primary tree
You can juggle two or more cohesion criteria to compose one hierarchy.
Generally, however, clustering activities or functions using different criteria can lead to different function hierarchies.
You can build several function hierarchies (a function forest) each addressing a particular stakeholder viewpoint.
I recall a speaker (at a BCS EA SG meeting) saying they had 9 function hierarchies - each representing the viewpoint of a different director-level reporting requirement.
As is the EA tradition, they settled on one function hierarchy as a basis for other analyses.
That function hierarchy was the one that most senior business leaders accepted as reasonably describing the scope of their business.
An EA team often uses a primary function hierarchy as a way to present the scope of the business they address.
It might correspond to a business goal/objective hierarchy, but it does not have to.
They can then map functions to other things – such as data created and used.
(I have yet to hear the possibility of parallel capability maps being discussed.)
Reused and cross-cutting
functions
A real-world business is a network
of interrelated actors, abilities, abilities and aims.
We impose hierarchical structures on
them to help us understand and manage them.
In a hierarchical structure, every node (apart from the top
one) has one parent/owner node.
But (unless your EA tool prevents it) you can define:
·
parallel function hierarchies – a function forest
· a function that is reused in different legs of one function hierarchy
·
a function outside of any hierarchy
· a function that cuts across the functions in your “primary tree”.
E.g. Consider functions called “photocopying”,
“disaster recovery” and “money laundering prevention”.
(I don’t know how far it is agreed the same things can be said of capabilities.)
Later in this article, there is an explanation of Service-Oriented Structured Analysis.
To be going with, these are the basic ideas:
Structured Analysis means defining business architecture entities (in hierarchical catalogs) and relating them (in matrices or diagrams).
This
was presumed knowledge in TOGAF version 8 and 9.
Service-orientation means defining structural system elements, abstractly, in terms of services they offer and require.
E.g. TOGAF version 1 defined Infrastructure/Technology Components by the Platform Services they provide, in a Technical Reference Model (TRM).
And
today, TOGAF also defines both Application Components and what may be called
business components by the services they provide.
The “Service-Oriented
Structured Analysis” implied by TOGAF 9’s business architecture did not feature
Capabilities.
A
correspondent was keen to show me where Capability fits.
Below
is an edited version of our discussion.
A case
study
Me: Architects abstract from real-world business operations.
They may abstract a logical Function hierarchy from the Organisation/management structure
They may abstract generic Services from particular Service instances discussed with stakeholders.
A retailer like Marks and Spencer provides Business Services to its customers.
Some Service do not leave a data trail: E.g. "Browse the stock", "Use a Fitting room", and “Park your Car for free”.
Other Services create data: E.g. "Purchase a Stock Item", "Return a Stock Item", "Purchase a Grocery Item", "Open an Account"
Correspondent:
In such a retailer, what are the top three reasons that customers go to the
Customer Care desk?
If
discussion of this lets you grasp the concept of Capability, it might also give
you a simple way to explain it to your students.
Me:
Returns, faults and general queries?
Correspondent:
A good answer. Let’s go with faults.
The
customer walks up to the Customer Care Desk with a faulty item and wants the
item repaired.
The
business does not have a Repairs Department or any way of sending items back to
the manufacturer and therefore cannot repair items.
However,
the business can replace the item so the customer gets a replacement.
At the
moment, the faulty goods are disposed of by the business with no compensation.
What
are the obvious ways to improve the situation for the business?
Me:
That depends on costings I have no idea about here, but options could include
one or more of the following.
·
Ask the manufacturer to pay for the
replacement
·
Contract with the manufacturer for
repairs
·
Contract with another business for
repairs
·
Establish a Repairs Function
·
Press the customer for evidence that
the item was faulty when they bought it, then grudgingly offer some other
option above
·
Give the customer their money back, and
then perhaps some other option above.
·
Find a more reliable manufacturer.
Correspondent:
Good, you're heading in the right direction.
Let's
go with the fourth, create an in-house Repairs Function. Are we definitely
agreed that is a Function?
Me:
Before speaking of Functions let me apply the simple approach outlined above.
|
A simple
business architecture approach |
In this case study |
|
1. What are the goals
of the business? |
To
reduce the cost of faulty items returned without compensation. |
|
2. What services
will the business offer/provide to achieve those goals? |
A
new Repair Item Service. |
|
3. What processes
must be performed to deliver those services? |
A Repair
Process to be defined. |
|
4. What roles are
needed to perform the activities in the processes? (And how many actors in
each role?) |
To be defined. |
|
5. What organisation
structure is needed to manage the actors? |
To be defined,
but the Customer Care Desk will surely be involved. |
|
6. What are the locations
where the process is performed? |
To be defined. |
If we
have a documented a function hierarchy (we don’t have to), then we should
consider the impact of adding a new Repair Item Service and Process.
This
is such a narrowly-focused business change that the activities in new Repair
Process might be grouped under an existing Function
Or
else, we might add a new, rather simple, Repairs Function.
This
new logical business component will group those activities required to achieve
defined Goal and deliver the new Repair Item Service.
Then,
if the Repairs Function is to be realised in-house, we’ll likely create an
in-house Repairs Organisation Unit.
Correspondent:
Good. Suppose we go ahead and create the Repairs
Function.
Me: A Function is only an abstraction;
what we find or create in the world are physical resources that can perform the
activities in the Function.
We create a Repairs Organisation Unit,
responsible for actual repair work, and assign Actors in the Customer Care Desk
to perform some administrative activities
Correspondent: The customer walks up to
the Customer Care Desk and probably has no direct contact with the Repairs
Function.
Me Yes, because the Repairs Function is only an abstraction,
it does not do things.
Customers might well have no direct
contact with an in-house Repairs Organisation Unit either.
But they surely will interact with
Actors in the Customer Care Desk Organisation Unit, who perform some
administrative activities in the Repairs Function.
Correspondent:
If we outsourced repair work, chose another business to do the repairs for us,
would the Function be different?
Would
the customer have to know the difference?
Me:
There is no obvious need for the customer to know the difference.
The customer
requests a discrete Repair Item Service regardless of how it is implemented –
regardless of the Actors used and Processes followed.
As a
business director or shareholder, I'd want the implementation to appear
seamless to the customer.
And
would hope the implementation of the Repair Item Service can be changed without
changing the name or essential nature of the Service.
Aside:
Note that we may well go on to define a contract for the Repair Item Service.
We
should define it declaratively (as an external entity sees it) rather than
procedurally (as it is performed).
The
contract will include some or all of entry conditions, exit conditions and
quantitative measures (like duration).
So, if
changing the implementation changes any of those details, then customers may
indeed notice changes in some quality of the Business Service.
Correspondent:
Yes, you're almost there [to positioning Capability].
Beforehand,
the customer could only get a replacement. What has changed?
Me:
Before, customers could request only a Replacement Service; now they can
request a Repair Item Service instead.
Correspondent: I've never seen anyone use a Service at that level, but I guess it's possible.
Me: You highlight the issue that few teach the “Service-Oriented Structured Analysis” implied in TOGAF version 8 and 9.
Central
to TOGAF is the presumption that every business provides Business Services.
Each
is a transient unit of behavior that ends in a result of value to a
customer – here, a Repair
Item Service.
Correspondent: And do you see there is a Capability gap in the case study?
Me: For sure, there is what you might call a Capability gap and I might call a Service gap.
The business owner may say we need the Capability to achieve the Goal - to save money lost on faulty items.
That Capability may be defined, in an actionable but still abstract way, as a new Repair Service.
Correspondent: Defining Capabilities helps us to
bridge another gap, the one between high-level goals and implementation, by focusing
on what is actionable.
Me: Bridging the goal-implementation gap is the role played
by Service definition in TOGAF, as this example illustrates perfectly,
You may prefer to say instead that to
achieve the higher-level goal, the business must develop and a Repair Item
Capability.
But
exactly how do you define the term “Capability”?
|
Correspondent |
Me |
|
Capabilities are
expressed in general and high-level terms and typically realized
by a combination of organization, people, processes, information, and
technology. |
The same is true of
Services (also Goals, and Functions). |
|
Capabilities are
typically aimed at achieving some goal or delivering value by realizing an
outcome. |
The same is true of
Services (also Processes, Functions and Roles). |
|
Capabilities are
themselves realized by core elements. |
The same is true of
Services (also Processes, Functions and Roles). |
|
To denote that a set of
core elements together realizes a capability, grouping can be used. |
Other approaches also
group the elements that realise an abstraction. |
|
Capabilities are often
used for capability-based planning, to describe their evolution over time. |
Other approaches also
group the element versions in each transition state. |
You’ve defined
some qualities and uses of the Capability concept without actually defining it.
However, we surely agree
that “Capabilities are the abilities of an organisation”.
You’ve also
neither distinguished Capability from other business architecture entity types,
nor related Capability to them.
Which makes it very difficult to pin down where your concept fits in a meta model that includes Goals, Services and Functions.
In discussion of MoDAF, “Manned Interplanetary Travel” has been given as an example of a Capability.
Earlier, you posted other examples of Capabilities that could well be documented as Goals.
And complained examples of Capability on the internet and in TOGAF should be called Functions.
And here, to explain Capability, you have discussed the development of a new Business Service.
In your retail example, your Capability corresponds to a Goal and to a Business Service.
Which leaves us with the following question.
Suppose a TOGAF user documents the Goal (to save money lost on faulty items) and the proposed Business Service (Repair Item).
Why should they document a Capability as well? What would that add?
(As I write this, I am waiting for the correspondent to answer.)
The footnotes list a dozen definitions that all define a Capability as an ability - of a business or other entity.
Most define it as an ability to do something - to perform one or more activities and/or achieve one or more aims.
Capability is a chameleon, since a business needs the ability to do anything you care to mention.
E.g. to achieve a Goal, deliver a Service, realise a Function, perform a Process, play a Role, etc.
To do any of these things, a business must develop and use the corresponding Capability.
Where
does capability fit in TOGAF?
The table shows how the Capability concept might be attached to several business architecture entities in TOGAF.
|
Business architecture in
TOGAF 9.2 |
A business (or its
actors) must develop and use the |
|
|
“Business
operations |
Capability to perform each Capability to play each |
Process
or
Service Role |
|
“factors
that motivate the enterprise |
Capability to meet each |
Goal |
|
“how
the enterprise is organizationally structured and |
Capability to manage each |
Organization
unit |
|
“what
functional capabilities the enterprise has” |
Capability to realise each |
Business
function |
In modern sources (unlike in its original military sense) a Capability is supposed to be defined abstractly.
And so, it is most typically associated with one or more of a Goal, a Service and/or a Function.
You might perhaps see it as an abstract supertype of those, which is documentable as any one of them.
Where does
capability fit in the art of business architecture?
We may use the word Capability in many discussions.
Its flexibility makes the term appealing and convenient in discussion with business people.
And in practice, the term is used freely by management consultants and enterprise architects.
So, tool vendors are encouraged to include Capability in their meta model of business architecture entities.
This enables their users to model whatever they choose as Capabilities.
This flexibility leads me to this hypothesis about business architecture:
Everything classified by one modeller as the name of a
capability might - alternatively - be classified by another modeller as the
name of something else
It could be the name a goal, a role, a service, a process,
a function or an organisation unit – for which the business must develop the
corresponding capability.
Where does
capability fit in the science of business architecture?
Including Capability as an entity in business architecture meta model is problematic.
The flexibility of the term makes it difficult to pin down its meaning and its relationships to other architectural entities.
In meta model terms, perhaps…
An abstract Capability might be modelled as a very abstract supertype of other already abstract entity types, notably Goal, Service and Function.
A concrete Capability will be found in whatever resources are grouped in whatever system or subsystem realises the defined abstraction.
How to
differentiate ability, capability, competence and capacity?
In natural language, these terms are used well-nigh interchangeably in discussion of human abilities.
E.g. You may either desire or possess the ability, capability, competence or capacity to play chess.
By contrast, in so-called “management science”, authors draw arbitrary distinctions between these words.
And different authors draw different distinctions.
|
|
Capability |
Competency |
Capacity |
|
Source 1: v 1 |
the condition of having
the capacity to do something |
the improved version
of capability |
. |
|
Source 1: v 2 |
the ability to
develop and flex to meet future needs |
the possession
of the skills, knowledge and capacity to fulfil current needs |
|
|
Source 2 |
the higher level of
ability that could be demonstrated under the right conditions |
the quality or state
of being functionally adequate or having sufficient
knowledge, strength and skill to deliver what is required.” |
the ability that
exists at present |
Baseline business
services and processes (implemented now) are inputs to EA.
Target business services
and processes (to be developed) are outputs from EA.
We label these system
elements the same way in the baseline and target states.
Curiously, two out of three sources above apply the terms competence and capacity to baseline (already used) abilities.
And apply the term capability to target (to be developed) abilities
Which is to imply abilities identified today as target capabilities, once developed, will be relabelled as baseline competencies and capacities.
Source 1: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.695.7600&rep=rep1&type=pdf
Source 2: https://www.businessprocessincubator.com/content/ability-capability-capacity-and-competence/
Structured Analysis involves defining a business architecture by:
· cataloguing entities (e.g. goals and organisation units) under hierarchical structures
· mapping the elements in one catalog to elements in another catalog.
EA/BA frameworks have long employed Structured Analysis.
E.g. see Business System Planning and BOST in The practice of business architecture.
TOGAF
versions 1 to 7 were focused on IT architecture rather than EA or BA.
Eventually, TOGAF version 8 drew on the BA tradition above, and TOGAF now includes a menu of possible catalogs and matrices.
Relationships
as cells in matrices
Bear in mind that every business architecture entity might be composed and/or decomposed.
So, when drawing a matrix, it is normal practice to map entities at about the same level of decomposition.
E.g. you might assign goals to organisation units in a matrix.
|
|
Goal |
Goal |
Goal |
|
Organisation unit |
x |
|
|
|
Organisation unit |
|
x |
x |
|
Organisation unit |
|
x |
|
Relationships
as lines on diagrams
Business Architecture frameworks often show diagrams in place of matrices.
E.g. You can name organisations and goals in boxes, and draw lines between them.
Bear in mind that EA is supposed to consider the enterprise as a whole.
Drawing hundreds of lines between boxes creates what some call a “shock and awe” diagram.
Cluster
analysis
Suppose you want to identify all the organisations units who contribute to the same goal.
Or all the goals that one organisation unit contributes to meeting.
Suppose you want to identify all the functions that create the same data.
Or all the data created by one function.
To do this, you can apply cluster analysis to the rows and columns of a matrix.
A matrix building tool may automate this, using what is call the “north-west corner” method.
The numbers constrain what is practical
It is difficult for one or two architects to maintain a matrix with more than, say, 1,000 rows and columns.
This implies the business architecture entities in an enterprise-wide matrix are at a decomposition level no lower than 3 or 4.
Suppose (as in TOGAF) you draw a Data Entity / Function matrix at the third level of decomposition.
It is unlikely you will get down to the level of atomic activities in work procedures.
You might get down to the level of smallish aggregates of normalised data entities – each centred on a “kernel” entity.
Scores of matrices could be drawn between, say, goal, service, process, role, organisation unit, function and kernel data entity.
Different EA frameworks and methods focus on
different relationships.
The next section includes some examples.
The aim here is not to promote any specific approach - only to bring more consistency and coherence to the whole.
However, what follows in this section fits what I was taught over the last four decades, and fits TOGAF.
Structured Analysis means defining business architecture entities (in hierarchical catalogs) and relating them (in matrices or diagrams).
This
was presumed knowledge in TOGAF version 8 and 9.
Service-orientation means defining structural system elements, abstractly, in terms of the services they offer and require.
E.g. TOGAF version 1 defined Infrastructure/Technology Components by the Platform Services they provide, in a Technical Reference Model (TRM).
And
today, TOGAF also defines both Application Components and what may be called
business components by the services they provide.
How
these two approaches work together in what may be called “Service-Oriented
Structured Analysis” has never been made entirely clear in TOGAF.
But what follows is compatible with TOGAF’s Content Framework.
Imagine you listed all the atomic
activities to be performed in the regular processes of a business.
Where atomic means the shortest activities that you consider worth identifying and naming.
It is possible to define other business architecture entities in terms of those activities.
E.g. The table below maps the definition of business
architecture in TOGAF 9.2 to some of its business architecture entities – each
defined in terms of activities.
|
Entities |
Definable
in terms of activities thus |
|
|
“Business
operations, |
Processes Roles |
A process sequences activities that lead to a result of value
(spanning one or more organisation units). A role groups the
activities that one actor is responsible for performing (in one or more
processes). |
|
“factors
that motivate the enterprise , |
Goals |
A goal is a motivation
for one or more activities |
|
“how the
enterprise is organizationally structured |
Organization
units |
An organisation unit is accountable for the performance of a
selection of activities. |
|
“and what
functional capabilities the enterprise has” |
Business
functions |
A business function groups activities that are cohesive in some way(s). |
The
“Service-Oriented Structured Analysis” presumed in TOGAF can be illuminated
with reference to the ArchiMate standard.
This table classifies core concepts in the meta models of business architecture you can find in TOGAF and ArchiMate
|
|
Behavioral
view of activities |
Structural
view of activities |
|
|
Consumer view |
Business
Services |
Business
Interfaces |
|
|
Implementation view |
Processes |
Functions
& Roles |
Logical
Components |
|
(Process Instances) |
Organisation
Units & Actors |
Physical
Components |
Notes
TOGAF does not feature Business Interfaces, but ArchiMate does.
ArchiMate does
not distinguish (which can be either distinct or
combined)
·
an abstract Interface - listing potentially accessible
Services
·
a concrete Interface – in which Services can be accessed by
customers/consumers.
ArchiMate’s questionable classification of Functions (under the behavioural view) leads people to confuse them with Processes.
Architects rarely document a Process Instance - except in an illustrative scenario or test case.
This table lists a variety of relationships that could, potentially, be documented.
|
Relationship between
entities |
May be construed as illustrating the general concept of |
||
|
Services <may be
found in> Interfaces |
|
|
Assignment of behaviors
to structures |
|
Services <encapsulate>
Processes |
Encapsulation |
Realisation |
|
|
Interfaces
<encapsulate> Structural views of activities |
Encapsulation |
Realisation |
|
|
Functions <realise
or provide> Services |
Encapsulation |
Realisation |
Assignment of behaviors
to structures |
|
Organisation Units
<realise or implement> Functions |
|
Realisation |
|
|
Actors <realise or
implement> Roles |
|
Realisation |
|
|
Roles <perform
activities in> Processes |
|
|
Assignment of behaviors
to structures |
|
Processes <sequence
activities assigned to> Functions |
|
|
Assignment of behaviors
to structures |
Service and interfaces are abstractions – external views of
system activity – defined as consumers see them.
Services <may be found in> Interfaces
Business Services may be listed in a catalog, as TOGAF suggests.
And may be found in Interfaces, as ArchiMate indicates.
Services <encapsulate> Processes
A Service encapsulates a behavioral view of activities.
A Service is delivered by initiating at least one Process, and
perhaps orchestrating others.
A Process is a
sequence of activities that end in a result of value to an actor inside or
outside the system of interest.
Processes <realise, complete or deliver the results
of> Services.
Interfaces <encapsulate> Structural views of
activities
Structural views of activities includes Functions,
Organisation Units, Roles and Actor.
In one famous business case study (“Morning Star”) every Actor
in the organisation defines their own Interface.
That is to say, they define the Services they can be asked to provide to other Actors.
More commonly, the Business Interface for an Organisation Unit may be:
· abstract, as in a Service Level Agreement document that lists many potentially accessible Services
· concrete, as in a “portal” that makes Services accessible to customers/consumers.
The term “realisation” applies to
relationship between a more abstract thing and a more concrete thing
Interfaces and Services are external views, which are realised
by more concrete internal views.
Functions and Roles are logical components, which are realised
by more physical components, Organisation Units and Actors.
Functions <realise or provide> Services
One Function may provide several Services.
Ideally, each Service is assigned to one Function, though that Function may require other Services from one or more other Functions.
Note, a Function is an abstraction, you cannot contact it to request a Service.
Some would here
replace Functions by Organisation Units.
Organisation Units <realise or implement> Functions
An
Organisation Unit is persistent and physical active structure.
It is
a managed group of Actors (who perform activities in one or more Functions and
Processes).
An organisation structure imposes a hierarchical management structure over the actors of a business.
A functional decomposition imposes a more abstract hierarchical structure over the activities of a business.
A Function is persistent but
logical active structure – a logical Organisation Unit.
E.g. “Sales”, “Wheel
replacement”, or “Training”.
It is an abstract grouping of
activities in one or more Processes.
It is a logical division or component of a business’s operations.
It is a group of business activities that are cohesive in some way, notably:
· activities needed to achieve a goal or closely-related goals
· activities that need related abilities or other resources.
It may be said that Organisation Units implement or realise Functions.
|
|
Function |
Function |
Function |
|
Organisation unit |
x |
|
|
|
Organisation unit |
|
x |
x |
|
Organisation unit |
|
x |
|
In a
special case, organisation units correspond to functions.
They correspond 1-to-1 in what some call a “functional organisation”.
They clash where the management structure is divided in other ways, e.g. by location, product type or customer type.
Actors <realise or implement> Roles
An Actor is an individual that plays one or more Roles.
A Role may be played by one or more Actors.
A Role is persistent
but logical active structure – a logical Actor.
Architects are taught to model Roles.
They rarely model individual Actors other than a Role-played-by-only-one Actor, like a named Organisation Unit.
The convention in ArchiMate is that
behaviors are assigned to structures.
But you can express the relationship in the
opposite direction.
Roles <define responsibilities for performance of
activities in> Processes
A Role (in an Organisation Unit) may be assigned to activities in several Processes.
One Process may require Actors in several Roles (in several Organisation Units).
|
|
Role |
Role |
Role |
Role |
|
Process |
x |
|
x |
|
|
Process |
|
x |
x |
x |
|
Process |
|
x |
|
x |
Each row of this matrix may be drawn as diagram – with the Roles as swim lanes.
In special
cases, a Role and a Process are in one-to-one correspondence.
This occurs when actors are employed to
perform all the activities in 1 and only 1 process.
Again, a Role is an abstraction, it does not actually perform Processes.
However, it is rare here to replace Roles by named Actors – except in an illustrative scenario or test case.
Processes
<sequence activities assigned to> Functions
A process imposes sequences on the activities required to meet some aim(s).
A functional decomposition imposes a hierarchical composition structure over the same activities.
One function may
wholly "contain" several processes
One process (or value stream) may span several functions (that is to say, it orchestrates particular activities with those functions).
|
|
Function |
Function |
Function |
Function |
|
Process |
x |
|
x |
|
|
Process |
|
x |
x |
x |
|
Process |
|
x |
|
x |
Each row of this matrix may be drawn as diagram – with the Functions as swim lanes.
Again, a Function is an abstraction, it does not actually perform Processes.
Some would here replace Functions by Organisation Units or Roles.
In
rare cases, a function is in one-to-one correspondence with a process.
That is, all the activities grouped in the function are the steps of one process.
Again, at the very bottom of function
(structural) and process (behavioural) decomposition are the same atomic
activities.
But remember, functional decomposition
usually stops at level 3 or 4.
And (where it is needed) process
modelling is more commonly completed at level 6 or 7.
A long-running, high-level, coarse-grained process may be defined only sketchily (e.g. in a value stream diagram).
A function and/or capability hierarchy may be useful, but is not the aim of business architecture
The aim is process improvement – by optimising, standardising, integrating and innovating in how regular business operations are carried out.
Process improvement techniques are not covered here.
What is covered is the nature of processes.
What is a process?
A series of actions or steps taken in order to achieve a particular end. Google dictionary.
A series of actions that you take
in order to achieve a result. https://dictionary.cambridge.org/dictionary/english/process
A series of actions which are
carried out in order to achieve a particular result. https://www.collinsdictionary.com/dictionary/english/process
In BA a process is a sequence of activities (coarse-grained or fine-grained) that end in a result of value to an actor inside or outside the system of interest.
An abstract process type (as defined by business architects or analysts) is realized in the material world as process instances in a concrete system.
It is performed by concrete actor(s) and produces concrete results of value to some actor(s).
A process, at any level may be defined with reference to some or all of the following
· Entry conditions: inputs and preconditions.
· Exit conditions: outputs and postconditions or state changes– and their value to some actor(s) and/or future process(es).
· A procedure that constrains activities to occur in sequences with optional and/or repeated and/or parallel paths.
· The roles of actors engaged in the process or activities within it.
Process decomposition
All is recursive.
Every service (fine or coarse-grained) is definable declaratively in a service contract (with entry and exit conditions) that encapsulates the process(es) develops and useed to deliver it.
A set of a services requestable and deliverable as a set is simply a coarser-grained service.
A set of connected processes is simply a coarser-grained (longer) process.
At every level and length, a process may be named after its goal - the results (products or desired effects) of value that it produces.
True, different conventions have evolved for documenting processes at different levels of composition and degrees of precision.
A process may be documented as a value stream, business scenario, use case, epic, user story, procedure or algorithm.
(A use case or epic is a process during which actors create and/or retrieve digital data using an application’s interface.)
And when talking to business people, you may call a business service or
process anything they like (say a product or value stream).
But giving different names to the same concept at different levels of
granularity is problematic.
It implies fixing the level of composition/decomposition at which a model is drawn, and makes a mess of any generic meta model.
Numbers?
At the highest level of system definition, there are N top-level "end to-end" processes, which produce a result of value to one or more external actors.
You can define a top-level process in terms of coarse-grained activities, then decompose each activity in a lower-level process definition.
There is no rule for how many levels of process decomposition it takes to reach "atomic activities"; it might be 3, it might be 7.
It seems few maintain a complete top-to-bottom set of business process models.
Artifacts?
You can document a process using various kinds of artifact.
You can declare its entry and exit conditions - as in a service contract.
You can define it procedurally - as in a flow chart.
You can define it formally or informally - perhaps as in a value stream diagram or use case description.
It seems few maintain thoroughly formal process definitions above the level that is encoded in software.
.
A value stream is a sequence of activities (so, a kind of business process) characterised as in three definitions below.
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).
A sequence of activities required
to design, produce, and provide a specific good or service, and along
with information, material. www.businessdictionary.com/definition/value-stream.html
The series of activities (the how)
creating a flow of value (realizing the value
[product/service]) that the customer gets. https://www.dragon1.com/terms/value-stream-definition
'Value' is what the customer gets, like a product or a service of high quality, in a fair period of time at a fair price. https://www.dragon1.com/terms/value-stream-definition
In short, a value stream is an end-to-end process, often defined at
a high-level of abstraction.
However, the length of that process can vary widely, from months to minutes.
The table below contains examples named in different sources researched for this article.
|
Example value stream names |
Note |
|
Cash management. Inventory management. Environmental liabilities. |
These sound like functions - don’t suggest an end-to-end flow. |
|
Hire to retire. Procurement to disposal. Deploy to
re-deploy/discard. |
These sound like entity life histories - ending in the expiration of
a resource. |
|
Prospect to order. Order to cash. Procure to pay. |
|
|
Book airplane seat (to ticket). Book holiday (to confirmation).
Claim processing (to refund). |
|
|
Open a bank account. Set up a direct debit to pay bills. Withdraw
cash from the account. |
The second and third are fine-grained – at a level close to
application use cases. |
Value streams can be mapped to capabilities, as processes can be mapped to
roles or functions.
|
|
Capability |
Capability |
Capability |
Capability |
|
Value
Stream |
x |
|
x |
|
|
Value
Stream |
|
x |
x |
x |
|
Value
Stream |
|
x |
|
x |
How a value stream is represented is a matter of choice.
The entry and exit conditions of a value stream may be declared in a service contract.
The end-to-end flow of activities may be drawn – loosely – in a value stream diagram.
Unlike a flow chart, this diagram only lists the activities within each stage - rather than constrains their sequence under a logical control flow.
That imprecision allows some adaptability and agility when the process is decomposed and realised.
|
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. |
The stages in a value stream diagram can be mapped to whatever capabilities (or functions) participate in the activities in that stage.
Related concepts
·
a functional
decomposition diagram – a logical organisation structure
·
a data
entity/business function matrix – which shows which data is created and used by
which functions
·
a value chain
diagram – which identifies the core and support functions of a business at the
highest level of definition (after Porter, 1985)
·
value stream
diagrams – which each represents activities in the end-to-end flow of a
business process (after Martin, 1995 if not before).
“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.” TOGAF
· “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/functional decomposition and process flow or value stream.
TOGAF’s “more formal functional decomposition diagram” is a logical structure with no hint of process flow.
“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". https://en.wikipedia.org/wiki/Value_stream_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.
You don’t have to document everything about a business that could be documented.
And the aim here is not to promote any particular business architecture framework, approach or diagram style.
The aim is to explain and relate the core concepts that underpin many approaches – in consistent and coherent way.
Business architecture in TOGAF 8 and 9 were based on the
concepts of what is here called “Service-Oriented Structured Analysis”.
This table classifies those core concepts.
|
|
Behavioral view of activities |
Structural view of activities |
|
|
Consumer view |
Business Services |
Business Interfaces |
|
|
Implementation view |
Processes |
Functions & Roles |
Logical Components |
|
(Process Instances) |
Organisation Units & Actors |
Physical Components |
Note that the TOGAF meta model does not feature Interfaces or Process Instances.
And ArchiMate classifies Functions under behavior, leading people to confuse Functions with Processes.
Inserting “Capability” into TOGAF has undermined understanding of its service-orientation and Structured Analysis artifacts
It has been inserted into the meta model without due regard to the concepts of Function and Service.
The result in the latest TOGAF is an unteachable conglomerate of business architecture approaches that use different vocabularies.
More generally, people interpret EA meta models and repository structures in different ways.
There is naive, confused, confusing and inconsistent EA practice.
For
more on the business architect role and concepts in a variety of role
definitions and frameworks, read The
practice of business architecture.
For some more detailed research, read
https://bit.ly/2Kpa80F.
For
more on the general system theory that underpins these matters, explore https://bit.ly/2yXGImr.
There follow some
points to remember.
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”)
· In most practical examples,
what is modelled in capability map looks no different from a function
hierarchy.
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.
· In
most practical examples, value streams are long-running processes.
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 (one-to-one)
Services
· 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 its implementation by processes.
· Beware! Business people use the term
service for what might be scoped in a service level agreement, which may
list many discrete services.
This section explores in some depth how people define capability.
Dictionaries (surveyed in writing this) typically define a capability as “the ability to do something or to achieve something”.
In other words, the ability to perform one or more activities and/or meet one or more aims.
In business architecture: “Capabilities are the abilities of an organisation.”
A business system may be observed in operation as a set of actors performing some activities to meet some aims.
An ordinary business develops and uses the ability to perform activities such as “sales”, “disaster recovery” or (much more fine-grained) “wheel replacement”.
The armed forces develop and use the ability to do such things as “control the air space over a territory”, or “rescue friendly forces from enemy territory”.
This table lists interpretations of capability that can be found in different EA/BA sources, which are not entirely consistent.
|
Which of the following statements do you think make sense? |
Comment |
|
1 A capability is an ability of a business (or
other entity). |
OK, compatible with
most definitions. |
|
2 A capability can be used by a business to
perform an activity. |
|
|
3 A capability can be used by a business to
achieve an aim. |
|
|
4 A capability can be developed. |
|
|
5 A capability can be exchanged (BIZBOK says). |
Appear incompatible
with 1, see NOTE below . |
|
6 A capability can be delivered (TOGAF says). |
|
|
7 A capability can act, can perform an
activity. |
Incompatible with 1
and most EA/BA thinking. |
|
8 A capability is concrete – composed of human
and technological resources that can act. |
DoDAF seems to
favours the concrete interpretation. MoDAF favours the
abstract reading; and TOGAF confuses the two |
|
9 A capability is abstract – defined without
reference to people, data or technology. |
|
|
10 An example could be “Manned interplanetary
travel”. |
OK if a capability
is attached to an abstract aim or goal. |
With respect to 5 and 6 in the table above, what
businesses exchange and deliver the products of using capabilities,
rather than the abilities themselves
Once a capability (aka ability, capacity, competency) has been developed, it can be used.
Sources:
·
Webster's: 1. The quality of being capable;
ability.
·
2. A talent or ability that has potential for development
or use.
·
3. The capacity to be used, treated, or developed
for a specific purpose.
·
Dictionary.com: Usually, capabilities.
qualities, abilities, features, etc., that can be used or developed.
When capabilities are used, what is
delivered, provided or produced are desired effects, types of effect,
services, courses of action or outcomes
Sources:
· DoDAF and JCIDS: The ability to achieve a desired effect…
· DDDS Counter (333/1)(A) (JC3IEDM) : The potential ability to do work, perform a function or mission, achieve an objective, or provide a service.
· NAF: The ability of one or more resources to deliver a specified type of effect or a specified course of action.
·
Wiktionary: The power or ability to generate an outcome.
The sources and definitions in black text in the table below are copied from this list of published in DoDAF .
The blue text – added here - distils the definitions to help us compare them, like with like.
|
The consensus?
In business architecture: “Capabilities are the abilities of an organisation”.
The blue text – added here - shows most definitions interpret capability as "an ability", and then apply it to activities and/or aims.
Here is an attempt to draw a consensus definition from those in the table above.
A capability is an ability (of actors), which can be used or developed, to perform activities, provide service(s) or achieve aim(s).
Note however that the definitions are not entirely consistent.
Two of them limit the concept of capability by relating it to a "course of action" (defined here as: “any sequence of activities that an individual or unit may follow.”
Which is to say a capability corresponds to a process.
And while a capability may be abstract (in MoDAF at least), when used by the military, it can refer to concrete set of human and technological resources.
Abstract
and concrete capabilities
A capability is an ability to be developed or used.
Consider the ability to ride a bicycle.
Before it is achieved it can be discussed as a goal.
When it is achieved, it can be discussed as an attribute of a complete concrete system (rider + bicycle + road surface).
It is an abstract capability until realised in a concrete system.
Capability-based planning may start by
defining an abstract capability as a goal.
E.g. MoDAF speaks of an abstract capability such as “Manned Interplanetary Travel”.
To do whatever is to be done, a business must develop and use the corresponding concrete capability.
DoDAF says a capability "occupies space and time" as though it is a concrete entity. .
Others speak of a capability as though it is a physical entity that has the ability to act as required.
This is to equate a capability with a group of actors (in a project, organisation unit or entire business) and all the resources used.
The required resources may include the 3 Ms: men, materials and machines (inc. computers, databases and networks).
And the knowledge, skills, energy and procedures that human actors need.
And even people trained to find whatever resources they need to achieve ad hoc aims.
In other words - the whole of the system or subsystem needed to demonstrate use of the capability.
In meta model terms, perhaps…
An abstract capability might be modelled as a very abstract supertype of other already abstract entity types, notably goal, service and function.
A concrete capability will be found in whatever resources are grouped in whatever system or subsystem realises the abstraction.
On
the questionable language used in standard definitions
Some speak as though capabilities are active structures that can act (e.g. deliver something).
But you can’t ask an ability do something; you must ask an active structure that possesses the ability (e.g. to deliver something).
Some speak as though capabilities are passive structures that can be acted on (e.g. can be delivered or exchanged).
But given a capability has been developed and used, then what is acted on are the result or products of using that ability.
You might think this lexical analysis is pointless nit-picking
But departing from natural language in defining business architecture concepts tends to obscure what they mean and how they relate to each other.
E.g. to speak, as TOGAF does, of delivering a capability is odd.
Surely what businesses deliver are the products or results of using a capability, not the ability itself?
In “A Business-Oriented Foundation for Service Orientation”, 2006, Ulrich Homann defined capability thus.
“A particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.”
But to speak of exchanging a capability is odd.
Surely what businesses exchange are the products or results of using a capability, not the ability itself?
The Business Architecture Guild’s BIZBOK glossary defines capability as Homann did.
“A particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.
The words particular and specific are redundant in this glossary entry.
The glossary separately defines a “capability instance” as a “specific realization”.
In DoDAF, an aim is called “a desired effect” meaning “the result, outcome, or consequence of an action”.
It defines “capability” as “the ability to achieve a desired effect…”
But singular associations (like 1 capability to 1 desired effect) are always questionable, and can be needless constraints.
If capabilities/abilities are composable and decomposable, then desired effects and activities must also be composable and decomposable.
Better, NATO’s Architecture Framework defines “capability” as “the abilities required for conducting operations in order to reach desired effects”.
Here, 1 capability relates to one or more desired effects.
All is recursive.
Grouping smaller/shorter things into larger/longer things – in a hierarchy - is a primary analysis and design technique.
It is used in most EA reference models and frameworks to help people understand and manage things.
Here are four common hierarchical structures.
|
Motivations |
Goal/objective hierarchy |
as
in a strategy map or a balanced score card. |
|
Physical
active structure |
Organization hierarchy |
dividing
people and resources for management purposes. |
|
Logical
active structure |
Function and/or capability
hierarchy |
dividing
larger/wider functions or capabilities
smaller/narrower functions or capabilities. |
|
Behaviors |
Process hierarchies |
dividing
each long-running process or value stream
into shorter processes. |
Corresponding and clashing hierarchies
Any two hierarchies may correspond, or else
clash to a greater or lesser degree.
Two
structures are said to clash when different hierarchies
are imposed over the same or related elements.
The science
of corresponding and clashing hierarchies can be traced back through Michal A.
Jackson (1975) to earlier sources.
In software design,
any two data structures read and written by a program must either correspond or
clash.
When they
correspond, the data structures can be merged into one program structure.
When they
clash (Jackson showed) the program is better divided into application
components that each process a different data structure.
Corresponding structures
You may base one hierarchy on another.
· Managers may create a “functional
organization” by defining an organization structure to match a logical function
hierarchy.
· Architects may align a function
hierarchy with a goal/objective hierarchy.
· Although the concepts of capability
and function differ, they are naturally organised under hierarchies that
correspond to each other.
Wherever two hierarchies correspond, you may merge and maintain them in
one structure, though this is a hostage to fortune.
Clashing structures
Given two structures are in correspondence, you may change one without
the other.
E.g. an organization’s management structure may be restructured by
location, customer type, product type or resource type.
This may be done without significantly changing what the business does,
as shown in a function hierarchy.
And that is
the major reason for basing business architecture documentation on the latter
rather than the former.
Duplication or
reuse of elements in different legs of a hierarchy?
You may find
some common or shared elements in different legs of a hierarchy, which may be
reused by delegation.
If you
decompose a business capability or function hierarchy far enough, you will
reach some capabilities or functions that are shared or generic.
But if you
follow the convention to decompose to only a 3rd or 4th
level, you are unlikely to find those common elements.
(By contrast,
class hierarchies abstract from the bottom up by generalization.
You will find
common or shared elements at the top, which may be reused by inheritance.)
There are
two ways to model communication between active structural elements (square
boxes):
a) as an
arrow showing one or more services are provided by a "server"
box to "consumer" box, or
b) as arrows
showing data/info flows between boxes.
The former
is more abstract; the latter is more informative.
It usually
seems over the top to do both.
The square
boxes can be components and/or interfaces; modelling both seems over the top in
many published examples.
The protocol
used to send or receive a data/info flow could be shown as an annotation
on it (rather than an interface).
In reality,
flows are often two-way, yet people often ignore the request in a request-reply
exchange, and error replies in other cases.
The service
and the main flow of interest point in opposite directions when invoking a
service to update or post some data.
Discussion
of EA is terminology torture.
“Enterprise Architecting, Enterprise
Engineering, and Organization Design all seem to refer to activities with the
same possible concerns and outcomes.”
Lapalme (2012)
Lapalme tried to divide EA into three
schools that might crudely be called IT, integration and adaptation
But mainstream EA cuts across all
three schools.
Discussion of systems is also terminology
torture.
Lapalme sought to promote the use of
“systems thinking” in his second and third schools.
But did not distinguish general system
theory from socio-cultural systems thinking.
General system theory about activity
systems – human or other – that can be modelled.
In much socio-cultural systems
thinking discussion, it is hard to identify what the “system” is, let alone
model it.
Remember, no model,
no architecture, just stuff happening in an unknown way.
See EA as applied system theory for detailed discussion.
This footnote maps some general system ideas to terms of EA frameworks (like TOGAF and NAF)
And of modelling
languages (like ArchiMate and UML).
|
General system ideas |
Defined in terms of business activities |
Business system ideas |
Application system ideas |
|
Aim |
A testable target for the outcome(s) of
activities. |
Business goal |
Software requirement |
|
Behavior |
A contract defining the request for and
result/outcomes of required activities. |
Business service |
Application service |
|
A behavior (e.g. value stream, use case
or epic) that sequences activities. |
Process |
Application process |
|
|
Abstract structure |
A group of services or activities
performable by an organisation/actor/component. |
Role |
Application interface |
|
Business function |
|||
|
Concrete structure |
A deployable managed unit that realises
services by performing activities in processes. |
Actor |
Application component |
|
Organisation |
Every designed
system can be described in terms of
structures that perform some behaviors to meet some aims.
And it exists in two
forms, in logical specification at design time and in concrete operation at run
time.
|
Abstract or concrete? |
Persistent
structures |
|
Transient behaviors |
|
|
Business organisation |
In logical specification |
business functions |
are specified as acting in |
business processes (aka value streams). |
|
In concrete operation |
organisation units |
realise functions |
by performing activities in business
processes. |
|
|
Business people |
In logical specification |
roles |
are responsible for performing |
activities (aka
tasks or sub processes). |
|
In concrete operation |
actors |
realise the roles |
by performing the activities. |
|
|
Business applications |
In logical specification |
applications
|
are specified as acting in |
use cases
or user stories. |
|
In concrete operation |
deployed software |
realises the applications |
by directing the use cases or user
stories. |
This table brings these ideas together using terms in TOGAF.
|
|
Required
behaviors |
Logical
active structures |
Physical
active structures |
|
Business |
Business Services Business Processes |
Business Functions Roles |
Organization Units Actors |
|
Information
Systems |
Application/IS Services |
Logical Application Components |
Physical Application Components |
|
Technology |
Platform Services |
Logical Technology Components |
Physical Technology Components |
This table
generalises business architecture entities that appear in EA frameworks (like
TOGAF and NAF) and modelling languages (like ArchiMate and UML).
|
Business architecture entities |
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 behavior performable by a business
component that produces a result of value to its consumer. An external view, a logical contract,
that encapsulates whatever process(es) are needed to deliver the desired
result. |
|
Process |
A sequence of activities performed by
the actors in a business in the course of delivering a business service. A process may occur within one
organization or function, or coordinate activities in several organizations
or functions. |
|
Logical structures |
groups of behaviors that are assignable to active structures |
|
Function |
A logical business component. A node in a business structure that
represents a subdivision and group of its logical activities and
capabilities. It is describable
externally by services provided and internally by activities assignable to
organisation units. |
|
Role |
A business function performable by one or more
actors with the requisite capabilities. It is describable
externally by services provided and internally by activities assignable to an
actor. |
|
Active structures (who) |
things that perform behaviors |
|
Organisation unit |
A real business component, capable of
realising one or more logical functions. A node in a management structure that
subdivides and groups its physical actors, and perhaps resources also. Note: in the special case of a “functional
organization”, each organization unit realises one business function. |
|
Actor |
An entity capable of realising one or
more roles; typically assigned to a bottom-level organization unit. |
|
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, created and used in the course of
performing behaviors. |
|
Location (where) |
A place where actors, components or
entities are found and work is done. |
Aside on data
The EA/BA concerns about information differ from those in Shannon’s “information theory” for maintaining the integrity of physical data structures.
They relate instead to the capture, use and value of the logical information/meaning that actors create and find in data structures.
Information about business entities and events is stored and exchanged using a domain-specific vocabulary in which every term has a specific meaning.
E.g. Loan amount, Required qualification, Capital gain, Airplane position, speed and direction.
Aside on actors
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.