Context-space mapping and the Chaotic domain
(This series of posts explores a concept of ‘context-space’ which in part draws on a categorisation immortalised in a certain well-known diagram. It must be emphasised that this is not about ‘That Welsh Framework‘ (aka twf) which that diagram illustrates: for details on twf, please contact this company. I apologise for these absurd aliases, but regrettably their necessity has been forced upon us by others.)
We seem to be iterating steadily towards a full description of what I’ve termed context-space mapping (as a more permanent name than the temporary label ‘tinc‘). For example, there’s been some very useful discussion on the previous post, especially by enterprise-architects Paul Jansen and Sally Bean. Paul Jansen followed this up with another Tweet:
In fact this leads to what is probably the fundamental difference between twf and context-space mapping (aka tinc): the role of the Chaotic domain. This particularly applies in terms of the respective views of repeatability within the context.
In the hope of preventing yet more repercussions, I won’t say anything about twf‘s approach at this point, other than to express my opinion that, in the terms of context-space mapping, its focus is primarily on the Complex domain, which in turn leads to an emphasis on contexts that are ‘partly-repeatable’ in highly complex ‘unordered’ ways.
Context-space mapping, however, needs to cover all repeatability-types. As twf‘s proponent indicates, the Simple domain of presumed-repeatability is covered by Taylorism et al.; the Complicated domain of analysed-repeatability by hard-Systems Thinking and the like; and the Complex by twf and so on. But there’s so far been little or nothing to cover the Chaotic domain of ‘barely-repeatable’ events and processes. So in practice it’s likely that that’s where whole-of-scope techniques such as context-space mapping will have the most impact.
The central theme in the Chaotic domain of practice is low- to zero-repeatability: some part(s) of the practice cannot be repeated, either because the conditions have changed – including the awareness and experience of the person doing the work. Conventional ‘scientific-analysis’ approaches (Complicated-domain) rely on repeatability, so they’re actually not all that much use in the Chaotic components of any real-world task – in fact will often be misleading because they provide an illusion of predictability. In a way, the same is true of many Complex-domain techniques: they give us a much more reliable picture of an overall uncertain context, but we can’t reliably apply that in reverse to tell us what to do for a specific ‘market-of-one’, such as a specific medical diagnosis.
Ability to engage appropriately in the Chaotic-domain in this sense is almost a definition of skill. It’s also a key component of almost all knowledge-work – which is why this concern is coming much more to the fore, as knowledge-work becomes an increasingly important part of the overall economy.
At the business-process level, one of the key figures is Sigurd Rinde, whose concept of ‘barely-repeatable processes’ is the focus for his Thingamy business-process-execution software. The whole point of Thingamy is that the processes themselves are made up as they go along, by the people doing the work, expressing and applying their expertise. Underneath this, however, is a consistent Simple structure that records every decision, every artefact, every transfer of responsibility – which makes it possible to create any required reports from the process, including conventional statistical analysis. The result is nicely summarised on Sig’s other website, 30megs.com – so-called from his tag-line “Here’s 30 Megs. Now go run Germany”, which in principle is entirely feasible with this kind of decision-support/decision-tracking software. Sig is not alone in this, of course – for example, Stafford Beer developed something similar that in effect ran the entire economy of Chile for a while, way back in the early 1970s – but Thingamy is probably the best example of a software package available today that is designed for true Chaotic-domain processes.
Context-space mapping is part of what needs to happen before we settle on any technique or tool such as Thingamy. It’s about mapping the options available to us, and the decisions that we make within ‘solution-space’, as part of an overall process of sensemaking in order to arrive at appropriate actions for the context. One of the key points in this is an awareness that we are part of the context, part of the ‘solution’: in the classic Chaotic-domain sense, there is a boundary, and there is no boundary, always in the same moment.
We always start from ‘reality’ – that which in twf is termed the ‘disorder’ domain. (Everything does in fact take place within that domain: any purported subdivisions – such as Simple, Chaotic and suchlike – are sensemaking-abstractions that we place onto that domain, but are not actually ‘real’ as such.) From there, we would move into some kind of recursive OODA loop (Observe/Orient/Decide/Act), where sensemaking itself forms one or more of the earliest iterations. In those terms, context-space mapping would typically proceed as follows:
- Observe: What is ‘the context’ here?
- Orient: How do I make sense of what I’m seeing?
- What parts of the context appear to be unique (Chaotic), unordered or ‘wicked-problem’ (Complex), complicated but repeatable (Complicated) or universal (Simple)? Using that categorisation, map out the ‘problem-space’.
- Given that categorisation, what cross-maps would be useful for sensemaking?
Note: There are an infinite number of cross-maps that could be used: some examples shown in this series include:
- here: repeatability and action-tactics; domains and tetradian asset-dimensions; time versus focus; Jungian domains
- here: twf tactics and types of practice; timescale versus ‘bindedness’; development of embodied ‘best-practice’
- here: repeatability and ‘truth’; marketing versus sales; the ‘plan / do / check / act’ cycle
- here: ISO-9000 quality-model; skill-levels; automated versus manual processes; asset-types; data, information, knowledge, wisdom
- here: cause/effect relationships; decision-mode, timescale and level of abstraction
- here: nature of boundaries between domains
- here: phases of matter
- Using the categorisations from the cross-maps, what available tools and techniques are ‘situated’ in what regions of the maps’ ‘solution-space’? What can we learn from this?
- Decide: Given what I have learned from sensemaking, what should be my ‘action-plan’?
- Select from the available tools/techniques.
- Decide on a plan as to how, why, when, where, by whom, with what, and in what order each of the selected tools or techniques should be used.
- Act: What am I doing as I am doing, and what do I see as I am doing?
- Enact the desired action.
- Apply the same overall OODA-loop to the action taken – recursively, where appropriate – for review, further sensemaking, decision and action.
- Repeat as appropriate.
(Some people might suggest that this kind of OODA-loop fits more within a twf-style Complex-domain mode than Chaotic-domain. True, there are important similarities, such as the shared focus on ‘unorder’ versus the Complicated/Simple notion of ‘order’. But the key distinction is that this acts on a single, individual, specific context rather than a Complex-domain collective – and is often also much closer to real-time than most Complex-domain decision-making.)
The above is a start towards how we would use context-space mapping, anyway. I’ll leave it there for now: any constructive comments, ideas and suggestions would be most welcome, as usual 🙂 – over to you?
Previous posts in this series:
- Complexity, chaos and enterprise-architecture
- More on chaos and Cynefin
- Alternatives to the ‘Cynefin’ term, please?
- Solution-space: beyond Cynefin?
- On meta-methodology
- Using ‘Cynefin-like’ cross-maps
- More ‘Cynefin-like’ cross-maps
- And more ‘Cynefin-like’ cross-maps
- More on meta-methodology
- ‘tinc’ – a Temporary Inconvenience
- Context-space mapping and enterprise-architecture