Design Principles for Business Capability Maps (Part 2)

Feb 10, 2022
Written by
Bernd Ihnen
Bernd Ihnen
Jeeps Rekhi
Jeeps Rekhi

Design Principles for Business Capability Maps (Part 2)

Value is delivered to the enterprise when Capability Maps are readily accepted and adopted as a strategic planning tool. Business stakeholders can make data-driven decisions and align and prioritize investment decisions, among others. In part 1 of our blog series on Business Capability Maps, we’ve identified design principles focusing on the stakeholders consuming the Capability Maps, the general structure of a map, as well as its visual appeal.

In this post, we share principles for the definition/ decomposition of a Capability Map and the first steps of how to start.

Capability Definition

There are two general principles that you need to follow when you define Capabilities:

  1. Business capabilities are represented and defined by the business: it’s not an ‘IT thing’!
  2. 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 have 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 capability 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 understand 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 descriptions, be:

  •  Precise: Explain – don’t simply repeat the name of the capability in the description. 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.

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 describing 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 components and other business/ application/ technology concepts. These differences are described in the blog: “Capabilities vs. Business Functions: Same Difference?

Business Capabilities as the Cornerstone of Your Digital Transformation Strategy
Business capabilities help architects give decision support to the C-level to execute the organization’s transformation strategy

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.A tip: Keep the depth of the capability map similar. Use 2-3 or 3-4 levels, and not 1-3 or 2-4 levels. This will make your mapping and analysis efforts easier.

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 external information (e.g. previous Capability Maps, consultant findings), industry references (e.g. sector capability models), organizational charts and process models. Use the design principles to define, refine and test the Business Capability Map through socialization and validation cycles. Ensure to include all the relevant business functions, and not only IT.

If you have questions, please do not hesitate to contact us. We can take you through a presentation showing first-hand the design principles described in this blog.

Look out for the next topic in our blog series about assessing capabilities!