Tom Graves

(This series of posts explores a concept of ‘problem-space’ versus ’solution-space’ which in part demonstrates alternative uses and interpretations of the Simple / Complicated / Complex / Chaotic categorisation originally described in the Cynefin diagram. It must be emphasised that this is not about the Cynefin Framework; for details on Cynefin, please contact Cognitive Edge.)

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.)

Read more…

As can be seen from the comments to the previous post, the demands that we find another name for this framework-that-has-no-name have become increasingly strident.

Various urgent online and in-person conversations have ensued. The only directly-meaningful name we came up with was ‘solution-space mapping‘, but several people have disagreed with that, and in any case there is already a well-established usage of the acronym ‘SSM’ in this context, namely Checkland et al’s Soft Systems Methodology.

There’s a long-standing software tradition of assigning arbitrary names as working-titles for projects. Someone suggested ‘Eric’, which was a name they’d used when developing an IT system for an airline, and which reminded me of a nonsense-phrase I’ve often used, that “anything unknown is called Fred”.

But even an arbitrary proper-name seems too concrete for something that is necessarily abstract and, as a name, necessarily temporary. We couldn’t think of any meaningful acronym, so we played with sounds for a while, until someone came up with this:

tinc

It’s the sound of the penny dropping, as someone ‘gets it’; the small bright sound that the imaginary light-bulb makes at the ‘Aha!’ moment in solution-space. A quick, recursive echo of a sound. And it’s also a contraction of what this name really is: a temporary inconvenience.

Since it’s clear we’re not even allowed to use the name of the framework that this isn’t in order to describe what it isn’t, we would have to apply the same process to give us a temporary name for that. So we might note that in Welsh the plosive sound ‘toof!’ would be spelt as twf, which should give us a relatively-safe acronym for That Welsh Framework. (’Twf‘ is also the name of the Welsh Language Board website, by the way – “Cymraeg o’r Crud, Two Languages from Day One”.)

So there we have it: tinc, for the framework, and twf, for the-framework-that-it-isn’t. A temporary inconvenience, but it’ll have to do for now.

(This series of posts explores alternate uses of the Simple/ Complicated / Complex / Chaotic categorisation originally described in the Cynefin diagram. This discussion is not about the formal Cynefin Framework; for details on the Cynefin framework proper, please contact Cognitive Edge. The term ‘beyond-Cynefin’ is solely a placeholder to indicate this separation of concerns.)

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.

Read more…

(This is part of an ongoing series that explores alternate uses of a generic conceptual categorisation originally described in the well-known Cynefin diagram. This discussion is not about the formal Cynefin Framework; for details on the definition and use of the Cynefin framework proper, please contact Dave Snowden at Cognitive Edge. The term ‘beyond-Cynefin’ is here used solely as a placeholder to indicate this separation of interests.)

Here’s another collection of ‘Cynefin-like’ cross-maps that I’ve found useful for sensemaking in enterprise-architecture and related work:

• ISO-9000 quality-model
• Skill-levels
• Automated versus manual processes
• Asset-types
• Data, information, knowledge, wisdom

More details after the ‘Read more…’ link.

Read more…

(This is part of an ongoing series that explores alternate uses of a generic conceptual categorisation originally described in the well-known Cynefin diagram. This discussion is not about the formal Cynefin Framework; for details on the definition and use of the Cynefin framework proper, please contact Dave Snowden at Cognitive Edge. The term ‘beyond-Cynefin’ is here used solely as a placeholder to indicate this separation of interests.)

Another collection of ‘Cynefin-like’ cross-maps that I’ve found useful in various aspects of my enterprise-architecture work:

• Repeatability and ‘truth’
• Marketing versus sales
• The ‘Plan / Do / Check / Act’ cycle

More details after the ‘Read more…’ link.

Read more…

(This is part of an ongoing series that explores alternate uses of a generic conceptual categorisation originally described in the well-known Cynefin diagram. It should be emphasised that this discussion is not about the Cynefin Framework, which is a distinct body of practices based on scientific research. For details on the definition and use of the Cynefin framework proper, please contact Dave Snowden at Cognitive Edge. As this broader usage of the categorisation does not yet have a specific name, the term ‘beyond-Cynefin’ is here used solely as a temporary placeholder to indicate this separation of interests.)

‘Cynefin-like’ cross-maps

I first started using what we could describe as ‘Cynefin-like’ models several decades ago, such as in my book Inventing Reality (first published 1986, current print-edition available here). I’ve found them immensely valuable in a very wide range of applications, especially in disciplines such as enterprise-architecture that necessarily cover the entire scope of a context. The key to its usefulness is that the model’s categorisation provides a consistent base-map for all manner of cross-maps, each of which provides new insights about the context.

Typical characteristics of a ‘Cynefin-style’ base-map include:

• universality: the model purports to cover the entire scope of a given context
• sensemaking: the purpose of the model is to guide sensemaking and decision-support, rather than (for example) design and implementation of a specific ’solution’
• simple partitioning: the model divides the context into a small number (typically 4-5) of regions or ‘domains’ (e.g. the Cynefin set of ‘Simple’, ‘Complicated’, ‘Complex’ and ‘Chaotic’), and often including a ‘none-of-the-above’ region (e.g. the Cynefin central region of ‘Disorder’)
• fluid boundaries: the boundaries between regions are not rigidly fixed (as they are in e.g. a two-axis matrix), and may be allowed to move, blur and/or be somewhat porous
• usage-dependent layout: the layout of the model may not be semantically significant (as it is in e.g. a two-axis matrix) – layouts are often two-dimensional, but may be single-dimension horizontal or vertical, or multi-dimensional such as the four-axis/three-dimension tetradian

(More after the ‘Read more…’ link.)

Read more…

(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:

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

The previous posts on ‘chaos and Cynefin’ were intended to contribute to an ongoing debate about how to use concepts from the published Cynefin framework and the like, and particularly to underpin a systematic exploration of what many Cynefin aficionados would describe as the ‘Chaotic domain’. It’s evident that there’s a real perceived need there, because overall I’ve so far had several hundred reads, several dozen re-Tweets (particularly via knowledge-management thought-leader David Gurteen and management-consultant Paul Jansen, for which many thanks), and a lot of constructive comments and feedback – all of which have been very helpful.

Unfortunately, as can be seen from his comments to those posts, one person who was definitely not happy about such ideas was the originator of Cynefin, Dave Snowden. So there’s evidently a major problem for us there.

What is clear is that, whether Dave likes it or not, a substantial community already uses Cynefin concepts and Cynefin terminology to describe a kind of meta-methodological ’solution-space’ within which various methods, methodologies and tactics can be situated, and their respective appropriateness for specific contexts can be assessed. What’s also clear is that, as far as Dave is concerned, we are no longer permitted to use the term ‘Cynefin’ for this ‘framework-that-occupies-much-the-same-conceptual-space-as-Cynefin’: we do need to find an alternative term for this.

In short, to describe that ’solution-space’, it seems we now need to move beyond Cynefin.

To do that, we need to identify:

• the role and purpose of this ‘not-Cynefin framework’
• how it draws from the published Cynefin framework and/or common usages of that framework
• how it extends and/or differs from the published Cynefin framework
• summarise how this framework would be used in practice

Once we’ve done that, we can perhaps start looking for an appropriate alternative term to describe it.

This is again going to be long, so I’ll stop here for a moment with a ‘Read more…’ link.

Read more…

As may be seen from his comments to my previous posts on ‘Cynefin and chaos’, Dave Snowden has expressed extreme displeasure at my/our usage of the term ‘Cynefin’ to describe the solution-space nominally described by the Cynefin framework.

Anyone have any suggestions for an alternate term that could be used for this purpose, please?

Many thanks.

Another ‘exploratory’, following on from the previous post on ‘Complexity, Chaos and Enterprise Architecture‘, in terms of the Cynefin framework, and again developing out of Dave Snowden’s excellent webinar on complexity and ‘abductive reasoning’.

Cynefin framework (original (c) Dave Snowden / Cognitive-Edge c.2003)

Cynefin is probably one of the most useful conceptual tools that I hold in my ‘consultant’s toolkit’. It is an enormously powerful and enlightening framework to understand the relationships between the simple, the complicated and the complex, and to understand why long-proven approaches such as Taylorism and Six Sigma can sometimes (or often, these days) go spectacularly wrong.

Yet for several years now – in fact pretty much since I first encountered Cynefin – I’ve been concerned that there’s been very little attention paid to the role of the Chaotic domain. So that’s the theme I want to tackle here: how may we reclaim the Chaotic, to make Cynefin more complete?

(I’d better say upfront that there’ll be a fair amount here that Dave and others may disagree with, sometimes quite vehemently – and that’s okay, because this is definitely a ‘work in progress’, and probably with gaping holes in the reasoning in places. I need that critique if this is going to work in practice. In no way do I consider that any of the other work in Cynefin is somehow ‘wrong’ – particularly not the work that Dave and others have been doing in the Complex space, which I regard as crucially important in business and elsewhere. All I’m suggesting here is that perhaps we need to approach the Chaotic domain with the same degree of discipline as we do with the others – and not simply ‘run away’ to the Simple or the Complex as soon as we hit the Chaotic, which is about all that standard Cynefin offers at the moment.)

This one will again be long (my apologies…), but should be useful to anyone who’s familiar with Cynefin, or has any practical concerns about how to handle inherent uncertainties in business and elsewhere. More after the ‘Read more…’ link, anyway.

Read more…