Tom Graves / Tetradian

History seems to be all in vogue in Cynefin circles at present. On one side, for example, there’s Cynthia Kurtz – the too-often-unacknowledged co-creator of Cynefin, and originator of some of its key concepts such as the crucial distinctions between ‘order’ and ‘unorder’ – who’s recently written some truly excellent posts on her past involvement with Cynefin and her subsequent development of those ideas into her current Confluence model. Very strongly recommended.

On another side, Dave Snowden has been busily documenting his own ‘history of Cynefin’, in a series of blog-posts with that title. In Part 4, for example, I’m very glad to see that he does indeed describe Cynthia’s crucial role in the development of Cynefin. And in Part 5, bizarrely, he uses my own work on context-space mapping – uncredited, unacknowledged, and, of course, completely out of context – as his sole example of an ‘illegitimate approach’ to usage of Cynefin concepts. I suppose I ought to be flattered at this singular censure, though to use Dave’s own words, “I don’t know whether to laugh or cry” at this, because all it really demonstrates is his continuing inability to get the point. Oh well…

(Unlike Dave, I’ve never laid claim to the mantle of ‘scientist’. I’m a toolmaker, a creator of conceptual tools: my real field is metamethodology, the methodologies for creating methodologies to create context-specific methods like those in Cynefin – and although there’s always a large theoretical component to that work, the core focus is always on practice, not theory. In a classic Two Cultures sense, might the real problem here be that we’re operating in different metaphoric ‘worlds’? No matter: it is what it is (or isn’t), and that’s that.)

The point that Dave seems to be missing is that he’s still using entirely the wrong criteria to assess what context-space mapping is all about. None of it is about ‘truth’ in the formal scientific sense: it’s much more about ‘mashups’, about the quest for something useful, that has value in a given context – which is a fundamentally different concern. To use one example he so pointedly dismisses in his ‘History’, if we were to merge the Cynefin categorisation with the classic ‘data, information, knowledge, wisdom’ stack, and claim that it was somehow ‘true’, that would make indeed no sense at all: if I’d actually done that, Dave’s critique about ‘illegitimacy’ would indeed be valid. But the whole point here is that in context-space mapping and many other related techniques – such as the venerable SWOT – we intentionally create crossmaps with  nominal-’mismatches’ of that type, and use the resultant cognitive-dissonance to trigger new ways of looking at a context. Mistaken notions of ‘truth’ or ‘legitimacy’ simply get in the way of this process: the legitimacy is determined from the discipline and precision of process, not from an ultimately-arbitrary ‘scientific lineage’.

It’s possible to argue that I continued to associate what’s now context-space mapping with Cynefin for a little while too long – a month or two, perhaps – beyond the point where it had become probable that their paths had diverged too much to make sense. It’s a common enough mistake, though, and perhaps a less reprehensible one than simply renaming someone else’s work as one’s own, without any actual difference in model. (Is acknowledging influence a greater ‘scientific crime’ than denying it? – I honestly don’t know.)

There’s also the blunt reality that every ‘new’ model is sort-of ‘illegitimate’ – Cynefin included, as Dave makes clear in his history – in the sense that it’s a kind of ‘bastard child’ of many different ideas coming together in unexpected ways. For context-space mapping, I’ll freely admit that the overall method and model each have many different ‘parents’, some of which I’ve long since forgotten and some I may never even have known. Yet that’s true for the work of most of us, I’m sure.

So in the current spirit of exploring the history of our respective models, I’ll point to a key influence behind context-space mapping, which came up in several different forms, most of them predating my involvement in Cynefin by several decades.

Read more…

After yet more aggressive unpleasantness and put-downs over my attempts to resolve ‘the Cynefin problem’ in enterprise-architecture, I think I may have at last found the real source of the repeated miscommunications that have taken place.

The clue comes from a Tweet by Richard Veryard:

#entarch Can’t judge “fit” btwn two frameworks from within either framework, you need a metaframework (shudder).

The problem seems to be this:

• Cynefin is a framework – a model and a collection of related practices.
• It is also a metaframework, in a somewhat limited sense of ‘meta’, in that the framework and the related practices are purported to be generic and may be applied in any discipline.
• What I’ve been describing throughout these posts is a usage of the ‘Cynefin categorisation’ (Simple, Complicated, etc) – i.e. the content of the model, without specific incorporation of the related practices. (I have been explicit all along that this is what I’ve been doing, but that point seems to have been missed. )
• This usage of the Cynefin categorisation is actually the expression of a metaframework – not a framework itself, but a ‘framework to define frameworks’. The metaframework is based on systems-theory principles, including themes such as rotation (checklists etc), reciprocation and resonance (as in ‘hard-systems’ theory etc), and recursion and resonance (as in ‘soft-systems’ theory etc), and in this specific ‘Cynefin-like’ instance uses the ‘Cynefin categorisation’ as its base-frame, for cross-comparison with other matching cross-maps for the purpose of layered sensemaking. The internal structure and foundation is thus significantly different from that used in the Cynefin framework – and at no point have I made any claim that they are the same.
• One of the key points above – as stated repeatedly in all of the posts – is that this ‘Cynefin-like’ metaframework is not ‘the Cynefin framework’: it merely uses the ‘Cynefin categorisation’ as its base-frame. Multiple ‘cross-map’ frames are then applied to the context: cross-maps from the original Cynefin model (e.g. ‘probe > sense > respond’ etc) might be used, but so might many, many others – none of which ‘are’ Cynefin. The various cross-maps are highly likely to deliver sensemaking interpretations that are different from those that would be achieved by using Cynefin alone – in fact the whole point is that it does deliver different results – and, conversely, any attempt to interpret the results solely in Cynefin terms will often make no apparent sense. It is not Cynefin – attempts to interpret it as such, or critique the results as such, are essentially operating from premises which do not apply in that context, and are inherently invalid for that purpose.
• The usage of the ‘Cynefin categorisation’ as a base-map in this way – as a metaframework – is merely one instantiation of a whole class of metaframeworks that use other key models or frameworks as base-maps. Other base-maps for such metaframeworks include extended-Zachman, Five Elements, the tetradian four-dimensions, OODA, PDCA and so on. (Some of those base-maps might use the Cynefin-categorisation as a cross-map on their own base-map – which will cause even more confusion if someone mistakenly interprets this usage of the cross-map ‘as’ Cynefin.)
• The class of metaframeworks is defined by a metametaframework, referred to as ‘context-space mapping’.
• Trying to interpret a framework (such as a single instance of a base-map/cross-map combination) from another framework (such as Cynefin) is essentially meaningless, exactly as Richard Veryard indicates in his Tweet above – the underlying premises won’t line up, so there’s no sensible or meaningful way to do a comparison between them.
• Trying to interpret a metaframework (use of the Cynefin-categorisation as a base-map in context-space mapping) in terms of a framework (Cynefin) by definition will make no sense – they’re functionally different as well as different in their premises.
• Trying to interpret a metametaframework (context-space mapping) in terms of a framework (Cynefin) will really make no sense.
• Unfortunately, all of this meaningless misinterpretation does seem to be exactly what’s happened here.

Which is odd, because such meta-relationships are not unusual: for example, every enterprise-architect is familiar with the relationship between models (e.g. UML models), metamodels (e.g. UML itself) and metametamodels (e.g. MOF, of which UML is one instantiation). Yet from the above it does seem that the main basis for all of these attacks comes down to one key person failing to understand these rather important distinctions about meta-layering.

Oh well. But I do just hope that this will at last dispose of those utterly pointless arguments, anyway?

There’s a core theme that reaches right to the heart of every enterprise-architecture: what is the appropriate tradeoff between sameness versus uniqueness?

The classic Taylorist solution has been to emphasise extreme sameness: to force everything – and everyone – to be the same, because it keeps things simple, controllable and easily replicable. But we now know that it’s too simple to work well with the real complexities of the real world. In fact it only ‘works’ as long as we can maintain the delusion that it does work: and whenever it fails – which eventually it always does – there’s a tendency to collapse into complete chaos. Which is not much of a ‘solution’ at all.

Yet to focus only on uniqueness all but takes us back to a pre-industrial age where everything is custom-made, everything is different, nothing is actually designed to work with anything else, there are no possible economies of scale, and no certain means to communicate with each other – all of which would seem to be the antithesis of architecture. Which is likewise not a good idea.

Clearly there is an architectural tradeoff there: and hence we need something – some conceptual framework – to help us tackle it.

For at least the past half-decade, and probably longer – see, for example, Andrew Johnston’s 2005 article ‘Architects: Masters of Order and Unorder?‘ – enterprise-architects have turned to Kurtz & Snowden’s Cynefin framework for help on this. For many of us, the Cynefin categorisation of Simple [aka 'Known'], Complicated [aka 'Knowable'], Complex and Chaotic has proven extremely valuable, such as for identifying structural themes and potential problems in conceptual misalignment. One example of the latter, as Dave Snowden has also often pointed out, is the misuse of Simple-domain techniques such as Six Sigma: by definition, these depend on very high degrees of repeatability – literally millions of identical events, in Six Sigma’s case – yet there are frequent attempts to apply them in contexts that have little or no repeatability (‘Complex’ or ‘Chaotic’ respectively, in Cynefin terms), which makes no sense at all.

Beyond that basic categorisation, though, attempting to use Cynefin in enterprise-architecture can itself be problematic, particularly where we need to tackle inherent uniqueness. The explicit focus of Cynefin, and Snowden’s Cognitive Edge consultancy, is the application of techniques derived from complexity-science to inherently-complex areas such as policy. (Which, from a cross-map of Cynefin to the ISO9000 quality-standard ‘stack’, is exactly what we should expect: ‘Complex’ maps to the ISO9000 ‘Policy’ layer, in the same way that ‘Simple’ maps to ISO9000′s ‘Work Instruction’.) Yet whilst Cynefin uses the sciences to tackle complexity, what we also need in enterprise-architecture is some means to use complexity to tackle ‘chaotic’ uniqueness – which is not the same at all. Therein lie some serious problems – and some potentially-serious mistakes – if we try to re-use Cynefin concepts in contexts for which it was not designed.

I’ll admit that I’ve probably made some of those mistakes myself. Over the past couple of years I’ve written a number of articles on Cynefin on enterprise-architectures, which made a lot of practical sense to many people, but unfortunately also led to some extremely unpleasant arguments that I have no wish to revisit. What’s become clear to me over the past few months is that the beguiling simplicity of the Cynefin categorisation can blind us to the fact that although its descriptions of the Complex and Complicated domains are essentially the same as we would use for context-space mapping in enterprise-architectures, its definitions and usage of the Chaotic and Simple domains are fundamentally different to those that are needed to tackle uniqueness and sameness in architecture. It’s like comparing a cross-head screwdriver with a flat-head one: at a cursory glance they may seem to be the same, and it’s clear that they are related in the sense that they have similar functions – but in practice they’re not interchangeable, and trying to use them as such will cause a lot of frustration and possibly a lot of damage too. Not a good idea.

So I’d like here to explore what aspects of Cynefin can be used in enterprise-architectures, how and why and where it should not be used, and what we could use as an alternative in those contexts. [I perhaps need to emphasise here that this is not a critique about Cynefin itself, but solely about certain (mis-)uses of Cynefin in enterprise-architecture.]

This again will need to be quite long – apologies – but at least this time there’ll be a fair number of diagrams to break the verbiage into more manageable chunks.

Read more…

(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?‘