Master Interweaving

Business Transformations through a structured integration and alignment of Strategy with Operations.

Improving Capabilities from Open Group (TOGAF Business Capabilities)

It was with great interest that I opened the Open Group’s guide for Business Capabilities. This business architecture addendum is a welcome addition to their (information) technology oriented Enterprise Architecture framework - TOGAF. TOGAF is a well known, respected, and widely used framework with quite many practitioners. 

Half-way through the guide something started to bother me. Something felt very familiar. Then I realised that the guide follows the tradition of framework presentations. A framework is explained first, then the benefits of using the it, are assumed to be obvious and clear.

This article is aimed at people interested in getting some ideas on how to enrich capability based analysis and modelling based on frameworks such as TOGAF.

I have been building frameworks and international standards since the end of 1990th on all levels from UN, ISO, EU, state agencies, mega projects to companies. In this work I have come to realise that this is the backward way to do it. The primary focus must be on beneficial use, and not on secondary behind-the curtain descriptions made by experts.

Can a guide such as this be turned around, into a valuable story Yes, but not without a few tricks.

  1. Introduce work orientation
  2. Shift focus to underlying concepts
  3. De-empathise levelling
  4. Shift to a conversions of source factors
  5. Add a human oriented and a logic story 

Let us start where values are created, in the use of tools such as the use of capability based analysis and models.

We don’t really know the real value of using a tool by understanding the tool itself or a stakeholder. This observation is consistent with the “Job to be Done” way of approaching customer orientation.  Prof Christensen from Harvard Business School covers this topic in an article in HBR, “Know Your Customers’ “Jobs to Be Done””.

“The circumstances are more important than customer characteristics, product attributes, new technologies, or trends.”

This hard-earned learning-point has been infused into the Interweaving practice, where the focus is on the primary, the benefits in work people do with others, across boundaries. In an upcoming article I intend to cover more the underpinnings of Work orientation.

1. Introduce work orientation

The first step is to introduce work orientation, a feature from Interweaving, which is human centric, work oriented and instrumental practice.

By shifting focus to work orientation we get closer to thinking about and caring for the values a tool can bring in some real situations or circumstances. This thinking differers from TOGAF, ISO 42010, and traditional approaches where the concerns of a stakeholder frames a viewpoint. Most of the times such concerns are knowledge oriented, which does not differentiate between stakeholders needs under different circumstances. After all, everybody is interested in “who is doing what with whom”, but they don’t have the same interests and needs.

By explicitly documenting “Work/job to be done” we get to explicitly and consciously to think about how results and benefits are created. 

  • What work is done and what tools are needed to do the task well?
  • What kind of questions are asked and what support can tools provide? 
  • What kind of decisions are made?
  • etc, etc

The bottomline is that an expert can create fantastic tools, but without explicit confirmation and validation that a tool is understandable, valuable, workable, acceptable and agreeable, a tool may be a waste of time and effort. As the story goes, Silicon Valley is full of visions and beautiful technologies on the scrapheap, with technologies that work well but the customer don’t want them or cannot use them as intended.

The following diagram illustrates a shift to work orientation from stakeholder viewpoints.


2. Shift focus to underlying concepts

The second step is to shift focus to the underlying concepts that a specific capability is based on from the rather square idea of capability itself .

Instead of talking about a capability with a name consisting of a verb and noun, “Innovation Management”, the discussion should be about the business phenomenon of ‘Innovation Management’. Without knowing anything about the essence of Innovation there cannot be real substantive discussions about an “Innovation Management Capability”.

See following articles for deeper information:

Untangling: What comes first, economical concept or capability?

Untangling: Is there more than a Capability to think about? 

3. Deempathise levelling

The third step is to deempathise levelling. In the face of real workflows, (theoretical) levels tend to disappear and can in many cases become barriers to meaningful discussions and decisions. 

In many cases, levels reflect method-builders standardised point-of-view of an organisation and contains predefined assumptions about people and their work-to-be-done. Interweaving supports different kinds of capabilities by looking at  peoples work-to-be-done. This approach support directly the creation and use of understandable, valuable, workable, acceptable and agreeable capability based analysis and models .

For each work-to-be-done, a capability must be based on meaningful business or operational concepts. The concepts are also relevant because they are part of shared mental models, decision making, and joint actions.

With respect to the presentation: 

  • Senior stakeholders is a large group. Do they perform work-to-be-done where they need the same capability models and information about the same kind of capabilities?
  • How many capabilities are related to management of something? Aren’t there other core concepts that top-level management and analysts are interested in?
  • Why should an advice of 20-30 capabilities be relevant? Isn’t it better to listen to people and hear what they need for their work? 

4. Shift to a conversions of source factors

The fourth step is to shift the view of a capability to a possibility that a result is achieved through the conversion of source factors. This instead of thinking of a capability that consists of components.

See the Capability Patterns for a visual explanation, Stylise Capability pattern, Extended Stylised Capability pattern

A component view is consistent with an IT and technology approach where the aim is to build something (technical) from components. However, this view opens up to serious complications. 

Can you in advance know the salient (most important) source factors and conversions, and how much they contribute to the result? A predefined set of kinds of components limits the options and reduce reasoning about what really are behind a capability. Some source or conversion factors may be missed and the included factors contribute only to a lesser degree. Maybe a capability to retain customers rely on the existence of a particular customer support centre and its dynamic boss, as opposed to customers support process components.

The problems with pre-choosing source factors are well-know within data analysis, econometrics, forecasting, decision making, and science in general. The wrong choices introduce flaws and bias into decision making with possible significant effects and dis-benefits.

Furthermore, the idea that a capability consists of discrete components (source factors) miss something unique and vital to the idea of capability. What is missing is the silent factor of how all the factors fit (align, integrate,…), act (coordinated,…), and evolve together. A team that works well together (able), or has proven in the past to work well together (competent), is generally more capable than a team that just has been assembled or brought in from sourcing partner. Same components but different strengths (substantiality).

5. Add a human oriented and a logic story

Model diagrams with squares or post-it’s are easy to look at but much more difficult to understand. Especially by people that were not part of the process creating them. In order to increase understanding and actual use, a capability model should / must be accompanied by…

  • a Conceptual Story aimed for human consumption and understanding. A conceptual story focus on the more imaginative right side of the brain.
  • a Logic Story that contains underlying logic behind the (point-of-) View. The logic story focus on the more logical left side of the brain.

See Point-of-View needs good Stories for more information.

These four steps all aim at bringing closer capability based analysis and modelling to delivering results and benefits in work people to with others


Interweaving is a unique approach and practice with its focus on work-to-be-done and what is most important (salient) to people. Without anchoring in work-to-be-done a capability tool and models may take on a life of their own, being relevant to experts, architects and modellers alone. 

Instead of assuming, Interweaving includes checks and balances where qualities such as understandable, valuable, workable, acceptable and agreeable are confirmed by actual workers, in their own world.

Remember, If you are going to use capabilities than they must be workable by people in the organisation. If not, then why spend funds creating, analysing, and assigning responsibility to capabilities?


/ Anders W. Tell

/ WorkEm Toolsmiths


Meaningful ... Business Capabilities
Tools of the trade: Talking Point Canvas

Related Posts