What are Business Capabilities & How to Identify them?
Aug 13, 2021
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.
Figure 1. Simplified capability map of an insurance company (inspired by the Panorama 360 reference model)
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.
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.
These general guidelines will help you identify your business capabilities:
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.
