(This is part of an ongoing series that attempts to resolve problems in (mis)interpretation of the Cynefin framework, and in particular the commonly-used Cynefin diagram. For the correct interpretation and use of the Cynefin framework and Cynefin techniques, please contact Dave Snowden at Cognitive Edge.)
The standard Cynefin diagram is as follows:
Diagram by Dave Snowden, Cognitive Edge (image: public domain)
As the Wikipedia article states, “The model provides a taxonomy that guides what sort of explanations and/or solutions may apply.” Unfortunately, this is a generic model that lends itself to multiple interpretations, only one of which is ‘correct’ Cynefin. There are also multiple uses of the concepts and conceptual space summarised in the model’s taxonomy and pathways, of which, again, only a specific subset may legitimately be described as Cynefin.
It is therefore important to state that what follows is not ‘Cynefin’, yet necessarily uses what is in essence much the same taxonomy (see ‘Framework role and purpose’ and ‘Similarities to Cynefin’ in the previous post ‘Solution-space: beyond Cynefin?‘).
The central theme in this ‘not-Cynefin’ framework is the concept of ‘problem-space’ and ’solution-space’.
Problem-space is the context of the problem. Part of this is repeatability, or perceived cause-effect relationships, which can usefully be mapped using the same ‘Cynefin’ taxonomy:
- Simple: very high perceived repeatability, in accordance with simple linear cause-effect rules
- Complicated: linear (repeatable) cause-effect relationships, but may involve multiple factors, delays and feedback-loops
- Complex: cause-effect relationships are context-dependent – for example, where the effect itself becomes the cause
- Chaotic: no perceived cause-effect relationships
(The central region of ‘Disorder‘ is always ‘chaotic’, by definition, because it is the starting-point before any cause-effect relationships can be determined; the Chaotic-domain of problem-space applies where some or all of the problem continues to show no perceivable cause-effect relationships.)
Solution-space is the context and characteristics of the solution – i.e. the methods used to resolve the perceived problem. This too can be usefully mapped using the same taxonomy:
- Simple: the solution uses rules based on linear cause-effect logic
- Complicated: the solution uses analytic algorithms allowing for feedback, delays, etc, but are ultimately based on linear cause-effect logic
- Complex: the solution uses context-sensitive heuristics, guidelines and iterative re-assessment, in which the problem is continually ‘re-solved’ rather than ’solved’
- Chaotic: the solution uses principles to guide creation of uniquely context-dependent results
(Note: these are only one-line summaries, not formal definitions!)
The process of finding an appropriate solution to a specified problem can be mapped as a pathway across solution-space. To succeed (i.e. to be effective), the ultimately-selected solution(s) must map appropriately to the context of the problem in problem-space. Note that although in some cases a problem may be situated in just one specific location in problem-space, it is more common for it to occupy a region or even to have components that spread out across multiple regions. For example, a context might be mostly resolved by a rules-based automated process (Simple) but also ’special cases’ that may need to be ‘escalated’ to an algorithmic system (Complicated), a manual review (Complex) or specialist expertise (Chaotic) for a ‘one-off’ incident. The overall solution must resolve all components in problem-space.
The core concept in the use of this framework is recursive meta-methodology. For example:
- a method in solution-space acts on the problem in problem-space
- a methodology selects an appropriate method
- a meta-methodology selects an appropriate methodology
- a meta-meta-methodology selects an appropriate meta-methodology
…and so on. A methodology is a path within solution-space; a meta-methodology is a path in another layer of solution-space; in effect, the layers may be nested indefinitely, but must ultimately all resolve to a set of methods that address the actual problem in problem-space.
The ultimate aim of all of this is to find methods that are appropriate and effective for any given problem, in any business context (such as my primary field of enterprise-architecture), or in any other field, as required.
I’ll stop here for now, but will give more explanation and illustrative examples in later posts in this series.
Previous posts in this series: