What are Business Capabilities & How to Identify them? – Bizzdesign

What are Business Capabilities & How to Identify them?

In the first instalment in this series, we gave an outline of the notion of ‘business capability’ and why it is so useful in strategy execution. But what exactly is this somewhat elusive concept and how do you define capabilities?

As mentioned in that previous blog post, 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 above: First, get away from organizational politics and technical limitations and look at the essence of what is 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. Capabilities 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 make sure that they are not bound to any specific implementation. 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 are used to reason in terms of organization structure, span of control, systems they own, business processes they manage or execute, et cetera. For instance, showing a capability map to managers often leads them to search out ‘their’ bit, where they think they are 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.

Simplified capability map

Figure 1. Simplified capability map of an insurance company (inspired by the Panorama 360 reference model)

Identification and Naming of Business Capabilities

Most important in defining business capabilities is therefore that they are named and defined in business terms by subject matter experts (often called ‘the business’ by IT people, but that is a dangerous catch-all term that we’d rather avoid). For any capability, it should be crystal clear what it does for the business. All too often, we see capability maps that were dreamed up by IT architects without sufficient business input, using technical terms, system-level functionalities rather than true business capabilities, focused on producing some data rather than delivering real business outcomes, et cetera.

It helps to use a naming scheme that clearly differentiates capabilities from other concepts, for instance business processes and value streams. Where a process or value stream defines the ‘business in motion’, sequencing activities to create a dynamic perspective on business behavior, capabilities 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 are 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 like Engineering, Marketing, and Accounting are explicitly forbidden: “Mapping teams should avoid using gerunds as the basis for capability names as they are not business objects and are only nouns in the nominal sense”. But their own examples don’t even adhere to this commandment… Moreover, this approach shows a focus on information/data rather than on the true abilities of the business.

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. Pick those business-relevant criteria that create 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 understood 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

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. They are different from business processes, functions, services, organization units, or IT systems, although these may all contribute to a capability. 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 are defined only once for the whole enterprise and they rarely change, unless, for example, your organization undertakes a new line of business or divests some of its current operations.
  • Capabilities may consist of sub-capabilities. A capability may also use other capabilities.
  •  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 assessments are the basis for capability-based planning. You can read more about this in our whitepaper.

Do’s & Don’ts

  • Involve business experts right from the start and create a cross-disciplinary capability mapping team. Don’t let the architects define the capabilities in isolation, 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.
  • Make sure 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.

In future instalments in this series, we will go into more detail on capability-based planning, analysis, relationships with other business architecture concepts, and more. Meanwhile, our whitepaper may provide you with some more insights in our thinking on the subject.