This post represents yet another attempt to describe certain fundamental differences in approach from twf (aka ‘That Welsh Framework‘ – so-called because we’re no longer allowed to use its official name at all) and to find an alternative term that might reduce the ongoing friction in that quarter.

To do this, we need to go right back to first-principles: the core concept of context-space, which eventually leads us to context-space mapping.

(Another long-ish post: more after the ‘Read more…’ link.)

Before any notion of order or unorder, or even of disorder, there is simply ‘the everything’: everything and nothing, all one, everything and nothing connected to everything and nothing else, a place-that-is-no-place that incorporates within itself every possibility. It’s not ‘chaos’ – it simply is.

There are all manner of names for this ‘active no-thing-ness’: Lao Tse called it ‘the Tao’, for example, whilst the ancient Greeks described it as ‘the Void’. For the more business-oriented purpose of enterprise-architects, though, we’ll need to constrain the scope of this ‘the everything’ somewhat, and we’ll also need a more ‘business-like’ label. So let’s call it context-space – the holographic, bounded-yet-unbounded space that contains every possibility within the chosen context.

In previous posts I’ve split this context-space into problem-space – the context in which things happen – and solution-space – the space in which we decide what to do in relation to what’s happening. But ultimately there’s just the context: “the only true model of a system is the system itself”.

Yet to make sense of anything, we need to impose some kind of structure. One place to start would be to filter ‘the everything’ in terms of its variability. Perceived-repeatability is one example of a variability that we might use (which we’ll come back to in a moment), but there are of course many others.

Initially this gives us a finely-graded spectrum of variability. Yet interestingly, most human sensory-perception is not very good with smooth gradations: it works much better with firmer boundaries. Hence most sensemaking will usually attempt to place some kind of ordered structure upon what may initially seem like unbounded chaos.

When we look at the physical world, of matter and material, we can see both of these processes in action, even within matter itself. There is a fairly smooth gradation of variability, primarily linked to temperature; yet there are also explicit ‘phase-boundaries’ where the internal relationship of matter undergo fundamental changes. Significant amounts of energy (‘latent heat’) can be absorbed or released in the ‘phase-transitions’ between these modes. In effect, these present as four distinct states of matter, traditionally described as Earth, Water, Air and Fire, for which the more scientific terms are respectively Solid, Liquid, Gas and Plasma.

Looking at the internal structures of matter within each of these states, we would typically describe the respective structural relationships as Simple, Complicated, Complex and Chaotic, as phases or domains within the context-space of matter. This categorisation along a single axis represents a simple first-order map of that context-space – hence context-space mapping.

Much the same applies to just about any other view into the overall context-space. If we take almost any type of gradation, we will be able to identify distinct phase-boundaries that can be used to partition the context-space into distinct regions along that axis: the nominal split of the visible-light spectrum into Red, Orange, Yellow, Green, Blue, Indigo and Violet is one such example. But perhaps the most useful split of all for enterprise-architecture and business-architecture is along an axis of repeatability, dividing the inherent uncertainty of context-space into regions that we could describe, in parallel with those states of matter, as Simple, Complicated, Complex and Chaotic.

Which brings us, unfortunately, into the same conceptual space as twf (That Welsh Framework) – though we’ve arrived there via what is, in very literal sense, a fundamentally-different route. And unlike twf, we can now see:

• how and why we’ve arrived at those particular categorisations
• how and why to use any specific axis for such categorisation
• what the boundaries between the ‘domains’ in the categorisation will look like
• how, why and when the nominally-Simple boundaries between categories may move (Complicated), blur (Complex) or fragment (Chaotic).

This provides a layered, recursive richness that is largely absent in twf. It also provides a means to link right across every possible view into context-space, rather than solely a specific set of interventions that focus primarily on a set of views into the Complex domain.

A first-order (single-axis) context-space map – such as the Simple-to-Chaotic ’stack’ – is not all that much use in practice. To make it more useful, we’ll need to add other axes as filters for sensemaking, to enable relevant information to fall out of the respective comparison. And we make it more useful again by selecting a related set of axes to provide a multi-dimensional base-map upon which other filters can be placed. (Two-dimensional base-maps are the easiest to work with, for obvious reasons, but three or more dimensions are entirely feasible – the tetradian is one example of a four-dimension frame compressed into three-dimensions for use as a base-map.) To do this, we choose axes which force the domains of the original single-axis spectrum into relationships of opposition and similarity with each other. For example, if we use ‘levels of abstraction’ as the core axis, and overlay that with timescale in one direction and a ‘value-versus-truth’ spectrum in the other, we arrive at the following base-map and its ‘cross-map’ of interpretive text-overlays:

Here Chaotic and Simple are in opposition over their means of interpretation, but similar in terms of timescale; Chaotic and Complex are similar in their means of interpretation, but opposites in terms of timescale; Simple and Complex, and Complicated and Chaotic, oppose each other on both axes; yet all domains are related in terms of layers of abstraction. The central region (‘reality’) is essentially a reminder that the domains represent related yet arbitrary views into what is actually the total ‘hologram’ of context-space – everything else is actually an abstraction from the real.

We then layer this recursively to apply to the nominal boundaries between each of the domains, so that these too may be considered to be fixed, movable, porous or fragmented or transient. An axis based on a simple binary true/false categorisation (in other words, a Simple boundary) will split the the context-space into two domains along that axis; if both overlay-axes have relatively-Simple categorisations (or movable two-part categorisations, in Complicated style), the overall context-space is split into four regions – which aligns well with the ‘matter’-type categorisation of Simple, Complicated, Complex and Chaotic. Likewise a smooth gradation along both axes pushes the context-space into four regions with Complex or even Chaotic boundaries between them.

Because of this,  a four-region base-map is likely to be the most common and most useful two-dimensional type – hence, we may note, the twf is often shown paired with two-axis overlays. But other layouts are possible and sometimes useful: for example, a pair of tri-value  axes would typically be used to align an eight- or nine-domain primary axis, such as seven-colour plus infra-red and ultra-violet.

The result is a consistent structure for base-maps that are simultaneously bounded and not-bounded, and that describe the whole of a context-space by structured views into that context-space that also acknowledge that the context-space ultimately has no actual structure. Hence the importance and validity of the assertion that even though twf is often shown paired with two-axis overlays, it is not solely a two-axis matrix. The other point, though, is that this indicates that twf is merely one instantiation (or set of instantiations, rather) of a generic class of context-space mappings that has been around and in general use for a lot longer than twf itself.

Hence to avoid further clashes with twf, I suggest that in future we use the generic term context-space mappings to denote base-maps and derivatives that use this type of structure.

Once we’ve cleared that particular road-block, we should be free to concentrate more on practical applications of context-space mapping for whole-of-enterprise architecture, but I’ll leave it there for now. As usual, any constructive comments, ideas and suggestions would be most welcome – over to you, if you would?

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‘

Related:

• ‘Two Cryptic conversations‘

Back to theory again – apologies… – following on from comments on the previous posts, especially ‘On meta-methodology‘.

The aim of this post is to try to create a bit more clarity around the notion of ‘problem-space’ versus ’solution-space’. To do this, I’ll draw on a variety of sources, ranging from dowsing to enterprise-architecture, Sigurd Rinde’s work on ‘barely-repeatable processes’, activity/response-models such as OODA and PDCA, and much more besides.

Will again be long, hence more after the ‘Read more…’ link.

Two key criticisms came up on the previous post on meta-methodology, as you’ll see in the comments. One was from Sally Bean:

One thing that does slightly jar with me in this particular posting, and elsewhere, is the use of the words problem and solution, which both suggest bounded spaces, when the reality is often much fuzzier, especially in the unordered domains. I strongly share the views that David Gurteen expressed in this recent comment on his website. http://www.gurteen.com/gurteen/gurteen.nsf/id/no-solutions. And of course, Ackoff used to talk about messes, rather than problems.

The other was from Paul Jansen:

I would like to ‘add a dimension’ (if you like) that I feel(!) is an intrinsic part of the quest at hand (meta-methodology). I speak of the relationship between the ‘interventionist’ and ‘the subject’. As it is with the inter effecting aspects of diagnosis and intervention, so it is at least equally true for the ‘performing artist’ and ‘his subject’ for either diagnosis or intervention. As the quote goes: “we find mostly what we look for”, and this is very true, it must be that the ‘consultant’ starts to effect the object of his attention immediately, a process which is part of what we should call ‘meta-context’.
[T]hat thought … has been lingering for some time now since a great deal of the interchanges so far seem to imply ‘no relationship whatsoever’ between the person doing the diagnosing and interventions and his ‘object’ of these.

To summarise, these are about the dangers of any purported separation between ‘problem’ and ’solution‘, and between ’subject/object’ and ‘observer’.

What I’m suggesting, I suppose, is that yes, those separations are artificial, but we do need them in order to able to respond appropriately within a given context (hence my re-framing of ‘responsibility’ as ‘response-ability’).

In essence, this is like the now fairly old physics-problem of “Is light waves or particles?”. The short answer is “Yes, therefore no”, which isn’t very helpful.  :-) In a science, this kind of inherent uncertainty can be a serious problem; but n a technology, we can choose to view light as waves, or as particles. Even though the two views are inherently incompatible at the quantum-level, both views are functionally ‘true’, therefore potentially useful: to use the physics-terminology of the time (Heisenberg? Schrodinger?), we “collapse the wave-function” according to perceived need. In other words, we use an artificial separation – though we do need to know and remember that the separation is not actually real.

John Boyd’s OODA (Observe / Orient / Decide / Act) model is useful here. The first phase is to observe what we see as ‘reality’. The catch here, as Paul Jansen implies above, is what I’ve elsewhere termed ‘Gooch’s Paradox’, after the psychologist Stan Gooch: “things have not only to be seen to be believed, but also have to be believed to be seen’. The result is that much of ‘observe / orient’ is an iterative process in itself, driven in part by culture, as John Boyd also notes, in a quote in the Wikipedia article on OODA:

The second O, orientation – as the repository of our genetic heritage, cultural tradition, and previous experiences – is the most important part of the O-O-D-A loop since it shapes the way we observe, the way we decide, the way we act.

This is one key reason why it’s important to provide a multiplicity of ‘views’ into the same nominal space. Some of these views will conflict – and the resulting ‘confusion’ should help to force us to observe more closely, not just the context, but also ourselves as part of that context. To use that previous terminology, we create a space within ourselves to prevent the ‘wave-function’ from collapsing prematurely.

So to adapt Shawn Callahan’s excellent video-summary of Cynefin, we could see the first stage of interpreting the ‘problem-space’ (i.e. ‘reality’) as a quick assessment of how cause/effect seems to work within the context:

And so on, with other views into ‘reality’, and how we perceive that ‘reality’. The process of interpreting ‘problem-space’ and deciding on an appropriate response takes place in what I’ve termed ’solution-space’ – in other words, the ‘Decide’ phase of the OODA loop, or, to use that physics terminology, the period whilst we hold the wave-function ‘uncollapsed’. All of the various cross-maps I’ve described in the previous posts [see the list of links at the end of this post] are tools that we might use within ’solution-space’. Overall, some of the key factors that I see in play within ’solution-space’ can be summarised in yet another cross-map:

Some of the choices we have are driven by the amount of time available before we have to commit to a decision (and subsequent action). The closer we get to real-time, the fewer options we have to reflect, experiment and analyse – which means, in effect, that we’re all but forced to choose between Chaotic or Simple. And if we’re not able to accept ‘chaos’ for what it is, we end up trying to ‘take control’ of something that, by definition, cannot be controlled. Which is not a good idea…

(This is the core of my disagreement with Dave Snowden and others around Cynefin: they’ve done amazing work on bringing the Complex domain closer towards real-time, but to me it still doesn’t seem to make any real use of the Chaotic domain in its own terms. Instead, as Shawn explains in the video, almost the only tactic offered is to ‘take immediate action’ to force it into another domain – which, in the real-time context, would necessarily push us toward the potentially-dangerous over-simplifications of the Simple domain.)

Another key point here is that every possible view of ‘reality’ – the ‘problem-space’ – is an abstraction. (One everyday example is that digital sound-recording is an abstraction of analogue – and there’s always some loss of potentially-important information within that process of abstraction. A long-established adage in systems-thinking is that the only complete model of a system is the system itself: everything else is an abstraction.) The Simple domain provides the most obvious extremes of abstraction; yet although the Chaotic domain is much closer to ‘reality’ in that sense, it’s still necessarily an abstraction of some kind.

In that sense, there can never be a perfect alignment between ‘problem-space’ and ’solution-space’ when we ‘collapse the wave-function’ in the decision immediately before action (and, recursively, in the decisions we take n the nested OODA loops within that action). In short, we never get it right.

The aim of recursive models such as OODA and PDCA is to allow us to iterate closer towards the ‘unachievable ideal’, either within the action (as in OODA) or over a series of actions (as in PDCA). What I’m aiming to do with this notion of ’solution-space’ is to provide a perhaps-better map of what actually happens within  those loops – in other words, to provide a means to map out the ‘orient / decide’ pathways.

Real complexity occurs whenever ’cause’ and ‘effect’ are interdependent – as they are in virtually every ecosystem – and/or whenever we touch a social context – frequently leading to ‘wicked problems‘.  It seems to me that the ‘mid-range’ of such complexity is already well-served  by tools such as Cynefin and the PDCA cycle; yet as with classic physics, those techniques seem to become less useful or usable as we move towards the far extremes:

• the ‘very small‘: a ‘quantum event’ of a single person applying a skill to a single (if sometimes nominally ongoing) real-world event – such as in dowsing, or in Sigurd Rinde’s concept of ‘barely-repeatable process’
• the ‘very large‘: a ‘cosmology’ of an entire conceptual ecosystem – such as in a whole-of-enterprise architecture that applies to the full lifecycle of an enterprise

The ‘run-away-to-another-domain’ tactic implicit here in Cynefin pushes us towards the Simple domain in both of these cases – either as overly-simplified real-time ‘rules’, or excessive large-scale abstractions. So how can we instead hold back against the inherent ‘panic’, and work with the inherent uncertainties of the Chaotic domain? That’s what I’m after here.

The set of ‘disciplines‘ that we described in ‘Disciplines of Dowsing‘ (pp.31-70 in the e-book version) provide one such summary for a specific class of Chaotic-domain skills (i.e. for use in inherently non-repeatable real-time contexts). As I’ve described in earlier posts, I’m also working similar sets for other contexts such as subjective-archaeology, but there’s a lot more that could be done in mainstream business with those same principles – such as sales, or maintenance, or anywhere else that has a high degree of non-repeatability. (Anyone who’s interested in working with me on this, please let me know! )

Right now I’m working more at the ‘very-large’ scale, such as whole-of-enterprise architecture – as documented in some of my books, such as ‘Doing Enterprise Architecture‘ and ‘The Service-Oriented Enterprise‘. The challenge there is not so much about rapid response (as it is in real-time skills) but in the sheer scale and scope of the contexts that need to be included, from the very small – individual details of individual processes – to the very large – interactions with an entire market and milieu over many decades.

In both cases it seems to me that the most important requirement is empathy – in other words, engagement with the context as itself and in its own terms, whilst also maintaining a clear sense of ’self’ so as to be able to move around within the ‘problem-space’ and ’solution-space’ before ‘collapsing the wave-function’ to make practical, real-world decisions. To keep it closer to the Chaotic domain of ’solution-space’, we need to emphasise the ‘values’ end of the ‘truth/values’ decision-making spectrum. Perhaps paradoxically, cross-maps such as those I’ve described in the previous posts seem to help at both of those two extremes of scale, by providing recursive real-time checklists for rapid decision-making, yet also with an inherent breadth and depth of scope that enables a naturally holistic overview of the entirety of a context.

That’s where I’ve come to so far with this, anyway. As usual, any constructive comments, ideas and suggestions would be most welcome – over to you on that?

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‘

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:

• ‘Complexity, chaos and enterprise-architecture‘
• ‘More on chaos and Cynefin‘
• ‘Alternatives to the ‘Cynefin’ term, please?‘
• ‘Solution-space: beyond Cynefin?‘