Human Processes: Capabilities

Most Enterprise Architecture methodologies, including the market leader TOGAF, now include the modelling of Capabilities. However, it is not always clear what a Capability is, how to use it, and how it relates to other model elements such as Business Processes and Value Streams. For this reason, many organisations waste a lot of modelling effort. Here is a brief analysis of how to approach Capabilities, explaining their fundamental connection with Human Processes.

TOGAF has the following to say in “Business Capabilities” (TOGAF® Series Guide, 2018, section 2.1):

“Defining a business capability involves identifying and describing what needs to be done by the business in support of its overall mission.”

This rather vague description is supplemented with a little more detail in section 2.2:

“A combination of roles, processes, information, and tools enable a business capability. The process of reviewing each of the business capability components helps refine the business capability name and description and supports the subsequent analysis of business capability gaps, duplications, and redundancies. This decomposition can be used as a test to check that the capability definition is, in fact, a business capability (rather than a process, organizational function, or service).

Business capabilities are coarse-grained concepts that enable business planning from different viewpoints. Business capabilities are built to focus on what the business does rather than how the businesses use business capabilities to deliver business value. That said, in order for a capability to be defined, we need to understand how the capability is realized in the form of roles, processes, information, and tools. The key distinction is that the business capability components will change regularly, but the business capability endures over longer planning horizons. The how of a capability must be self-contained within the capability.”

This is still less than helpful. The text points out that it can be hard to distinguish a Capability from a process, organizational function, or service, but saying that the high-level description endures across changes to implementation is not enough to help make this distinction. We will see that this is not even true.

Since an organization should only possess a Capability that is useful for its business purpose, it is more helpful to think about Capabilities in reference to value mapping. However, we have to be careful here too, since there are several approaches to modelling value.

Michael Porter’s Value Chain partitions an organization into activities, often incarnated as functions or departments, showing costs and sources of differentiation:

Value Chain
Figure 1: Porter Value Chain

Value Networks identify the participants involved in creating value, describing social and technical resources in order to understand the dependencies and relationships:

Fig.2: Value Network
Figure 2: Value Network

Lean Value Streams model the sequence of activities required to design, produce, and deliver a good or service, in order to optimize the associated business processes:

Fig.3: Lean Value Stream
Fig. 3: Lean Value Stream

Value Mapping (as defined in TOGAF) presents an end to end collection of value adding activities, represented by incremental stages that capture stakeholder perception of value:

Fig. 4: TOGAF Value Mapping
Figure 4: TOGAF Value Mapping

None of the above techniques helps us understand the relationship between Capabilities and other modelling constructs. Porter Value Chains are generally used in relation to organizational structure. Value Networks are about stakeholders. Lean Value Streams help optimise business processes. TOGAF Value Maps also make reference to business processes, although they also make use of Capabilities, which muddies the water further.

A more recent technique for modelling value is Wardley Mapping, which is not intended as a way of defining Capabilities, but is of more use in doing so than any of the above. Wardley Mapping has a number of associated diagrammatic techniques, but the more important thing for our purposes here is that it is a methodology for shaping the strategy of an organization:

  • Observe – Create situational awareness, remembering that maps change over time
    1. Needs – Identify what customers want
    2. Value Chain – Not a Porter Value Chain but rather a holistic approach to TOGAF Value Streams
    3. Map – Show how mechanisms are changing
  • Orientate – Work with stakeholders to remove duplication and bias, refine maps (adding metrics as needed), and identify areas of possible re-use
    1. Challenge – Remove duplication, choosing the most effective way forward
    2. Adjust – Find commonality and define shared services
  • Decide – Decide on strategy and implementation, creating any artefacts needed (SWOT, Business Model Canvas, and so on)
    1. Think – Use gameplay to box clever
    2. Methods – Choose the direction of travel
    3. Simple – FIST (Fast, Inexpensive, Simple and Tiny) via small, self-organising teams
    4. Evaluate – Refinement step that may not be necessary
  • Act – Start iterating
    1. Act – Agile, Scrum, Kanban, …

The end product of Wardley Mapping may be a diagram such as this:

Figure 2: End product of Wardley Mapping
Figure 5: End product of Wardley Mapping

The areas grouped by dotted lines represent shared business services, that may be provided in-house or by partners in a value network. These are effectively Capabilities. Looking at them through the lens of Wardley Mapping makes several things clear:

  • Contrary to the advice provided in TOGAF documentation, Capabilities are not fixed but must evolve to align with opportunities and threats resulting from a changing business environment.
  • Hence, Capabilities are inseparable from organizational strategy.
  • This strategy is implemented by dividing an organization into programme teams, each of which is responsible for implementing a Capability.
  • Each team must understand their place in the organizational roadmap, and how their deliverables fit together over time.
  • Associated technical deliverables should be provided in an Agile way, since it will not be clear at the start exactly how the integration is to be achieved or what obstacles will be encountered along the way.

In other words, Capability modelling results in the definition of a set of inter-related Human Processes for organizational development, which are responsible for delivering new business services and associated technical deliverables. This means that to be effective in defining and delivering Capabilities, an organization must be effective in defining and delivering these Human Processes – for which I refer the reader to other columns in this series.

PDF Version

Keith Harrison-Broninski

Keith Harrison-Broninski

Keith Harrison-Broninski FRSA is an author, speaker, and technology/business consultant specialising in collaboration across organisational boundaries as well as social technology for wellness, community, and finance. Keith’s first book was "Human Interactions" (2005): "Set to produce the first fundamental advances in personal productivity since the arrival of the spreadsheet" (Information Age); "The breakthrough that changes the rules of business" (Peter Fingar, author of "Business Process Management: The Third Wave"); "The overarching framework for 21st century business technology" (BP Trends); "The next logical step in process-based technology" (Chair of the Workflow Management Coalition). Keith went on to develop these principles for cross-boundary collaboration in further books and research and lead award-winning social enterprises for healthcare innovation, wellness, and community finance. Keith’s latest book "Supercommunities" brings together insights from recent academic research with original ideas about wellness, collaboration, and finance to explain how communities everywhere can become antifragile through social trading.


Leave a Reply

Your email address will not be published. Required fields are marked *