Business Capabilities

as the Cornerstone of Your

Digital Transformation Strategy

Authors:
Marc Lankhorst
Bernd Ihnen
Jeeps Rekhi
Sven van Dijk
Henk Jonkers
1
Table of Contents

Introduction ........................................................................................................................ 3

1. Why Capabilities are key in Business Architecture ............................................................ 4

2. What are Business Capabilities? ..................................................................................... 7

3. How Business Capability Maps Help Senior Management to Make Better Investment
Decisions ....................................................................................................................... 11

4. Design Principles for Business Capability Maps  ............................................................. 15

5. Relating Capabilities to ‘Strategy’ and ‘Business Model’ .................................................. 21

6. Linking Capabilities to the Operating Model: Business Functions and Organizational

Structure ......................................................................................................................25

7. Mapping the BIZBOK® Metamodel to the ArchiMate® Language ....................................27

8. How to Assess Business Capabilities  ............................................................................. 30

9. How to Measure Capability Dimensions .........................................................................33

10. How to Model Capabilities Over Time and Describe Different Instances  ........................ 36

11. Directing Strategic Change With Capability-based Planning ......................................... 40

12. Measuring the Effectiveness of Change Investments using Capability-based Planning ... 45

13. Capability Governance: The ‘Who’ Dimension of Capability-based Planning  ................ 50

14. Capability Governance Tailored to Customers’ Needs  ...................................................53

15. Overcoming Obstacles to Successful Implementation .................................................... 56

16. A 10-step Approach to Implement and Grow Capability-based Planning ....................... 59

Need help with Capability-based Planning?  ....................................................................... 63

Contributors ...................................................................................................................... 64

2
 Introduction

Introduction 
Capabilities are the core of your business architecture.  

Start by reading our eBook on Capability-Based Planning.  

Imagine the following scenario: your C-level management needs to execute on the organi-
zation’s digital transformation strategy. To improve customer experience, the OCIO needs
to implement digital tools to enforce a customer-centric journey. To support their strategic
planning aligning business and IT and investment prioritization, they turn to you, as their
architect or designer. 

The scenario we describe above could be applicable to any large digital transformation
project. To support you, we’ve created a comprehensive eBook on Capability-based Planning –
included you’ll find everything you need to know on Business Capabilities, Business Architecture
and how to support your organization’s Digital Transformation strategy.  

Business capabilities are stable building blocks that define what an organization does.
They encompass elements such as people, processes and systems that come together to
realize specific functions. Due to their relatively lasting nature and the way they consolidate
various cross-domain components, capabilities are a very useful tool for facilitating dialogue
between stakeholders on the business and IT sides of the organization.  

By managing and planning the way these capabilities and their constituents interact
with strategy and with, among others, technology components, organizations can better
navigate and execute on transformation projects. 

This eBook aims to help you understand, implement and use the practice of Capability-Based
Planning in your organization. It covers a wide range of subjects aimed at helping you use the
broad scope and analytical toolset of enterprise architecture to identify valuable insights that
can provide decision support to the C-level management to execute the organization’s trans-
formation strategy.   

3
 Why Capabilities are key in Business Architecture

1. Why Capabilities are key in Business Architecture 

Many organizations struggle to make optimal strategic decisions, because they lack an under-
standing of the ‘big picture’ of their enterprise. They have challenges like: 

● Difficulty to assess global performance, rather than performance of local busi-

nesses and applications 

Enterprises often find it challenging to get an enterprise-wide perspective on business perfor-

mance. An enterprise is made up of people, processes, information, and technology (both IT
and operational), but it’s often unclear how these assets contribute to business goals. This lack
of alignment makes it difficult to assess performance of the organization against the strategic
goals of the business at a global level. 

● Budgets are not unlimited and multiple initiatives compete for those budgets 

Prioritizing investments is a complex task. Portfolios are often crowded with initiatives
competing for limited budget, so how do we decide which initiatives will contribute the most to
strategic goals? All too often, portfolio management is ‘decibel-driven’, where those with the
loudest voices will get their projects approved. 

● Outcomes of individual projects do not always support common business goals 

There are many change initiatives taking place at the same time, often executed using agile
approaches, mostly in a fairly independent way. How do we ensure these initiatives stay aligned
with the goals of the business? 

Business Architecture to the rescue 

As an architect or designer, you’ll of course know that any good design starts with the ‘why’.
The purpose and desired effects of what you design. In designing enterprises, this purpose
is captured in things like its mission statement and in its business model, in terms of e.g. the
customers it serves and its value to them.  

Next, you look at ‘what’ your enterprise can or must do to achieve those effects. And only then
will you design ‘how’ you are going to do that. You don’t want to get bogged down in organiza-
tional or technical details when trying to understand what an enterprise does for its customers,
for instance. 

Designing this ‘what’ of enterprises is where the discipline of business architecture comes in.
Business architecture has several important contributions to make: 

● It lets you accurately describe what the organization does and how it functions.
This creates a common understanding of the enterprise for business and IT

4
 Why Capabilities are key in Business Architecture

stakeholders alike. 

● It supports the alignment of strategic objectives and tactical demands, ensuring

optimal strategy execution. 

● It guides and informs senior management’s decision-making process and con-

tributes to the enterprise’s long-term success. 

The ‘what’ of an enterprise – an explanation 

As mentioned, you need to understand and design what an enterprise can and must do to
fulfil its mission, before diving into the organization structure, business processes, IT systems,
and other implementation aspects. This provides the ‘big picture’ needed to deal with the
challenges your enterprise may be facing. Firstly, get away from organizational politics and
technical limitations and look at the essence of what’s needed. 

This is where the concept of business capability comes in. Business capabilities are used to
describe the abilities of an enterprise, i.e., what it is able to do, independent from implemen-
tation. Looking for example at a bank, there they do pretty much the same things today as
they did 100 years ago. So you could say that the set of business capabilities is pretty much still
the same. But how they do it is very differently today, especially the last few decades driven
by technological advances.  

Moreover, you can use capabilities not only to describe what the enterprise does today, but
also to design the abilities it needs to have tomorrow. And you may even discover new ca-
pabilities you didn’t even know your enterprise had. Maturing existing, or even building new
capabilities is where the concept of capability-based planning comes in, and provides a struc-
tured, and balanced approach to support an organizations strategic planning cycle.

Figure 1 Enterprise Goal

5
 Why Capabilities are key in Business Architecture

This differentiates business capabilities from concepts like ‘business function’ which is more
focused on day-to-day operations, on what the enterprise does rather than what the enter-
prise can do (or can do better). What it can do, of course, includes what it does today, but it also
describes its potential. This is what makes it especially relevant in strategic discussions.  

Importantly, the concept of capability is cross-functional and cross-organizational. Capabili-

ties are not tied to specific departments, functions, or roles in the organization. Rather, what
gives you a capability is the combination of various people, processes, technology, information,
and other resources, from across the entire enterprise. 

This also makes it a notion that is very much focused on collaboration. Different parts of the
organization together provide your enterprise with its capabilities, and possibly this collabora-
tion even stretches beyond the borders of the organization, including partners in its ecosystem.  

6
 What are Business Capabilities? 

2. What are Business Capabilities? 

What exactly are Business Capabilities and how do you define capabilities?  

You need to understand and design what an enterprise can and must do to fulfil its mission,
before diving into the organizational structure, business processes, IT systems, and other im-
plementation aspects. This provides the ‘big picture’ needed to deal with the challenges enter-
prises face. We would like to advise you to get away from organizational politics and technical
limitations and look at the essence of what’s needed. 

We said that business capabilities are used to describe the abilities of an enterprise, i.e., what it
is able to do, independent from implementation. What it can do of course includes what it does
today, but it also describes its potential. This is what makes it especially relevant in strategic
discussions.  

In enterprise and business architecture, the concept was introduced mainly from the defense
domain. To quote from the NATO Architecture Framework: “A capability is the ability to achieve
a desired effect under specified standards and conditions. […] In NAF, the term is reserved
for the specification of an ability to achieve an outcome. In that sense, it is dispositional – i.e.
resources may possess a Capability even if they have never manifested that capability.” 

Importantly, the concept of capability is cross-functional and cross-organizational. Capabil-

ities are not tied to specific departments, functions or roles in the organization. Rather, what
gives you a capability is the combination of various people, processes, technology, information,
and other resources, from across the entire enterprise. 

In identifying capabilities, you want to ensure that they are not bound to any specific implemen-
tation. For instance, ask yourself if a business capability would change if you would split up a
department or implement a new system involved in delivering that capability. If it would, then
probably you didn’t identify a true capability. 

This abstraction from implementation is also what makes the concept sometimes a bit difficult
to understand and communicate. Most people instinctively reason in terms of organizational
structure, span of control, the systems they own or the business processes they manage or
execute, etc. For instance, when showing a Capability Map to managers, they often look for
‘their’ bit, where they think they’re responsible because it resembles e.g. their department. This
is, of course, a misconception, but it is not always easy to overcome this instinctive reaction.  

7
 What are Business Capabilities? 

Source: Horizzon 
Figure 2 Simplified capability map of an insurance company (inspired by the Panorama 360 reference model) 

Identification and naming of Business Capabilities 

Key in defining business capabilities is therefore that they’re named and defined in business
terms by subject matter experts (often called ‘the business’ by IT people, but that’s a dangerous
catch-all term rather to be avoided). For any capability, it should be crystal clear what it does
for the business. All too often, we see capability maps conjured by IT architects without suf-
ficient business input, and using technical terms and system-level functionalities rather than
true business capabilities focused on producing some data rather than delivering real business
outcomes.  

It helps to use a naming scheme that clearly differentiates capabilities from other concepts, for
instance business processes and value streams. A process or value stream defines the ‘business
in motion’ sequencing activities to create a dynamic perspective on business behavior. Capa-
bilities, in turn, define the potential behavior of an enterprise, the ‘business at rest’, its abilities.
Processes and value streams are often named with a verb-noun scheme, e.g. ‘Adjudicate
Insurance Claim’. Verbs are therefore best avoided in capability names, to avoid confusion
and stress the ‘business at rest’ perspective. Such a naming scheme also helps in identifying
capabilities. If you’re tempted to name a capability like a business process, are you sure you
really found a capability? 

One approach, advocated by the BIZBOK® Guide, is to identify every capability based on
a specific business object and name it with a ‘business object – action’ naming convention.
According to the BIZBOK, this action must not be expressed with a verb; even gerunds (a word

8
 What are Business Capabilities? 

that ends in an -ing and is used as a noun) like Engineering, Marketing, and Accounting are
explicitly forbidden.  

According to the BIZBOK: “Mapping teams should avoid using gerunds as the basis for capa-
bility names as they’re not business objects and are only nouns in the nominal sense”. However,
BIZBOK’s own examples don’t even adhere to this commandment. This approach shows a
focus on information/ data rather than on the true abilities of the business.  

Best approach - stay focused on the business 

Rather than only allowing business objects as the basis for decomposing and discriminating
between capabilities, we favor using the classical notions of coupling and cohesion. Select busi-
ness-relevant criteria that creates the highest internal cohesion and the lowest external coupling
of capabilities. This gives you self-contained capabilities that have a relatively independent
existence and can function as true business components. Business objects are certainly one
way of clustering the abilities of an enterprise but are by no means the only criterion. Markets,
regions, regulatory compliance regimes, pace of change, social relations, and various other
aspects can factor into the identification and decomposition of capabilities.  

Of course, you want to stay away from implementation detail and stay focused on the essence,
but this is a gradual distinction, not something absolute. As architects, we tend to be good at
generalizing and abstracting, but we need to be careful. No enterprise exists without real people
performing concrete activities in the context of a social fabric. If you abstract too much from
that, you will surely lose your business audience.  

So don’t be distracted by all too rigid or abstract identification or naming schemes. By far the
most important is that the name of a capability is widely recognized, and its definition is under-
stood by all stakeholders involved as something the enterprise is able to do. Consistency and
abstraction from implementation detail are important and useful, but not if they come at the
cost of business understanding. 

Guidelines for identifying business capabilities 

These general guidelines will help you identify your business capabilities: 

● Capabilities define what your business does or can do, not how it does it or who
is doing it. Capabilities are different from business processes, functions, services,
organization units, or IT systems, although these may all contribute to a capa-
bility. The same capability may be implemented in different ways, e.g. manually,
IT-supported, or fully automated.  

● Capabilities are owned by your business and named and defined in business
terms. Their definition should be readily understandable by all stakeholders.  

● Capabilities are unique and stable. They’re defined only once for the whole en-

9
 What are Business Capabilities? 

terprise and they rarely change, unless, for example, your organization under-
takes a new line of business or divests some of its current operations.  

● Capabilities may consist of sub-capabilities. A capability may also use other ca-
pabilities.   

● Capabilities can be organized in a capability map, which provides an overview of

your entire enterprise.   

● A capability’s maturity can be assessed across different dimensions, such as

people, process, technology, information, and other resources. Such assess-
ments are the basis for capability-based planning.  

Useful tips in identifying business capabilities 

● Involve business experts right from the start and create a cross-disciplinary ca-
pability mapping team. Don’t let architects define the capabilities in isolation, and
only asking business experts for a review afterwards. 

● Use capability reference models from industry forums as inspiration and starting
point for your own work. They can also help you identify what your differentiating
capabilities are, by comparing them to what the industry standard is. 

● Ensure your capabilities are mutually exclusive and collectively exhaustive: there
should be no overlaps or gaps between them. 

● Don’t be constrained by formal identification and naming schemes that don’t

match business terms and understanding. 

10
 How Business Capability Maps Help Senior Management to Make Better Investment Decisions

3. How Business Capability Maps Help Senior Management

to Make Better Investment Decisions 
Today we live in a rapidly changing world. Senior management is faced with various change
initiatives to improve the different functions of an enterprise. All of these change initiatives are
backed by well-informed arguments and compete for budgets. Although strategic manage-
ment has access to a vast amount of information and tools to support strategic, tactical, and
operational decision-making, they often lack a holistic view on budget allocation to track how
investments are creating value for the enterprise.  

Using a Business Capability Map as framework for investment decisions and change designs
has received increased traction over the last decade. With a ‘Business Capability Map’, senior
management has the ability to analyze an enterprise by looking at it holistically, through a
business perspective lens.  

A business capability map describes what the enterprise may have the ability to do, indepen-
dent from how those things are done, looking at people, processes, technology, information,
or physical resources.  

By using Business Capability Maps, senior management can now make more effective invest-
ment decisions while also empowering enterprise and business architects to support them more
efficiently. In turn, architects can increase the efficiency of future operating model designs and
analyze business capability improvements. 

Stakeholders benefiting from a Business Capability Map 

Who are the primary enterprise stakeholders benefiting from a Business Capability Map? A
stakeholder is an individual or organization that has substantive impact on the business of an
enterprise and can be internal (for example an employee) or external (for example a customer
or a partner).  

Stakeholders typically utilize capability maps for decision making while architects support them
in this function. Therefore, the primary stakeholders for a Business Capability Map are C-level
executive management and their direct reports, and senior business leadership with titles such
as Vice President or Director. They sponsor the design and use of capability maps as a tool for
improving the business.  

However, there may be many other individuals working “within” this framework (for example
strategists, business analysts, managers/ owners of the processes, technology, information,
and resources) that also benefit from utilizing a Business Capability Map. Designing a holistic
and sound capability map usually is the responsibility of enterprise and/ or business architects.
Capability maps communicate in business terms what an enterprise is capable of, regardless
of how it is currently doing it.  

11
 How Business Capability Maps Help Senior Management to Make Better Investment Decisions

Purpose of a Business Capability Map  

Effective investment decision-making 
A top priority for senior management is to make better decisions while ensuring that budgets
for investments are allocated effectively. Digital businesses today are becoming a source of
competitive advantage. The ability to quickly steer the organization towards its strategic goals
and adapt faster and more effectively to changes in this competitive landscape, is becoming a
critical success factor for enterprise leadership. A Capability Map provides executives with an
enterprise-wide perspective of the impact of their investments.  

Most importantly, a Capability Map indicates which capabilities will be improved. This is crucial
when assessing competing demands for investment budgets on a ‘level playing field’, indepen-
dent of the specific details of each demand. In other words, it provides a way of comparing
‘apples with apples’ when evaluating the benefits of multiple initiatives, in terms of which capa-
bilities are improved, and by how much. This enables visibility and transparency of alignment
with strategic priorities ensuring that there aren’t gaps in the investment portfolio where key
capabilities aren’t addressed. 

A Business Capability Map also supports senior management to determine whether their in-
vestments are moving in a strategic direction. This is done by assessing business capabilities
for strategic relevance.  

Source: Horizzon 
Figure 3 A Business Capability Map in Bizzdesign Horizzon which supports customers to make effective invest-
ment decisions by connecting business capabilities with strategic relevance. The map shows gaps in
areas between planned investments and the strategic direction of the enterprise

12
 How Business Capability Maps Help Senior Management to Make Better Investment Decisions

Efficient capability transformation design 

While business capability maps provide stakeholders with the ability to make effective decisions,
the next step is to realize the change. A capability touches many aspects in an enterprise and
typically includes people, processes, technology, information, and physical resources. How can
senior management ensure that everyone and everything operate in the context of a business
capability? Additionally, analyzing the ‘as-is’ state and designing the future operation model of
a capability is often complex.  

ArchiMate and other standards provide a common language that helps architects and
business analysts address the complexity and raise the efficiency of the analysis and future
design. ArchiMate provides high-level overviews for heat mapping, as well as detailed designs
of processes, application, technology, data, and security architectures.  

Feedback from Bizzdesign’s customers indicate that by utilizing ArchiMate they were able to
decrease the time it takes to create and analyze future designs by 20-30%.  However, it’s more
than just drawing a diagram. When a common language is used, communication and collabo-
ration between stakeholders improve when they design the future of the enterprise.  

Source: Horizzon 
Figure 4 An example of a target operating model design. Changes are highlighted in green 

How to track improvements in capabilities 

Another important benefit, apart from enabling assessment of the strategic relevance of ca-
pabilities, is that Business Capability Maps enable stakeholders to assess and track the maturity
of capabilities. A map provides insights on where senior management needs to improve the
capabilities of their enterprise. However, can they measure the maturity of current and future
business capabilities? 

13
 How Business Capability Maps Help Senior Management to Make Better Investment Decisions

Source: Horizzon 
Figure 5 Spider chart

Senior management can use spider charts to visualize a capability assessment. For the ‘Claim
management’ capability, six dimensions are defined, and it shows how the process dimension is
broken down into more details. The baseline analysis for this capability results in values for the
different dimensions, which are linked using the red line. The required maturity, broken down
into values for the individual dimensions, is indicated with a green line.  

  

14
 Design Principles for Business Capability Maps  

4. Design Principles for Business Capability Maps  

To successfully design Business Capabilities and Business Capability Maps, it’s important to
consider design principles.  

 
1
  Strategic
Business Management

3
Strategic Fiscal & Accounting Risk & Compliance Performance Enterprise
Management Management Management Management Architecture

Core

Customer Management
Asset Management

2
Customer Contact Customer Relation
Investment
Investment Strategy Management Management
Performance

4
Management
Management

Service Channel Customer Data

Investment Portfolio Asset Inventory Management Management
Management Maintenance

Business
Capabilities
Policy and Claim Management
Money Management
Contract Lifecycle
Claim Settlement
Banking Accounts Management
Management Management

Contract
Claim Administration

5
Cash Flow Money Market Administration
Management Management

Support
Business Support
Organizational Process
HR Management Office Management Facility Management IT Management
Development Management

1) Stakeholder
2) Capability map structure
3) Capability definition
4) Capability decomposition
5) Visual appeal
Figure 6 Areas of concern in designing a Business Capability Map

The stakeholder  
Business capability maps enable C-level and upper management to look at the enterprise
through the lens of capabilities. They use it to advance their strategy and guide investment
plans. This has implications for the design of the Capability Map. What do you need to consider? 

In practice, Business Capability Maps are often defined by IT roles. This affects how Capabili-
ties are described and on which terms. It’s important to keep in mind that the Capability Map
is used by business leaders. Therefore, the description of the design needs to match wording
these leaders can understand in a technology-neutral manner. Otherwise, the view of the en-
terprise is created through the lens of IT and too abstract.  

15
 Design Principles for Business Capability Maps  

If the Capability Map is not regarded as an accurate and meaningful description of the
business activities of the enterprise, as perceived by senior business leadership, then it will not
gain traction as a collaboration tool for planning and business design. 

Another aspect is the positioning of other planning and design frameworks. Think of a Business
Process Map or Application and Technology Portfolio categorizations. Will the Capability Map
replace all those maps and frameworks? Certainly not, because these frameworks provide
stakeholder-specific viewpoints. The Business Process Map looks at the enterprise through
the lens of operational processes, and the application framework is a way to look at the IT
landscape through the lens of Application Portfolios.  

These different maps and frameworks can also be related. For instance, we have seen in
practice that it’s useful to analyze which applications realize which business capabilities, as well
as which application portfolio category they belong to. This helps to connect different stake-
holders, especially in the early stages of introducing the Business Capability Map to an orga-
nization. 

Capability map structure 

A complete Business Capability Map typically includes many capabilities which need to be
structured in a meaningful way. There are different approaches to categorizing business ca-
pabilities. For inspirational purposes, we’d like to give a few common examples: 

● Strategic vs. Operational vs. Supporting or Enabling Capabilities 

● Customer-facing vs. Operational vs. Shared vs. Change Capabilities 

● Core vs. Non-core Capabilities 

● Customer-facing vs. Internal Capabilities 

● Innovative vs. Differentiating vs. Commodity Capabilities 

In practice, we often see Strategic vs. Operational vs. Supporting Capabilities used to differ-
entiate capabilities into strategic, operational, or supporting. Especially in the industry sector,
where the main focus is often on the operational capabilities relating to the production and
delivery of the products.  

Note that the classification of a Capability can vary, depending on the industry or strategy of
a company. For example, an HR capability in industry is often classified as supporting capa-
bility, while in (consulting) services, it might have a more prominent role – depending on the
company’s strategy. A customer-facing classification makes sense when looking at client-fac-
ing capabilities. The classification for innovative, differentiating, and commodity capabilities is
inspired by the Gartner pace layer idea. You can also combine these classifications in a heat
map.  

16
 Design Principles for Business Capability Maps  

Source: Horizzon 
Figure 7 An ArchiSurance Capability Map that combines the following categories: Strategic vs. Operational vs.
Support; and Innovative vs. Differentiating vs. Commodity 

Visual appeal of a map 

C-level and business leaders are confronted by many presentations, project pitches and they’re
typically very busy and need to form an opinion quickly. Keep in mind that you only have 50 mil-
liseconds to make a good first impression! (Source) Give your Capability Model the necessary
visual appeal to clearly show its value.  

A first impression depends on different factors. It is largely based on colorfulness and the com-
plexity of a graphic. Your audience’s age, gender, and education levels all influence how colorful
and complex your Capability Map should be (Source). We recommend designing an engaging
capability map! Use a clear structure, graphical structuring elements, corporate colors, icons,
and of course, align the boxes. You may want to approach design experts to help you make
your map visually appealing.  

All these suggestions sound simple, but it’s often not widely used because of tool limitations
to model a Capability Map. Refer to the above ArchiSurance Capability Map as an example
of how to create simple columns or rows. This map includes corporate colors and graphical
elements that will easily appeal to business stakeholders. 

17
 Design Principles for Business Capability Maps  

Capability definition 
There are two general principles that you need to follow when defining Capabilities: 

● Business capabilities are represented and defined by the business: it’s not an ‘IT
thing’! 

● Business capabilities are unique, mutually exclusive and collectively exhaustive:

ensure that there are no duplicates, overlaps or gaps 

Try to avoid duplicate or overlapping capability definitions, although this may be difficult in
your first version of the Capability Map. You won’t know whether you have duplicates until
you’ve created the first map! Business capabilities should be unique and mutually exclusive, and
together they should cover your entire business. However, you may have variants of capabil-
ity names such as Performance Measuring for financial performance, production, sales, etc.
Always keep in mind the main stakeholder and the intended usage of your Capability Maps. 

Define Business Capabilities in business terms 

The name of a capability needs to be clear for business leaders because they often don’t un-
derstand techspeak. Use business language that resonates with senior managers and other
stakeholders instead of rigid naming conventions.  

The name of a capability should emphasize ‘what we do’ rather than ‘how we do it’. It’s
important to adopt names that resonate with senior managers and stakeholders. Typically
expressed as a compound noun or gerund (-ing form of a verb). E.g. ‘Project Management’,
‘Market Development’, and ‘Product Engineering’. Capabilities are often based on a business
object, e.g. ‘Product Design’, ‘Risk Assessment’, ‘Materials Procurement’, but don’t make this a
naming convention restriction to avoid turning your capability map into a business object map.  

Add short descriptions to your capabilities to make the definition of it clear. This will steer the
stakeholders’ thinking process in the direction you intended. When you’re adding short descrip-
tions, be:  

● Precise: Explain – don’t simply repeat the name of the capability in the descrip-
tion. For example, use the following wording: ‘the ability to…’. 

● Concise: Provide just enough details to indicate what is / what isn’t included.  

● Informal: Focus on getting the message across by using phrases or single words
and not grammatically correct sentences, which could take a lot of time to read.  

18
 Design Principles for Business Capability Maps  

Business capabilities are stable and implementation-neutral 

Judy Goldberg, former Executive Director at Sony and founder of Wondershift rightly mentioned:
“You don´t need a digital strategy. You need a business strategy for the digital age”. When de-
scribing a Business Capability Map, don’t distinguish between business and IT capabilities. 

A case in point is that an enterprise that produces fruits has been doing the “same” over
decades. Techniques and technologies for producing fruit may have changed over the years,
but what the company does has remained the same provided that they haven’t changed their
business model.  

An automated capability is still a business and not an IT capability. The description of how you
realize a capability is important, but this should be part of the operating model description that
you design in ArchiMate with core concepts, such as functions, processes, application compo-
nents and other business/ application/ technology concepts. 

Capability decomposition 
Important and somewhat challenging questions are: “Which capability elements do you ‘bundle’
together, and how do you decompose a Capability Map?” 

Identify the capability resources with the highest cohesion. This is a general architecture design
principle and will guide you on the path to designing an adaptive enterprise. Aim for high
cohesion inside of a capability and loose coupling between capabilities. Cohesion is defined
by strong relations between resources. These resources form a business capability and usually
consist of people and their roles and skills, process, technology, information, infrastructure,
and natural resources. Questions you need to discuss include: 

● Which resource type has the highest cohesion?  

● Do we need to center a capability around information, buildings, machines…?  

The webinar Capability Maps the Next Generation presented by Wolfgang Goebl discusses
this topic in detail.  

How to start? 
Now that we’ve shared the design principles, you may be wondering where to start? You need
to have a mandate to architect a business capability map! Without proper sponsoring, you’ll
have a hard time getting engagement from the required subject matter experts to resolve
the inevitable issues/ conflicts. You also won’t have any customers for your Capability Map.
Creating a Capability Map without a sponsor is therefore futile.  

You’ll also need to know which analysis and decisions the sponsor wants to make based on the
Business Capability Map. What’s the purpose? For a quick start, reuse existing internal and

19
 Design Principles for Business Capability Maps  

external information (e.g. previous Capability Maps, consultant findings), industry references
(e.g. sector capability models), organizational charts and process models. Use the design prin-
ciples to define, refine and test the Business Capability Map through socialization and valida-
tion cycles. Ensure to include all the relevant business functions, and not only IT.  

  

20
 Relating Capabilities to ‘Strategy’ and ‘Business Model’

5. Relating Capabilities to ‘Strategy’ and ‘Business Model’ 

The relationship between business strategy and capabilities is a two-way street. On the one
hand, the strategy of an enterprise is a way of configuring its capabilities and resources to
achieve certain goals. This may entail improving some capabilities, developing or acquiring
completely new ones, or even divesting some non-core, non-strategic capabilities. 

On the other hand, your existing capabilities may lead you to pursue entirely new ventures. As
several manufacturing companies learned at the start of the Covid pandemic, their existing
capabilities allowed them to shift focus to the production of personal protective equipment or
even more specialized products like ventilators. This is exactly what Demcon did, the company
next door to Bizzdesign’s head office in Enschede: They developed, produced, tested, and
delivered complete ventilation systems within the space of one month, using their pre-existing
capabilities in producing related technology. 

Mapping the strategic relevance of your capabilities and combining this with information on
cost and investment, is a great way to support management decision making.  

Source: Horizzon 
Figure 8 A capability heat map with IT investment levels (color) vs. strategic importance (label) used by a
Bizzdesign customer 

21
 Relating Capabilities to ‘Strategy’ and ‘Business Model’

The example in the above figure shows (with different colors) the total IT cost for each capability
(red = high, green = low), calculated as a roll-up of the operational cost of existing systems (run)
and the investment in new IT (change). This cost is distributed across the capabilities according
to the use the customer makes of these systems. Labels depict the strategic importance level of
each capability, which is calculated as a weighted average of a capability’s relevance in terms
of the company’s 5 strategic, long-term goals.  

The company’s program portfolio board uses these heat maps in IT investment planning. In the
figure, you can see that most of the IT investment goes towards Sales, Customer Management,
and Payment, which include some highly strategic sub-capabilities such as Payment Execution.
You can also see strategically important capabilities with low IT investment levels, e.g. Customer
Billing, possibly because these are not IT-intensive but maybe also because of a misallocation
of budgets. Conversely, some capabilities receive substantial investment, e.g. Communication
Management, without being very strategic to the company.  

From Business Model to Capabilities  

You may be familiar with the Business Model Canvas, which is a great way to depict the business
model of an enterprise. Within this structure (see the figure below), there’s a box called “(Key)
Activities”. Rather than describing operational activities here, we would use this to list the key
capabilities needed for this business model. In the example below, we focus on a specific aspect
of the business model of our example company, concerning a customer-centric banking appli-
cation. 

Source: Horizzon 
Figure 9 Business Model Canvas  

22
 Relating Capabilities to ‘Strategy’ and ‘Business Model’

Reusing the same capabilities in the Business Model Canvas is a great example of how you can
connect different best practices for business analysis and architecture. You can even highlight
in the canvas the strategic and investment analysis we have described earlier. That would
show, for instance, that the strategic importance and investment level of Payment Execution
match its role in this business model.  

From Capabilities to Resources 

For the “Asset Management” capability mentioned above, an insurance company needs
personnel with the right skills, information on the financial markets. Perhaps even high-speed
transactional systems, and much more. Of course, you want to define a capability in an imple-
mentation-neutral manner, but without such an implementation you don’t have that capability.  

Moreover, resources often have a strategic value by themselves: for example, in a copper
mining company, the copper mine will be paramount in your strategy. You won’t think about your
company in terms of an abstract “Ore Extraction” capability but in terms of how you extract
ore from this specific mine with all its geological and other peculiarities. At the same time, you
don’t want to lose yourself in all the details of an operating model, when you’re working on
your strategies. Therefore, the ArchiMate language provides the concept ‘Resource’ (defined
as any asset that is owned or controlled by an individual or organization), which allows you to
do strategy planning at a higher level.  

Relating Capabilities and Value Streams 

Where capabilities represent the enterprise ‘at rest’, i.e., its abilities and potential, value streams
describe the enterprise ‘in motion’ (e.g. sequences of activities to create value for customers,
stakeholders, and others). These two concepts are like potential and kinetic energy in physics,
they’re two sides of the same coin. To describe their relationship, cross-mapping can be done
between capabilities and value streams. This shows how capabilities support the stages in a
value stream.  

This can be done at a very high level, where you capture the entire value chain of the enter-
prise. The stages in this value chain can be cross-mapped to the top-level capabilities in the
Capability Map. At a more detailed level,  a value stream captures how a specific result of value
is created for a specific stakeholder or group (e.g. a customer segment). The stages of such a
more detailed value stream are in turn supported by capabilities from a more detailed level of
your Capability Map. 

One way to represent this is in the form of a Business Outcome Journey Map. This is similar to a
Customer Journey Map but at a higher level. Rather than describing the specific steps that an
individual customer takes (with all the possible exceptions and variants), it shows the stages in
a value stream, the goals and value propositions of each stage, and the capabilities supporting
it. This can link back to your investment planning or Business Model Canvas, where you also
find these value propositions, for instance. An ArchiMate Model provides great value in the
backend, as it captures the concepts and relationships of both the Business Model Canvas and

23
 Relating Capabilities to ‘Strategy’ and ‘Business Model’

the Capability Map, tying everything together.  

Source: Horizzon 
Figure 10 Business outcome journey map 

24
 Linking Capabilities to the Operating Model: Business Functions and Organizational Structure

6. Linking Capabilities to the Operating Model:

Business Functions and Organizational Structure 
Let’s start by clearing up an important misunderstanding: a Capability Map is not a functional
decomposition of the enterprise!  

Many Capability Maps are full of business functions, or even worse, resemble organizational
charts. Business functions describe the day-to-day operations of the enterprise. Now anything
you actually do is obviously something you are able to do. So, for each business function, you
could define a 1-to-1 related capability. But this isn’t a great way to use the concept, since there
are many things your enterprise could do that it doesn’t do on a day-to-day basis: it has capa-
bilities that go beyond mere business functions. 

As an example, we can use the military which uses the expression: ‘Boots on the ground’ where
they describe their potential to have troops deployed anywhere in the world in 24 hours.
However, they don’t have a business function: ‘Boots on the ground’, let alone a ‘Boots on the
ground department’. But ‘Boots on the ground’ is a capability.  

Business functions express the concrete activities performed to deliver capabilities. In an

ArchiMate model, you express this using a realization relationship: one or more business
functions realize a capability. Next to that, you can of course define which departments
are responsible for performing these functions and which information and technology
uses it. That then provides you with a line of sight between a capability and its realization.   
 

Source: Horizzon 
Figure 11 Capability realization by business functions (and actors).

The capabilities: Money Management, Asset Management and Policy and Claim Management
are realized by three business functions, with the Investment Management function involved in
two capabilities. These functions are in turn performed by two responsible organizational units.
This is the basis for the operating model of your enterprise. A similar mapping can be made
between value streams, which describe the high-level value creation steps in your enterprise,
and the business processes that realize them.

25
 Linking Capabilities to the Operating Model: Business Functions and Organizational Structure

Using capabilities and business functions together 

The capability concept supports the collaboration of people from different disciplines. You
should consider that people have different ways of thinking, depending on their background.
We like to share some observations from our practical experiences. 

Managers often think in terms of groups of people and the work they do (and e.g., span of
control, ownership and responsibility). They therefore tend to interpret such a map as an or-
ganizational or functional structure. Similarly, people with an engineering background (and es-
pecially in IT) think in terms of functional decomposition. Both management and engineering
have a design perspective where ‘this bit’ of the enterprise or system (e.g., a department or
component) needs to do ‘that piece of work’ (e.g., perform a function or execute a business
process). The potentiality and dispositional nature of capabilities isn’t something either of these
worlds is natively familiar with. The military are more advanced in their capability thinking.
However, we have observed a tendency for them to mix up capabilities and resources, e.g.
calling an aircraft carrier a capability (perhaps betraying the military’s obsession with
hardware), rather than a resource (or collection of resources) that supports a capability like
‘Power Projection’.  

Nevertheless, even if a capability map is a bit too ‘functional’ it can still be useful and offer a
way to let people adapt to and adopt the concept. Just make sure it does not depend on any
specific technology implementations or organization structures and stays focused on the ‘what’
rather than the ‘how’. 

Our advice is to go back to the roots of the capability concept and use it as you’ve original-
ly intended: Describe what the enterprise does or is able to do, in other words, its potential.
That’s what gives it strategic relevance. Business functions performed by the various parts of
the organization can contribute to the realization of these capabilities. Don’t create both a
detailed capability map and an equally detailed business function map that covers the same
ground. Use them at their own abstraction levels within a joined-up structure, e.g. using capa-
bilities at the topmost two or three levels to express the high-level abilities of the enterprise.  

Use business functions for more detailed levels, closer to implementation, to express the
concrete activities you perform to deliver these higher-level abilities. In this way, different parts
of the organization may also have their own distinct business function structure to deliver the
same capabilities. If you then relate the various other elements of your operating model such as
the people (e.g., departments, teams, roles), processes, technology and information to these
business functions, you create traceability between capabilities and their realization(s). 

  

26
 Mapping the BIZBOK® Metamodel to the ArchiMate® Language

7. Mapping the BIZBOK® Metamodel to the ArchiMate®

Language 
Since the foundation of the Business Architecture Guild a little over a decade ago, its Business
Architecture Body of Knowledge (BIZBOK®), as expressed in the BIZBOK® Guide, has become
a popular set of guidelines and techniques for practicing business architects. More recently, it
has also defined its own metamodel, which you can read about in this whitepaper (published
August 2020). This metamodel provides you with a core set of concepts for expressing business
architecture in the way that BIZBOK® defines it. 

The ArchiMate® modeling language for enterprise architecture, first published in 2004 and
established as an Open Group standard in 2009, also covers Business Architecture but has a
wider scope. Moreover, it offers a notation as well as a metamodel, so you can write down your
architecture models in a standardized way that is understood by your fellow architects.  

Now wouldn’t it be nice if you could express BIZBOK®-based Business Architecture in ArchiMate?
This would allow business architects to benefit from the well-established tool support for the
language in expressing their business architecture artifacts. Moreover, it would let business ar-
chitects easily connect these architectures to a broader and deeper scope of enterprise archi-
tecture.  

The ArchiMate language was explicitly designed with such relations to other languages and
metamodels in mind. It therefore provides a bridge to languages like UML and BPMN, with
equivalent concepts. For instance, the ArchiMate ‘Application Component’ concept equates
with the UML ‘Component’ concept.  

Conversely, if we don’t link up business architecture with the rest of enterprise architecture,
it runs the risk of being a stand-alone discipline that can’t truly show value. Already, we see
business architects sometimes struggle because ‘the business’ fails to understand their abstract
concepts like ‘capability’. By showing how those concepts are underpinned by more concrete
elements like those mentioned above, they become a lot more tangible and understandable
for non-architects. 

27
 Mapping the BIZBOK® Metamodel to the ArchiMate® Language

Concept Mapping  

The mapping between two conceptual universes is seldom 1:1. Some of the BIZBOK® concepts
could be expressed with different ArchiMate elements. For example, the ‘Stakeholder’ concept
in BIZBOK® can be used to express someone with an interest or concern, just like in ArchiMate,
but it can also have an operational role, e.g. triggering a value stream. In ArchiMate, such
you can better express such operational roles using the ‘Business Role’ concept. Although there
are a few different mapping options, the mapping above works well in practice and is a good
starting point for your own business architecture modeling efforts.   

Source: Horizzon 
Figure 12 BIZBOK - ArchiMate strategic-level mapping: The background shows the BIZBOK® metamodel
overlaid with applicable ArchiMate concepts and relationships. From the ArchiMate language, we use
Motivation, Strategy, Business, and Implementation & Migration elements 

Hierarchical Levels 
In this mapping, you may notice that ArchiMate uses a single concept at different levels of
hierarchy. For instance, the BIZBOK® ‘Organization’ and ‘Business Unit’ concepts are both
expressed with an ArchiMate ‘Business Actor’ in the second mapping, one being composed
of the other. As you can imagine, an organization structure may have e.g. Departments with
Business Units, Teams within Departments, etc.  

28
 Mapping the BIZBOK® Metamodel to the ArchiMate® Language

The same pattern is shown by BIZBOK’s ‘Value Proposition’ and ‘Value Item’, both mapped to
ArchiMate’s ‘Value’ concept, and by ‘Value Stream’ and ‘Value Stream Stage’, both expressed
as ‘Value Stream’ in ArchiMate. Moreover, unlike the more strictly defined BIZBOK® concept,
you can even use an ArchiMate ‘Value Stream’ for modeling an entire value chain, thus linking
your business architecture to your business model in the economic sense.  

Such hierarchical levels occur in many other areas too, e.g. business process decomposition or
application structure. For this reason, ArchiMate does not have any built-in, fixed hierarchies.
Rather, it allows arbitrary composition and aggregation levels between elements of the same
type. That flexibility provides you with yet another way to drill down from high-level, strategic
views of the enterprise into progressively more detailed operational models. But if you want a
tighter mapping of the BIZBOK® concepts to ArchiMate, you can use the language customiza-
tion mechanisms outlined in Chap. 15 of the ArchiMate specification to create custom special-
izations for these different hierarchical levels. These could even have a custom notation. 

From Business Architecture to Operating Model 

From the concepts in this mapping you can drill down into the operating model of your en-
terprise. More concrete concepts for that operational level can be linked with a Realization
relationship to their more abstract counterparts in a business architecture model. For instance,
ArchiMate Business Processes can realize a Value Stream stage, and Business Functions can
realize a Capability. From this operating model we can drill down deeper towards the imple-
mentation, for instance to express that a Business Process is automated, modeling its realiza-
tion by an Application Process performed by some Application Component.  

That way, you can drill down from high-level business drivers and motivation, via your business
architecture, into the underlying operating model as expressed in elements like business
services and processes, applications, IT infrastructure and physical technology. Such a line of
sight provides essential business insights, helping you set investment priorities, analyze opera-
tional risks, assess regulatory compliance, foster innovation, and much more.  

As you can see from the above, the ArchiMate language is an excellent way to express your
BIZBOK® business architectures and relate them to other domains of architecture and design.
Of course, excellent tool support for modeling, analysis and collaboration is vital. That way,
business architecture truly becomes an actionable discipline! 

  

29
 An approach: How to Assess Business Capabilities  

8. How to Assess Business Capabilities  

Capability-Based Planning activities are structured in a cycle: Map, assess, plan, and control.
It shows us where to begin and the next steps to gradually increase the impact on the organi-
zation.  

In the ‘Map’ phase, we define and create the Capability Map, which we can use to analyze the
organization, assessing the strategic and architectural alignment of the capability framework.
In this chapter, we explore the ‘Assess’ phase, where Capabilities are measured based on their
contribution to our business strategy and identifying opportunities to improve maturity. This is
visualized on the Capability Map, e.g. using heatmapping techniques. 

Figure 13 Capability-Based Planning Approach 

Our approach to assessing Business Capabilities includes defining three dimensions. To effec-
tively assess Capabilities and execute Capability-Based Planning, we need to combine these
three dimensions because there are clear relationships and dependence between them. These
three dimensions are: 

A. Strategic Importance 
Business Capabilities link to the strategic objectives of an enterprise. From this, we can derive
their relative strategic importance to the organization. Executives must prioritize and focus
investment on the right Capabilities and for managers to understand which Capabilities are
critical to success. 

The key question answered here is: “Which Capabilities are required to successfully deliver a
strategy?” 

For this dimension, we’ve identified three key metrics relevant for an assessment of the
Strategic Importance of a Business Capability: 

30
 An approach: How to Assess Business Capabilities  

● Strategy Execution: Is the Capability required in the context of a strategic goal? 

● Business/ Operating Model: Does the Capability provide critical support or

resource for a key value proposition? 

● Future Opportunity: Does the Capability provide critical support or resources for
future enhanced or new value propositions? 

Figure 14 Strategic Importance Dimensions 

B. Maturity 
In a Capability Map, we define the set of Capabilities that an organization requires to be suc-
cessful against its formulated strategy. However, just having the Capability in place isn’t enough
because we also need to be very good at it, especially those Capabilities with high strategic im-
portance. For managers, an assessment of Capabilities based on maturity identifies where im-
provement and development are required. It shows both change leaders and change experts
where the key problems lie.  

Figure 15 Maturity dimensions 

31
 An approach: How to Assess Business Capabilities  

The key question answered here is: “Which Capabilities are currently performing below
expected or required performance levels?”. These are the Capabilities that may require
investing in various improvements. You would typically prioritize those dimensions where the
highest difference between current and target levels is. 

The maturity of a Business Capability is determined based on its maturity in the common di-
mensions of people, processes, technology, and information. 

C. Adaptability  
Capability-based Planning is not a one-off exercise: an organization needs to align strategic
goals with the required Capability, and continuously retain this alignment as strategic goals may
shift. As we have argued in the past, adaptability is essential for the modern enterprise. Any
organization needs the flexibility to respond to changes in the environment and the ecosystem.
An assessment of adaptability gives executives insights into how easy it is to change Capabili-
ties, and for managers on which Capabilities need to be more flexible or resilient. 

The key question answered here is: “Which Capabilities are problematic to improve?”  

In our vision, there are three key metrics important to determine the level of adaptability of a
Business Capability: 

● Adaptability to the environment: What’s the role of the Capability for the
response to external (e.g. law or regulation) and internal (e.g. business interrup-
tion) dynamics? 

● Adaptability to the customer: What’s the role of the Capability for the response
to changing customer needs? 

● Capacity: Can the Capability respond to changing demand? 

Figure 16 Adaptability dimensions 

32
 How to Measure Capability Dimensions

9. How to Measure Capability Dimensions 

The most common capability assessment models use a five-level scale, probably under the
influence of the CMMI maturity model for software development: 

1. Performed 

2. Managed 

3. Defined 

4. Quantitatively Managed 

5. Optimizing 

Each level has a definition, e.g. level 4 means that your capabilities or processes are measured
with quantitative (e.g. statistical) techniques, with quality and performance objectives used as
criteria in managing them. A detailed assessment can evaluate various aspects of each capa-
bility, and the results can be analyzed quantitatively. This works if you want to assess a relatively
small number of capabilities on domain-specific aspects. For instance, in assessing software
development capabilities or processes, you can look at software defects, rework, user satisfac-
tion, and many other metrics as input.  

Doing a broad, possibly enterprise-wide, capability assessment, such as a detailed analysis,

often takes too much effort. Alternatively, you could put experts in a room and ask them to
rank each capability on a 1-5 scale. However, this would rely too much on personal opinion and
doesn’t give these experts a foundation for their evaluation.  

Our approach aims to take the middle ground. We let such a group of experts score their
agreement with a number of statements about each capability on a 5-point Likert scale from
‘strongly disagree’ to ‘strongly agree’. By limiting the number of statements per aspect and
dimension, we keep the required effort to a manageable level. As an example, the Process
dimension of Capability Maturity includes statements such as:  

● “Each process has a clear owner who is accountable for performance.”  

● “Processes are monitored with success measures that are regularly reported.”  

● “Processes for the capability are fully optimized and efficient.” 

For each statement, the average score of the experts is entered into the assessment model.
Together, the resulting scores for a set of statements are averaged, resulting in a value for that
dimension. The values for each dimension can, in turn, be averaged to calculate the overall
maturity of the capability.  

33
 How to Measure Capability Dimensions

Capability Assessment in Bizzdesign Horizzon 

In Bizzdesign Horizzon, you can use fields in data blocks to enter these assessment scores. With
calculated fields, you can define an expression to compute the average across the fields for
each statement and another one to calculate the overall average maturity level. You can also
make this a weighted average if some dimension is more important than another.  

The resulting data can be shown in Bizzdesign Horizzon in several ways, such as a heat map of
your Capability Map, helping you pinpoint issues such as below-par capabilities that require
management attention and investment priority.  

Strategic Capabilities - Direction Setting

Product Program & Strategic

Strategy Budget Planning Management

Core Capabilities - Customer Facing

Marketing Sales Customer Management Account Management Payments Operational Services Servicing

Advertising Customer Sales Product Account Financial Message Channel Activity Customer Case
Offer Agreement Reconciliation Analysis Analysis Management

Brand Lead Customer Fraud Correspondent Customer Billing Customer Order

Management Management Agreement Detection Bank Management

Campaign Product Customer Beha- Position Financial Disbursement Customer Issue

Management Matching vioral Insights Management Gateway Analysis

Prospect Sales Planning Customer Relation- Transaction Payment Open Item

Management ship Management Management Execution Management

Underwriting Customer Credit Collateral Central Cash Issued Device

Rating Administration Handling Tracking

Customer Service Counterparty Risk Reward Points Awards

Management Management & Redemption

Customer Event
History

Customer Access
Management

Enabling Capabilities

Administrative Business Communication Event Financial Human ICT Information & Language Legal & Procurement Security
Management Program Mng Management Management Management Resource Mng Management Knowledge Mng Management Ethics Management Management

Source: Horizzon 

Figure 18 A capability heat map with IT investment levels (color) vs. strategic importance (label) 

Further Analysis 
Analyzing this data helps you pinpoint the pain points of where you are and where you want
to be. Typically, high strategic importance and low maturity capabilities must be investigated
first. You want to analyze (in-depth) those aspects where the difference between current and
desired maturity is the largest.  

At the same time, you may find that such a capability is not very adaptable. You may first need
to invest in improving this adaptability otherwise other changes may be too difficult, time-con-
suming, and costly. This is the typical worst-case scenario: a capability that’s very rigid because
it heavily depends on legacy software that’s difficult to change. However, this capability is core

34
 How to Measure Capability Dimensions

to the operation of your enterprise, and needs urgent uplifting to keep up with competitors and
customer demands. 

This data can be used in many ways to support business decision-making. For instance, in Ca-
pability-Based Planning you want to plan capability improvements in the most effective way,
investing where and when it counts. Change initiatives could be scored by the capability im-
provements they provide and the concrete contribution of those improvements to strategic
goals and other KPIs. Based on this, they could be compared and ranked. One way of doing
this is using the Cost of Delay of each initiative, which in turn is input for Weighted Shortest Job
First prioritization of change initiatives. 

Assessing and improving capabilities can become more complicated in large, geographi-
cally dispersed enterprises with multiple instances (implementations) of the same capability.
Moreover, to describe the evolution of your capabilities (or rather these instances), you would
typically model capability increments.  

35
 How to Model Capabilities Over Time and Describe Different Instances  

10. How to Model Capabilities Over Time and Describe

Different Instances  
In larger organizations, the same business capability may be implemented in different ways
across the enterprise in business units or regional organizations. For example, in a multi-nation-
al company, the same Human Resource Management capabilities may be realized in different
ways in accordance with local customs and regulations. Each of these specific versions can be
modeled as a specialization of the same generic capability. 

Figure 19 Regional capability instances specialize in the same generic capability 

Each of these instances, in turn, is realized by various other elements (people, process, infor-
mation, technology) from each region. Perhaps some of those are again standardized across
the entire organization, say an HR application used globally. Others are local, like the individual
HR departments of each business unit.  

These instances can be assessed separately. From these assessments, you can calculate an
average maturity, but perhaps more importantly, you can analyze which instances perform best
and share best practices with other instances. You can increase global maturity by fostering an
internal learning process. 

Modeling Capability Increments and Releases 

The evolution of capabilities is often expressed in so-called ‘increments .’Each increment rep-
resents a stable state of a capability that exists for a certain time. These increments can also
be considered specializations of a generic capability. In this case, they don’t represent local
differences like the capability instances discussed above, but differences that occur over time.
If you need to use both increments and instances in conjunction, an instance will typically have
its increments, not the other way around.  

36
 How to Model Capabilities Over Time and Describe Different Instances  

Source: Horizzon 
Figure 20 Capability increments and projects realizing these 

The figure above shows a simple roadmap where the Customer Management capability is
improved in stages by three ArchiMate work packages that model the change activities: to
homogenize the information and data on customers across business units, to improve global
access to that data, and to harmonize billing processes across different business units. The end
date of each of these is when the corresponding capability increment is fully realized, so that’s
the start date of the increment. You could mark this as a milestone on your roadmap. 

If we look at each of these changes in more detail, we would see that those change activi-
ties impact specific elements that contribute to the realization of the increment. For instance,
‘Harmonize billing process’ mainly impacts the project dimension of ‘Customer Management
increment 3’ by improving the billing process, which underpins this capability dimension.  

Source: Horizzon 
Figure 21 Horizzon High-level and detailed roadmap stages 

37
 How to Model Capabilities Over Time and Describe Different Instances  

We can organize capability increments in releases resulting from a series of sprints (see the
above figure). This view shows the release planning and, for Release 1, also the (simplified) sprint
planning. This way, you can analyze what happens to the availability of your solution if an agile
team decides to move a certain feature to a later sprint, for instance. In the underlying model
(but not shown in the figure), all the elements created or changed in the two sprints contrib-
ute to the first capability increment. Of course, this is a highly simplified figure for explanatory
purposes. The real roadmap is much more extensive and includes improvements to several ca-
pabilities.  

The further you look ahead, the less tangible and specific your roadmap will be. Hence, the
ArchiMate concepts for the near-term future are typically the concrete and detailed business,
application, and technology layer elements. For the medium-term future, you might use the
more abstract, high-level capability and resource concepts, and you might express the longer
term using only goals and outcomes.  

ArchiMate’s graphical notation for plateaus is mainly useful for mapping such an evolution
rather than depicting the architecture itself since many elements in your architecture are part
of several plateaus. For example, anything in the baseline that survives through the transitions
above is part of all plateaus on the roadmap. That would clutter a figure like the above. For that
reason, we often use plateaus in an architecture model but not necessarily in a view.  

Often, we enter the aggregation relationships between plateaus and their content in a cross-ref-
erence table and use this in views and analyses. Figure 4 shows an example of such an analysis,
highlighting elements based on the plateaus they’re part of, based on the same scenario shown
above. Such a heatmap quickly shows the impact of changes to your architecture. 

Source: Horizzon 
Figure 22 Highlighting plateaus in the architecture 

38
 How to Model Capabilities Over Time and Describe Different Instances  

Next to the coarse-grained capability-level roadmap outlined above, you can model that some
elements in the architecture are improved in more specific ways. Using the same technique as
for capability increments, you could, for instance, model the generic application component
‘General CRM System’ with specializations for versions like ‘General CRM System 3.2’, ‘General
CRM System 3.3’ and ‘General CRM System 4.0’. Each of these can, in turn, be related to
a plateau that starts on the release or deployment date of this version and ends when it is
replaced by the next.  

The same modeling technique can also model deployed instances of e.g. applications,. Be
careful with modeling too much detail and tracking every individual release of an application or
instance of a server type as a separate object in your enterprise architecture. This is probably
more detail than you need or want to maintain. 

Next to the architectural perspective with plateaus, we often see more precise dates being
used. To avoid having many plateau objects tied to specific dates and periods, you can enrich
your model with attributes. In this way, you can combine detailed release dates with high-level
architecture plateau planning. 

  

39
 Directing Strategic Change With Capability-based Planning

11. Directing Strategic Change With Capability-based

Planning 
A topic attracting increasing attention from architects and executives alike is How to use Capa-
bilities to inform strategic planning. You can do this through planning process to deliver Capa-
bility-based change.  

Figure 23 Capability-based planning process 

By driving the future state design architects are involved and inform all of the other five stages
(in the above image).  Sometimes, it may even be that the above process requires iterations.
For example, closing the gaps may require too expensive an investment requiring a revision
of which gaps are in scope. Even the final stage of creating a roadmap may reveal that the
timeline is unacceptable.  

The planning process for capability-based change 

 

Figure 24 Planning process for Capability-based change 

40
 Directing Strategic Change With Capability-based Planning

Gap analysis 
Executing your organization’s strategy requires a wide set of business-as-usual processes to be
working sufficiently to deliver the strategic goals. Where those processes are insufficient, there
is a gap – after i.e. something needs to be done to raise performance.  

Business capabilities are a great language for describing gaps since they’re stable over time,
have definitions, and are enterprise-wide. Most importantly, they can map upwards to strategy
and map downwards to people, process, technology and data and their maturity can be
evaluated by assessing these dimensions.  

Figure 25 Capability gaps identified 

Gap prioritization 
Having obtained a list of underperforming capabilities, the challenge is to decide which ca-
pabilities most need improvement. A scientific/objective approach is needed to quantify each
capability so they can be ranked. We recommend the following: 

● You need to consider both the current and the future state, with the future state
being derived from your enterprise’s goals. 

● Strategic Importance and Maturity are common dimensions stakeholders use to

decide which capabilities to invest in. 

● To put figures against a capability, measure it in terms of its people, process,

technology and data components. 

41
 Directing Strategic Change With Capability-based Planning

Figure 26 Capability maturity and strategic importance: A capability landscape that has been heatmapped
against as-is maturity, with a label showing its strategic importance 

Investment allocation 
With a set of capabilities quantified against your chosen dimensions, you now need to decide
where to allocate budget and people. Break this complicated decision into two stages: 

1. Filter your capabilities to consider only the ones worth investing in – which you can
do by only considering ‘strategically important’ capabilities that have a maturity
below a certain threshold. However, don’t ignore that you’ll need enabling ca-
pabilities that aren’t strategic but are nonetheless critical for supporting your
strategic capabilities. 

2. Generate a metric for ranking the capabilities. The interactive dashboard below
shows how you can create a score based on multiplying individual scores for the
complexity, cost and impact of the capability improvement.  

Figure 27  Capability dashboard

42
 Directing Strategic Change With Capability-based Planning

Future state modeling 

The result of the Investment Allocation step is a list of the capabilities which receive investment.
The aim is to determine what changes will be made to improve these capabilities. This means
that two aspects need to be considered: 

● Mapping the capabilities to their people, process, technology and data compo-
nents to show the tangible impacts. 

● Creating different scenarios of the changes; e.g. one option could see people
changing work practices significantly but keeping the technology the same.  

Decision-makers can then review these to-be options and decide which is best for the orga-
nization. The significant advantage of using capabilities is that changes to related parts of the
organization can be considered together and aren’t viewed in isolation.  

Figure 28 A Target Operating Model where a capability is broken down into process, applications and data. 

In this case, the people dimension is left out because it’s quite simple: a single team performs all
the payment processes. In other cases, this may be more complicated involving different roles
and the requisite skills. 

Initiative formulation 
Once the future state models have been decided, it’s easy to create a work package to
implement each to-be model. However, the risk is that a complicated network of dependen-
cies is created and that a large number of overlapping work packages compete for the same
resources (e.g. subject matter experts, IT operations staff). This increases the complexity and
risk of your deliveries and raises costs and time-to-market.  

43
 Directing Strategic Change With Capability-based Planning

To mitigate this, you can re-structure your work packages to align with one or more business
capabilities – allowing you to focus on changing only specific parts of the organization and
minimizing the impacts on key resources. It also doesn’t matter if you’re using agile or waterfall
methodologies because alignment to business capabilities improves the efficiency and effec-
tiveness of your transformation.  

Roadmap generation 
The initiatives provide the means for delivering the capability improvements, and these two
dimensions can be laid out against time on a roadmap. The roadmap below shows how the ca-
pabilities identified in the Gap Analysis and selected in Investment Allocation are then improved
over time by work packages implementing capability increments.  

Figure 29 Capability-Based planning timeline 

Using capabilities to do planning may seem daunting at first, but it gives you a common language
across your organization – a language that remains the same year after year. You can use this
language with all your stakeholders, from executives to implementers, and describe the end-
to-end process from strategy to execution. Moreover, this analysis is already happening to
some degree in every enterprise, and so it’s a case of introducing capabilities as a means to
simplify the process and make it more effective.  

  

44
 Measuring the Effectiveness of Change Investments using Capability-based Planning

12. Measuring the Effectiveness of Change Investments

using Capability-based Planning 
To measure the effectiveness of change investments, you need a way to control the processes
(Map, Assess, Plan, Control) by continuously monitoring the effectiveness of the changes
proposed by a Future State Design. For this, we need to know how this Future State Design
contributes to the required improvements of key Business Capabilities, which have been identi-
fied as priorities for investment in an earlier stage of the process. 

Figure 30 Capability-Based Planning Process 

 ‘SMART-ify’ capability gaps using a driver tree approach 

To determine if we realize the required performance, we need a more specific definition of the
capability gap and make gaps measurable in terms of their contribution to capability improve-
ment. In other words, we need to ‘SMART-ify’ capability gaps.  

The first step is combining the bottom-up approach with a top-down approach using a ‘driver
tree’ view. We break down high-level strategic drivers into more specific business challenges in
the driver tree view. These business challenges are modeled as (ArchiMate) assessments. We
can do this in one or more steps to get to a level where we can define the challenges as concrete
business problems that need to be solved. These business problems are a more specific version
of a capability gap, and in turn, link into business capabilities. Closing these capability gaps will
improve the performance of the capability.  

This approach gives us a direct line of sight between strategic goals and drivers and the ca-
pability gaps. We can use this to provide additional input for gap prioritization since we can
now analyze the relative strategic importance of closing a capability gap. This can be further
enhanced by putting ‘weights’ on the leaves of the driver tree.  

45
 Measuring the Effectiveness of Change Investments using Capability-based Planning

Figure 31 (Source) Driver tree view for strategic driver: Market Share 

Linking KPIs to strategic drivers and goals 

With capability gaps linked to strategic drivers and goals, as well as to business capabilities,
we can look at the realization of improvements not only in terms of the capability aspects (e.g.
people, process, technology, etc. but also in terms of their contributions to strategic goals.  

To measure and monitor these contributions, we need to define Key Performance Indicators
(KPIs) and link them to our strategic goals and drivers. C-level executives typically determine
these KPIs. Using Bizzdesign Horizzon, architects can add these KPIs to the model repository
and link them to strategic goals and drivers modeled in the same repository. In the example
below, we see how the driver, Market Share, is supported by KPIs including ‘Revenue from
Digital Services (%)’ modeled as a metric object.  

Figure 32 Strategic KPIs for ‘Market Share’ 

Enhanced ‘Initiative Formulation’ 

An additional step is to allow a model-driven approach for monitoring the effectiveness of
change initiatives represented by the work packages. In the real world, the components
supporting a business capability will undergo the actual change. These components include
business processes, application components or IT platforms, and are represented in the Target
Operating Model, also shown in the article mentioned before.  

46
 Measuring the Effectiveness of Change Investments using Capability-based Planning

In this step, specific results of initiatives to close capability gaps are identified and linked to
components in the scope of the Target Operating Model.  

  

Figure 33 Initiatives (and desired end states) to fill capability gaps – how Initiatives (work packages) and their
results (implementation events) are linked to capability gaps 

In addition to the capability roadmaps, we can now generate roadmaps at the component level
using Bizzdesign Horizzon. This visualizes how, for example, a business process will be improved
over time. In the figure below, we see an example of a process roadmap for improving the
Payment Execution business process, which is in the scope of the Target Operating Model of
the Payment Execution business capability. 

Figure 34 Process Roadmap for ‘Execute Payment’ 

 Baseline, Target, Expected KPI Values 

The last step of the Control phase in the Capability-Based Planning process is to quantify and
analyze the improvement. We do that by setting a target (leading) value for the Strategic KPIs
we captured earlier in the process. C-level executives typically determine these targets. Next,
architects can work with business teams to identify a baseline (lagging) value for the same
strategic KPIs.  

The improvements represented by the implementation events on the Process Roadmap are
responsible for getting from our baseline to our target in terms of KPI scores. For example,
the percentage of Process digitization will go considerably up once the new payment system
is operational. At the same time, the percentage of revenue from digital services will improve
as well.  

47
 Measuring the Effectiveness of Change Investments using Capability-based Planning

Using this approach, architects work with several stakeholders, including business managers,
process experts, project management officers and the likes to estimate the contribution of
each improvement (implementation event) against the relevant KPIs. The result of this is shown
in the table below.  

Figure 35 KPI table for business process: ‘Execute Payment 

The table shows the relevant KPIs (rows in the table), the baseline value and subsequent im-
provements, and their expected contribution to KPI improvement. If we add all contributions
within this scope’s time frame, we get to an expected KPI value (see the After column).  

This answers whether currently planned improvements on the roadmap will bring us the KPI
performance we envision.  

Figure 36 Roadmap for process Payment Execution, with a KPI progression charts 

The same data can also be presented as a line chart where the progression of KPI improvement
is visualized in alignment with the Process Roadmap. The blue line in the chart represents the

48
 Measuring the Effectiveness of Change Investments using Capability-based Planning

Expected KPI value, and we see an increase at each point where we expect to deliver an im-
provement (implementation event). The green line represents the envisioned target KPI value.  

In our example based on the ‘Payment Execution’ process, we clearly see both in the table view,
and the chart views that the current Roadmap overachieves for the Process digitization (%) 
KPI, but we fall slightly short for Revenue from digital services (%). These results may be used to
reconsider priorities in the next iteration of the Capability-Based Planning process.  

Conclusion 
In this chapter, we proposed an enhancement to the Capability-based Planning process to
support its Control phase and bring a more quantitative view of the Strategic Roadmap(s). By
doing this, architects can prove the effectiveness of a Future State Design.  

This also provides a very important input into managing the work packages that should
implement the Future State Design. In the real world, the management of these work packages
is covered by Project Portfolio Management (PPM) processes. Prioritizing and balancing a
portfolio of projects becomes much better informed using the input from the Capability-Based
Planning process. 

The Control phase is the last step in this process. But of course, this isn’t the end since, in the
meantime, many things may have changed inside or outside the organization. This requires
us to adapt the Strategic Roadmap(s) by going into another iteration of the Capability-Based
Planning process, which aligns well with the yearly strategic planning cycle we see in many
organizations. 

  

49
 Capability Governance: The ‘Who’ Dimension of Capability-based Planning

13. Capability Governance:

The ‘Who’ Dimension of Capability-based Planning  
This chapter discusses the who dimension: the roles and responsibilities around capabilities and
their use. We’ll look at the approach advocated by the BIZBOK® Guide from the Business Ar-
chitecture Guild. You could say this represents an ‘idealist’ perspective.  

Figure 37 An example of a roadmap showing the evolution of Capability-based Planning, starting from the
OCIO (Office of the CIO) 

BIZBOK® Roles in Capability Governance 

The BIZBOK® Guide distinguishes the following roles in Capability-based Planning: 

● Business sponsor: Since business architecture is owned by the business, sponsor-

ship must be established within the business. Often, a CIO can assist with building
sponsorship support within steering committees or transformation teams. 

● Team leader: Business architecture teams should be led by business leaders with
roots and reporting responsibility in the business. 

● Subject matter expert: Business professionals with knowledge of all major

aspects of the business, such as major customer-facing capabilities and value
streams. They’re expected to participate in drafting level 1 and 2 capabilities in
meetings that cross their subject area. They may also facilitate workshops to
establish business ownership accountability and provide expertise. 

● Business architect: Their role is to look beyond traditional business concepts

50
 Capability Governance: The ‘Who’ Dimension of Capability-based Planning

and create and socialize business architecture. In larger organizations, multiple

subtypes of this business architect role often exist, typically aligned with business
subject area expertise. 

● Architecture mapping expert: An expert in assembling and organizing capability

analysis results into a formal knowledge base and developing the formal and ad
hoc blueprints required. This role also requires tool expertise to meet blueprint
mapping and knowledge base governance. 

● Mentor: Someone well-versed in Capability Mapping and Business Architecture

in general, who provides behind-the-scenes guidance for team building, gover-
nance, mapping, blueprint creation and integration into strategies, projects and
related architectures. 

Note that the same individual can sometimes play multiple roles. For instance, a senior business
architect may also be a mentor or team leader. Typically, these individuals form a virtual team
and aren’t hierarchically subordinate to any single senior manager or executive.  

Practical considerations 
As the BIZBOK® Guide rightly states: ‘Business architecture governance ‘must be based on the
premise of business ownership, business sponsorship, and representation from essential business
areas’. In practice, however, this approach requires a high level of maturity from the enterprise
and its business architecture practice. Organizations that have just started on a business archi-
tecture journey may find it difficult to get the level of ownership and participation by business
sponsors, management, and experts that this approach advocates.  

Additionally, the conceptual way of thinking used in enterprise, business, and IT architecture
is often unfamiliar to business stakeholders. It takes time to convince business leaders of the
value of such an approach. The best way to overcome this is to: ‘show, don’t tell’. Build business
architecture artifacts that provide value to decision-makers, and the demand for business ar-
chitecture will grow.  

Often, this will start in IT before closely involving the business because that’s where this archi-
tectural way of thinking originates. Hence it is easier to work with IT stakeholders and build your
initial business architecture artifacts there, sharing them with business leaders and experts later. 

Moreover, and despite its name, rather than starting directly from ‘the business’ (which is
already an IT term for everything non-IT), IT leadership who recognize the value of a business
perspective on IT architecture to support their decision-making often initiate a business archi-
tecture practice. From this business-oriented IT architecture, an architecture perspective on
the business of the enterprise may evolve and as a result, a true business architecture discipline
may be initiated. 

51
 Capability Governance: The ‘Who’ Dimension of Capability-based Planning

For instance, a typical scenario is where a forward-looking CIO wants to base IT investment
decisions on the envisaged future capabilities of the enterprise rather than on classical budgeting
per department. To this end, a group of business architects is formed from the existing enter-
prise and IT architecture teams. This group is tasked with creating a Capability Map and other
artifacts to support a capability-based planning initiative for IT investments. 

The resulting Capability Map may still be quite IT-focused, reflecting subdivisions and func-
tionalities of the application landscape rather than true business capabilities. That may not be
all bad though: if the structure is sound enough to support IT decision-making with a business
focus, you have already taken a first step in the right direction. If you restrict your Capability
Map to two or three levels deep, you can limit the risk of creating a too IT-focused map because
you typically think in more general terms at these higher levels. It also makes it easier to maintain
and update the Capability Map; use documentation fields of your Enterprise Architecture tool if
you like to capture more details of what happens ‘inside’ these capabilities, rather than creating
sub-capabilities for everything. Progressively refactoring and refining the map to become a
true business capability map may be a more fruitful approach than trying to get it right the first
time, which is nearly impossible for an inexperienced team with limited business involvement.  

In any case, we advise that you take an iterative and incremental approach. Too often, we’ve
seen capability mapping initiatives that took many months or stalled before delivering any
meaningful value, simply because of the perceived need to be complete in both breadth and
depth.  

Instead, we would start with a broad but shallow level 1 map, from which we zoom in on specific
areas based on two criteria: 

● Business relevance: Are these capabilities strategically relevant or business

critical? Avoid spending too much time on commodity and supporting capabilities
just to be complete. 

● Cooperation between the right people: Can you involve the relevant leaders and
experts in the area of interest, and are they willing to spend time on this? 

  

52
 Bizzdesign’s Approach to Capability Governance Tailored to Customers’ Needs  

14. Capability Governance Tailored to Customers’ Needs  

Bizzdesign’s approach to Capability Governance is similar to BIZBOK’s but more pragmatic.
Most importantly, it takes into account that many business architecture initiatives start from
the IT organization as well as from a lower level of maturity. We often see that the core of a
capability mapping team comes from some architecture department or team that reports to
the CIO. They, in turn, consult with leaders and experts from the business areas concerned, but
these are often at some distance from the mapping effort itself.  

We distinguish between the following roles:  

● Sponsor: Whoever is investing in creating a Capability Map and needs insights

from it to improve decision-making. This might be a business leader, in practice,
it’s often the CIO, Chief Digital Officer, or someone similar. The sponsor in a sense
is the capability map owner (but not the owner of the capabilities on the map!) 

● Business capability representative: These are business leaders with roots and
reporting responsibility in the business. If the sponsor is located within IT (e.g.
the CIO), business leaders are not always as closely involved as the BIZBOK®
proposes, but they should at least be consulted and informed. We intentional-
ly avoid terms such as ‘capability owner’, ‘manager’ or ‘accountability’ because
that implies ‘being in control of something’. Since a capability model is indepen-
dent of solution realization and organization structures, there could be too many
relationships between capabilities and business leaders managing the orga-
nization. Hence, you can’t easily assign this kind of ownership to managers of
teams, departments, or business units, since one capability might involve (parts
of) many different departments. Moreover, when IT owns the overall Capability
Map, subsets of it are unlikely to be owned by business leaders. Nevertheless,
business leaders may identify with certain capabilities and therefore be suitable
capability representatives.  

● Subject matter expert: Someone who knows the day-to-day operations and
details of the business in the area the capability describes. This professional
is ideally from the business and an expert in a subject matter area. If this isn’t
feasible, e.g. because of resource constraints, it could also be someone in IT who
is in close contact with the business and has enough business expertise.  

● Business architect: Has a good understanding of the business and is in touch with
the SMEs. Ideally, business architects report to the business. However, when IT is
the owner of the Capability Map, this role often sits in the enterprise architecture
team, which may be part of the CIO/ Digitization/ Transformation Office.  

● Capability steward: As part of their role, business architects are the stewards

53
 Bizzdesign’s Approach to Capability Governance Tailored to Customers’ Needs  

of one or more (groups of) capabilities, responsible for a sound structure of

the capability model, no overlap, good naming, descriptions, and updated vi-
sualizations to support the sponsor’s decision making. These stewards facilitate
workshops or meetings to create and update the Capability Map, related visual-
izations and reports.  

● Business contact: Someone in the business domain of the relevant capability

area. Contact of the Subject Matter Expert (or Business Architect) to be consulted
to get insights and input for the business architecture. This role is typically the
second line of support for SMEs, especially when they are not located in the
business themselves. 

● Benefits manager: A role that originated in project portfolio management.

Someone who identifies, plans, measures, and tracks the benefits of business
architecture and the business capabilities themselves. This is key to growing the
maturity of your business capabilities and your business architecture practice.  

● Mentor: As in the BIZBOK, an experienced business architect can guide the team
and helps grow their business architecture approach.  

Figure 38 The first three roles are must-haves (Sponsor, Subject Matter Expert, Business Architect). The rest of
the roles accelerate the usage of a Business Capability Map 

Again, the same individual might play more than one role, as is already apparent from the Ca-
pability Steward role, which forms part of what a Business Architect does. Note that we don’t
distinguish separate roles for Team Leader and Architecture Mapping Expert. Business archi-
tects can often self-organize without needing a formal, hierarchical team leader.  

54
 Bizzdesign’s Approach to Capability Governance Tailored to Customers’ Needs  

Moreover, any Business Architect worth their salt should be well-versed in capability mapping
and other description techniques, so this doesn’t need to be a separate role. Nevertheless, in a
larger business architecture team, some members might focus more on e.g. stakeholder com-
munication and engagement, and others on managing the architecture knowledge base or
creating beautiful architecture artifacts. 

We also introduced two specific roles: the Capability Steward and the Benefits Manager.
The first is important because you can’t readily assign formal business ownership to capabil-
ities. You’ll need the right architectural expertise to develop a sound capability structure. The
second is key because we acknowledge that Capability-based Planning teams often start from
a low level of maturity and need to grow their capabilities. To this end, you’ll need to track and
measure what you’re doing as a Business Architecture /Capability-based Planning team and
apply this to the actual business capabilities themselves. How is your work as a team having an
impact and where can you improve your way of working and results? 

Pragmatic starting point 

As you’ve seen, our approach to Capability Governance intentionally deviates somewhat from
the BIZBOK® Guide and other frameworks that state that capabilities should be owned by ‘the
business’. Although we agree in principle, we have to be realistic. Our approach reflects what
we see in practice and provides a starting point to demonstrate the value of using Capability
Maps and Capability-based Planning for investment allocation of IT budgets. It explicitly states
that it starts with deviating from best practices but keeps in touch with relevant business roles.
That helps you avoid turning a business Capability Map into an IT Capability Map. 

Once you have established the value of capability thinking in the context of business-focused
IT investment planning, you can evolve this into ‘true’ business architecture, purely focused on
the architecture of ‘the business of the business rather than the architecture of the business as
IT interacts with it.  

  

55
 Guarantee Successful Implementation By Overcoming Major Obstacles

15. Overcoming Obstacles to Successful Implementation 

Below are some of the main challenges you may encounter with the implementation of Capa-
bility-based Planning and how you could overcome those: 

Understanding the concepts 

First and foremost, this notion of ‘capability’ is new to many organizations, but it looks suspi-
ciously like things people already know: departments, business processes, functions, etc. This
poses an inherent danger because without recognizing and valuing the change in perspective
capabilities offer, many people will say: “I don’t see the difference, let’s keep doing it the way
we did before.” Some may think, for example, that a Capability is just what some department
does. However, capabilities are defined independently from organizational structure and reor-
ganizing the organigram doesn’t change your capabilities.  

Moreover, if managers think they recognize a Capability as something done by the depart-
ment or business unit they’re responsible for, they tend to claim that Capability as ‘theirs’.
We’ve literally witnessed this when showing a Capability Map to management stakeholders,
who started pointing at it and staking their claims. But Capabilities are often crosscutting the
organizational structure.  

To overcome this obstacle, educating all stakeholders involved on this new notion of Capa-
bilityis key. To make this rather abstract notion tangible, it’s required to explain what it means
in concrete, business-focused terms, using your own organization as an example. Show how
Capabilities are implementation-independent and describe what’s possible. This is the key
advantage of capability thinking: it focuses on the current and desired abilities of the enter-
prise, on what it can do, not merely on its day-to-day operations, processes, or departments.
Explain to your stakeholders how this lets you focus your attention on those Capabilities that
are strategically important because they differentiate your organization from its competitors.
Where you’re able to do things others can’t.  

Managing the capability definition or assessment process 

Often it’s quite difficult to get agreement on capability identification or definitions. Some
business architecture methods take a very strict approach to capability identification and
naming. However, from our experiences, it’s more important to use relatable terminology to
ensure organizational acceptance rather than focusing on methodological purity. Without ac-
ceptance, failure is ensured. 

A factor in this is team size. On the one hand, getting to an agreement is more difficult. Con-
versely, too many cooks spoil the soup: large definitions where every team member has con-
tributed some words are not always the best outcome. It’s easier to work with a small group
of business experts and someone versed in Business Architecture to help shape the result.
Moreover, you can present the resulting Capabilities and definitions as work-in-progress, to
be amended if needed, rather than set in stone. Of course, you want to have a largely stable

56
 Guarantee Successful Implementation By Overcoming Major Obstacles

capability structure, but there’s always room for improvement and if someone feels left out,
they can still provide their input later. Changes will always occur in a volatile business world. 

Ensure rapid time-to-value 

It’s important to show value as soon as possible. It’s simply not acceptable to take many months
to create a Capability Map or to do an in-depth maturity assessment of every Capability. On
top of that, mapping those capabilities to the people, processes, technology and information
involved may also take a lot of work. But you don’t always need all those details to show the
initial value. You can get a small group of business experts together to forge an approximate
picture, use that to confirm the level of detail needed, and reduce the scope of your effort if
necessary.  

Although some approaches advocate building a complete Capability Map that covers every
aspect of your enterprise, we think it’s much more useful to concentrate your efforts on those
capabilities that are of strategic importance: the core capabilities that differentiate your en-
terprise from others or the enabling capabilities that lack investment and therefore can’t ad-
equately support these core capabilities. Of course, these will be supported by any number of
enabling and commodity capabilities that are also relevant, but from a strategic perspective,
those won’t have as much of an impact. You don’t need to elaborate on lower-level capabilities
or detailed definitions if those capabilities aren’t very important for business decision-making. 

Ensuring management sponsorship and stakeholder engagement 

To improve acceptance and buy-in, having sponsorship from senior management is key. A
main goal of Capability-based Planning is to improve decision-making on investments, which
is perhaps the most important responsibility of senior management. Hence, their involvement
and active promotion of this approach are essential. However, they may not always be involved
from the beginning, and convincing them of the value of Capability-based Planning requires a
solid argument. Typically, we would build a showcase focused on a limited number of strategic
capabilities, small enough to control the effort but large enough to demonstrate how Capabili-
ty-based Planning helps in decision making. 

This also holds true for the engagement of other stakeholders. Different communities in the
organization can gain from using Capability-based Planning in various ways, but they need to
be shown (rather than told) what these gains could be. Building Capability Heatmaps or Dash-
boards for a limited scope and a targeted audience helps them to understand what this new
way of thinking may bring. 

Overcoming resistance to changes in control 

Introducing Capability-based Planning as the basis for investment allocation by senior manage-
ment may invoke resistance from stakeholders lower down in the hierarchy. In many organiza-
tions, budgets are distributed to departments in a yearly budget cycle. Department managers
who control those budgets have a certain autonomy in discretionary spending. When budgets
are tied to specific capability improvements instead, they lose autonomy and may not like that.

57
 Guarantee Successful Implementation By Overcoming Major Obstacles

Conversely, C-level management may use this as a lever to break down middle management’s
fiefdoms and improve investment efficiency. In that respect, this is similar to approaches like
zero-based budgeting. 

This resistance may be especially strong with management with a Profit &Loss responsibility for
the department or business unit they manage. Allocating budgets along a different dimension,
such as Capabilities, will only succeed with active endorsement by C-level management. The
political implications of such changes aren’t something an architecture team can address. This
requires active, hands-on senior and executive involvement.  

Even then, you may not want to centralize budget allocation fully. Different business units
will often have different instances of the same Capability, funded separately. By focusing on
how those instances can learn from one another and share best practices, you may achieve
an overall capability improvement across the enterprise without needing a major budgeting
change.  

Making decisions at the right level in the organization 

In large organizations, you may need some federated decision-making approach to avoid an
overly bureaucratic centralized process for capability assessment, gap analysis, and budget al-
location across the entire enterprise. Moreover, those closer to the action are often better able
to judge what is needed in the short term and for local improvements. Longer-term, strategic
decisions, for instance, on developing entirely new capabilities, divesting or outsourcing others,
etc., are best taken higher up in the organization, where management has a better overview of
the enterprise-wide impact.  

So even though Capabilities are crosscutting organizational structure, you may still want to use
that structure to manage some Capabilities lower down in the organization. Simply because
centralized, top-down control doesn’t always work.  

Conversely, in some cases, you could think of changing the organizational structure to better
align with the Capabilities it offers. That won’t work for all Capabilities, but it may improve and
align management structures. Not least because if people work together in providing the same
Capability, you might want to align how you facilitate that collaboration and how you manage
them in terms of their OKRs, KPIs, incentives, etc. 

  

58
 10-step Approach to Implement and Grow Capability-based Planning

16. A 10-step Approach to Implement and Grow

Capability-based Planning 
Some approaches advocate creating a full Capability Map of your entire organization as a
starting point. While we see the benefits of that, for instance, to avoid overlapping capabili-
ties, we think that an iterative approach is more practical for most larger organizations simply
because of the scale of the effort. Moreover, such an approach will ease your stakeholders into
this approach without forcing them to change their established ways of working overnight and
avoid the pitfall of ‘analysis paralysis’.  

Our approach consists of the following steps (though you may want to pick and choose which
are most relevant to your organization and the resource capacity available): 

1. Identify the initial scope: Pick a relevant part of the business for which it is
feasible to start with a Capability-based Planning approach. You need to have
easy access to the relevant stakeholders and subject matter experts for this
scope.  

2. Lay the groundwork: Ensure stakeholders have a basic understanding of the

capability and value stream concepts. Work with subject matter experts to
identify the relevant capabilities down to a reasonable depth, say 2 levels.
Don’t go too detailed for a first cut: 4 levels or more would typically be too
much. 

3. Create a draft capability map for the chosen scope and validate this with the
stakeholders and SMEs. Refine this as needed. 

4. Perform an initial assessment of the strategic importance of these capabili-

ties. For instance, use a typical classification scheme of commodity vs. differ-
entiating vs. innovating, or relate these capabilities to specific strategic goals
of your enterprise. 

5. Do a basic analysis of the strategically most relevant capabilities from step 4.

For instance, perform a high-level capability maturity assessment or calculate
a roll-up of the IT cost related to capabilities. You may want to start with a
simple t-shirt sizing metric assessed by a domain expert before going into
more detailed assessments. 

6. Relate the capabilities you analyzed in the previous step to change initiatives
(e.g., projects and programs, agile value streams) that impact these capabil-
ities. 

7. Assess the expected impact of those initiatives on the analysis from step 5.

59
 10-step Approach to Implement and Grow Capability-based Planning

Will an initiative, for instance, lower the IT cost or increase the maturity of a
capability, and if so, by how much? 

8. Using this impact to prioritize these initiatives. Initially, use this as addition-
al information in the existing investment decision-making process to avoid
too much resistance. Once stakeholders see that this approach contributes
to better decision-making, this CBP-based information can become leading
rather than merely supporting. 

9. Use these priorities to identify new or realign existing change initiatives and
define capability roadmaps to close the gap between current and desired ca-
pability maturity.  

10. While implementing these change initiatives, track relevant KPIs and adjust
priorities as needed. 

Figure 39 Double-loop learning in implementing capability-based planning 

Additional points: how to extend our ten-step approach 

Implementing this reusable approach is itself an iterative process. From a specific, confined
scope, you can extend and grow in several directions: 

Expand the scope 

For example, rolling this out across different business units. Growing your capability map also
requires rethinking some parts since the additional scope may overlap in capabilities with the
parts you already addressed. Make sure your capability map does not become a substitute

60
 10-step Approach to Implement and Grow Capability-based Planning

for the organization structure since that would negate many of the advantages of capability
thinking. Remember, a capability is not equivalent to a team, department, or another organi-
zational unit. 

Expand the stakeholders involved 

This could be from IT into the business, and it could be from senior business managers to
business executives. Once senior leaders experience how this new way of thinking helps them
focus investment decisions on the capabilities that are key to their strategy, they may even
become advocates for this approach and convince their peers of its value. But the somewhat
abstract nature of the capability concept will require a lot of communication: you will likely need
to keep explaining this, and as they say, show, don’t tell: seeing it in action works best. On the
other hand, you can emphasize how capabilities are a shorthand for people, process, technol-
ogy and data, making complex topics easier to understand. 

Increase sponsorship 
It should move from being a one-off exercise to being central to the business planning cycle.
Business capabilities are generally static over time, so if they are used repeatedly, they become
more recognizable and readily understood by stakeholders. It justifies the investment in defining
them. Ideally, capability-based planning will move to the most appropriate team, e.g., the
Strategy Planning team or equivalent in your organization. 

Establish capability ownership 

An average organizational chart does not always lend itself to easily identifying capabili-
ty owners since capabilities often cross organization functions. However, executives could
become responsible for capabilities despite all the resources involved not being in their chain
of command. Ideally, with ownership comes responsibility for planning, resourcing and delivery
of the capability. 

Extend and refine the capability analyses and assessments 

Use more metrics, obtain better/more precise data, involve more subject-matter experts, and
integrate systems to pull the ‘official’ data to automate these assessments. By improving the
data used, decisions on investment in change become more based on facts and figures rather
than hunches and intuition. That helps you move away from ‘decibel-driven’ decision-making,
where the people with the loudest voices get their projects approved. 

Formalize investment prioritization  

Formalize investment prioritization along the lines of capabilities rather than classical projects,
typically in concert with other management changes. For example, this approach works well
with moving from project to product-focused teams in IT. The key change here is that the
strategy is linked to a capability outcome rather than a project scope which can contract easily.  

Learn from this process of maturation  

Learn from this process of maturation using feedback from the organization to refine your way

61
 10-step Approach to Implement and Grow Capability-based Planning

of working. Capabilities are a new way of thinking, and while they offer numerous benefits that
support what organizations are trying to do, you need to listen to the challenges and successes
with this approach. 

Of course, you need to keep your stakeholders informed and committed all the time, manage
resistance when it occurs, and evaluate the return on investment of your CBP effort. Don’t
overdo it! Not everyone needs to become a CBP champion (but being at least a runner-up is an
excellent position to aim for).  

Political and emotional aspects of change 

This eBook is focused on the rational aspects of Capability-based Planning and not on change
management in general. However,  the political and emotional aspects of change are equally
important to make Capability-based Planning a success in your organization. This includes:   

● Understandability: Make your approach easy to comprehend and assess without

detailed knowledge or direct experience for stakeholders. 

● Simplicity: Remove the noise of details; the human brain can only take in so much
information. 

● Granularity: When making a decision, people will have questions; ideally, always
be able to answer a stakeholder’s questions by really showing (e.g. by tracing it in
your models) rather than just telling these stakeholders what the answer to their
question is. 

● Collaboration: Any change in the way of working requires persuading, challeng-

ing, arguing, agreeing, creating coalitions, and horse-trading.  

Especially when it comes to organizational politics, architects are often ill at ease and out of
their depth. Teaming up with someone more versed in this dimension of change (e.g., an ex-
perienced program manager or senior business leader) could be a good way to establish and
mature a Capability-based Planning approach.  

Most importantly, this should not be a ‘push’ effort from architects. Rather, you should aim to
create a ‘pull’ from senior stakeholders by showing the added value of such an approach for
their daily work and responsibilities. Once you succeed in piquing their interest, you may be
surprised by the traction you will gain with such an architectural approach to business change. 

  

62
 Need help with Capability-based Planning?

Need help with Capability-based Planning?  

By using our powerful enterprise architecture SaaS platform, Bizzdesign Horizzon, for Capa-
bility-Based Planning, you can ensure the alignment of your (IT) transformation to business
strategy using a common language.

Let’s get you started! Our platform:

● Aligns strategy, goals, business priorities and processes to applications, organi-

zations and technology investments

● Defines what capabilities your organization needs and is capable of (indepen-

dent from the organizational structure) to achieve the desired business outcomes

● Helps you get an enterprise-wide perspective of business performance and

identify priorities for investments aligned with your organization’s strategic goals

● Sets investment priorities that deliver the most value to your organization, in line
with your strategy

Contact us today for a demo, or for more information, visit bizzdesign.com or follow us
on Twitter, Facebook, and LinkedIn.

63
 Contributors

Contributors 
 

Marc Lankhorst, Managing Consultant

Connect on linkedIn

Bernd Ihnen, Senior Consultant

Connect on linkedIn

Jeeps Rekhi, Senior Business and Enterprise Architect

Connect on linkedIn

Sven van Dijk, Consultant and Trainer

Connect on linkedIn

Henk Jonkers, Customer Success Consultant

Connect on linkedIn

64
 Contributors

65