Business Capabilities are at the heart of an organization’s planning ecosystem. Capability mapping serves many purposes, two of which are critical. First, business capabilities are instrumental in setting priorities more quickly focusing on the most profitable initiatives first. Second, well crafted detailed capability-based roadmap allows agile project planning that is more accurate, less risky, and takes less time.
What Is a Capability Model?
According to TOGAF®, “A business capability is a particular ability that a business may possess or exchange to achieve a specific purpose.[1]” A business capability delimits what an organization does or wants to do without attempting to explain how, why, or where the organization uses the capability.
As for a business capability map or capability model, it is the complete and stable set of business capabilities of an organization. A business capability model provides the visual depiction (or blueprint) of all the business capabilities that are or could be used by an organization[2]. For example, Figure 1 above shows the typical level 1 business capabilities in the financial services industry[3]. Each one of these level 1 business capabilities can be decomposed into several levels deep, logically grouped into different tiers to enable analysis and planning.
In Figure 1, level 1 business capabilities are categorized into 8 functional tiers. In a TOGAF® business architecture certification course, it is recommended that you stratify level 1 business capabilities into 3 tiers: 1- strategic, 2- core, and 3- supporting. In my experience, most business stakeholders are more comfortable grouping their level 1 capabilities by function. The number of functional tiers can vary a lot from one organization to another.
It should also be noted that seven of the eight tiers in Figure 1 are almost identical from one industry to another. These seven common functional tiers are 1- client-driven, 2- marketing & sales, 3- strategy, 4- human resources, 5- finance and accounting, 6- enterprise support, and 7- governance and compliance. The level 1 capabilities grouped under the financial services tier are unique to the banking and financial services industry. It goes without saying that every client that has used and examined this framework made adjustments to reflect the reality of their own organization. In the financial services industry, other capability frameworks are available, including the Banking Industry Architecture Network (BIAN) business capability map[4]. Capability frameworks also exist for other industries[5].
Why Focus on Capabilities?
There are four good reasons to use business capabilities, as explained here:
- Capabilities are more stable in time than org charts, processes, products, or applications. Business units will usually perform several capabilities. Business units are not as stable as capabilities over time. Why not processes? Processes change often over time and from one business unit to another.
- Priorities are set more quickly focusing on the most profitable initiatives first.
- Capability-based agile project planning is more accurate, less risky, and takes less time. Agile requirements, epics, and user stories are described much more accurately starting from a detailed capability-based roadmap.
- Capabilities allow an organization to sort through and make sense of its supporting applications/systems.
How to Build a Capability Map?
A business capability model corresponds to a complete and stable set of business capabilities. The modeling methodology should typically include a top-down and bottom-up approach from business design to agile solution delivery and execution.
To begin with, a capability model may include only level 1, 2, and possibly level 3 business capabilities organized in several tiers. To accelerate the process, many organizations will avoid beginning with a blank page and start instead with an industry-based framework that will then be modified initially by the business and enterprise architecture team to reflect the reality and vocabulary of the organization. Once the architecture team is comfortable with the preliminary capability model, validation and approval in a top-down approach by business stakeholders, usually business managers, needs to occur.
The decomposition of the top-level business capability into lower levels can occur later in a bottom-up approach, especially if the business process documentation is either absent or outdated. Trying to find and validate all lower-level capabilities is a waste of time. Lower-level business capabilities can be discovered instead while finding the enabling business capabilities of value streams like the ones mentioned in Figure 2 below. Value streams or customer journeys are excellent approaches to identify problematic enabling capabilities (high priority and low-performance capabilities, for example), as explained in this book. Furthermore, value streams are also used extensively in many agile delivery approaches, including the Scaled Agile Framework® (SAFe®).
It should also be noted that the title of a capability should be explicit enough to be easily searchable by subject matter experts. Capabilities should always include a simple and clear description easily understandable by business and IT stakeholders to avoid confusion. Capabilities should have unique ID numbers for data synchronization because often they will be used in many planning applications like IRIS Business Architect, Ardoq, Avolution, LeanIX, Orbus, ServiceNow, PowerBI, etc. It should also be observed that enabling capabilities of value streams can be measured in several ways. Be also advised that the examination of a problematic capability will often require its decomposition into at least 5 levels deep, especially if business processes are non-existent or outdated. This way, the refinement of a capability model of an organization will occur naturally with the accumulation of examined value streams and their enabling capabilities over time. As a rule of thumb, a business capability that enables a value stream is usually far more important for an organization than business capabilities that are not.
Cross-Map Capability Relationship
Business capabilities should be the main anchor of an organization’s planning ecosystem because of their stability over time. They can be cross-mapped to at least 10 domains of interest, four of which are mentioned in TOGAF®[6] , as mentioned here:
1. People and business units, including internal or external stakeholders, business units, divisions, or partners involved in owning or using a business capability.
2. Processes. Business capabilities may be operationalized through one or several business processes. Examining the efficiency of these related processes is often used to measure the maturity of a capability.
3. Information. Information concepts represent the business data and knowledge required by a business capability.
4. Resources. Business capabilities rely on a range of IT systems, applications, and micro-services, but also physical assets, and even intangible assets.
As illustrated in Figure 3[7] above, 5 other domains of interest can be cross-mapped to business capabilities, as mentioned here:
5. Capability/Value Stream Mapping,
6. Capability/Product,
7. Capability/Initiative,
8. Capability/Requirement, and
9. Capability/Strategy.
Business Capabilities are at the heart of an organization’s planning ecosystem. Handled right, they can be instrumental in identifying an organization’s priorities. Furthermore, they need to be used systematically in IT portfolio and project management to deliver a detailed roadmap to be shared and used by agile delivery teams and increase the odds of success of an organization’s digital transformations.
Author: Daniel Lambert, Managing Partner at Business Architecture Info
Daniel Lambert, M.Sc., is a business strategist assisting business and enterprise architecture teams in collaborating better with the entire planning ecosystem of their firm and increasing the success rate of their organization's digital transformation initiatives and projects. He can be reached at https://www.businessarchitecture.info.
References/footnotes:
- This definition is item 4.28 on this webpage on the Open Group website.
- A definition of a capability map is available in section 3 on this webpage on the Open Group website.
- This framework is available on this webpage on the Business Architecture Info website.
- The BIAN business capability map can be viewed on this webpage.
- Business capability models are available among others on this webpage for the following industries: energy and utilities, financial services, healthcare, insurance, manufacturing, pharmaceuticals, retail, telecom, and transportation.
- The 4 elements of the implementation of a business capability are mentioned in section 2.2 on this webpage on the Open Group website.
- This figure is extracted from the video entitled “Capabilities – the Heart of Your Business and Enterprise Architecture”.