Cynefin and the Chaotic domain – an update

The first part of this is just a ‘public-service announcement’ service for Cynefin aficionados: Dave Snowden has announced that his current process of updating Cynefin has now extended to include a rethink of the Chaotic domain:

RT @snowded: 2 months playing with drawings & ready with subdomain model of the chaotic domain of #Cynefin http://t.co/tgXVSKAk #agile #entarch

The next part of this is where it gets very hard for me. These days I generally try to avoid having anything directly to do with Cynefin or Snowden, and it’s fairly unusual for me to read anything on his blog at Cognitive Edge: when I do find myself there from following some link, it’s more often by accident than by intent. (Interestingly, Snowden does visit this blog quite often: six distinct visits from three different IP-addresses so far this month, according to my weblog-stats.) But on this occasion the Tweet above specifically addresses the crux-point of our area of disagreement – the ‘Chaotic’ domain – and the hashtags also explicitly place it as an item-of interest for Agile development and for enterprise-architecture – both of which are key concerns for my own work. So whether I like it or not, it’s clear that this is one circumstance where I do need to review what’s being said.

I’ve been there once now to take a brief glance at the article – enough to confirm that, yes, since it does claim to be relevant to enterprise-architecture, I do need to go back there to do a proper in-depth review. Before I do that, though, I need to set out what I understand as ‘the Chaotic domain’ in enterprise-architecture – because that’s what I’ll use as my key reference-point in that review.

The start-point, obviously, is that I need to specify what I mean by ‘chaos’ in this sense. In terms of formal theory, I use themes from several definitions, some mathematical, some from quantum-theory and the like:

• discrete event, viewed and/or experienced in isolation from any other (and hence outside of any event-relation notions of ’cause’ or ‘effect’)
• in relation to other events, may or does exhibit chaotic dynamics – sensitivity to initial conditions, topological mixing and ‘orbital density’ (or contextual equivalent)
• even if apparently deterministic, the behaviour is non-linear and/or not inherently predictable
• evidences quantum-like step-change, with probabilistic, chaotic or true-random transitions

A routine example of the latter in business is the decision to buy. Mathematically-speaking, it’s a true chaotic-type state-transition, often exhibiting back-and-forth uncertainty before settling into a seemingly stable state, very similar to the state-transition process that occurs during inversions of the Earth’s magnetic poles.

Note that this relates primarily to single events, events viewed in isolation from all others: hence this is not the same as complexity-theory, which always deals with related events – or more accurately, the process of deriving perceived-relationships between events, and thence a prediction or prognosis for overall collective outcomes. However, there is rarely a simple cut-off between complexity and chaotic-systems: in quantum-physics, for example, the effects of Heisenberg-uncertainty – we can tell where something is but not where it’s going, or where it’s going but not where it is – are essentially a statistical matter, and fade out of the picture above around ten quanta or so, where there can be enough events on which to base a statistical trend.

Outside of formal theory, probably the simplest way to illustrate this would be a set of business-views in relation to what complexity-theory might describe as an ‘outlier’. I’ll use the Cynefin terminology here, but also cross-link it to the SCAN frame:

In a Simple view in business – such as in the classic Taylorist ‘work-instruction’ , there’s no such thing as an ‘outlier’: whatever-it-is is either in scope for me, or it isn’t. If it isn’t in scope, there might be something in my instructions to tell me where to escalate it to, but either way it’s not my problem: let someone else worry about it. End of story.

In a Complicated view in business – such as in conventional analysis – an ‘outlier’ is something way off in the statistical wilderness. It’s too small to matter: we can safely ignore it for now. We assume, anyway.

In a Complex (‘Ambiguous’) view of business, we’d take the existence of an outlier a lot more seriously. As Chris Arkenburg puts it:

Outliers are the unexpected events, the Black Swans that come out of nowhere and blow expectations out of the water.

That’s where tools such as Cynefin and Snowden’s ‘Sensemaker’ software come into play. And such tools can play an important role in that kind of assessment, too: I don’t have any doubts about that.

Yet in a Chaotic (‘Not-known’) view of business – the kind of world that actually exists on the front-line, or in general-practice in medicine, or in any customer-facing area of work – everything is an ‘outlier’: the moment we hit any kind of uniqueness, it literally cannot be anything else.

Note, though, that this is not a ‘simplistic categorisation tool‘: it’s a set of views into a context, not a set of categories for a context – and that distinction is extremely important here. Almost every real-world business-context will contain elements that are Simple, Complicated, Complex and Chaotic – and a dynamically-changing mix of those elements, too. What this kind of frame does do is to help us identify which types of response-mechanisms within our design-palette will align best with each of these categories, and hence allow us to design ‘solutions’ – and links between ‘solutions’ – that can handle the required mix and dynamic range at the operations-level.

Simple and Complicated are already well-served by Taylorism and the like, and by most conventional types of IT-systems. The Complex domain is perhaps less well-supported at present, but we’re seeing much more use of complexity-based ‘solutions’ such as pattern-matching, fuzzy-logics, probabilistics to identify criticality of outliers, blurry ‘Big-Data’, and so on. What we don’t have much of as yet is explicit, systematic techniques to deal with Chaotic contexts such as ‘market-of-one’, or any other form of inherent-uniqueness. And yet all real-world business-contexts have some level of inherent-uniqueness at the point of contact – for which current business-theory offers us almost no support at all. Which is a problem… – and especially so for enterprise-architectures, which must address the full range of real-world business needs.

The key point I look at here is this: at the moment of action, there is only this item, right here, right now – it is itself, distinct, unique. Either side of that moment of action – in preparation for action, and in follow-up to action – non-uniqueness can exist; cause-and-effect can exist, or at least be perceived or derived; Complex, Complicated and Simple can make sense again. But at the point of action, no: there is only uniqueness, and there is neither ’cause’ nor ‘effect’ – there is only is. And at that point of action, there is also no-one else, no Other to do it for me: whatever this ‘it’ is, right here, right now, it is my responsibility – my ‘response-ability‘ – to resolve and complete that action. That’s the Chaotic, in the strict formal sense of the term; and if we get it wrong, and try to misapply the Simple, the Complicated or the Complex into this type of context in our architectures, what we get instead is ‘chaotic’ in the colloquial sense of the term.

To me, the only real purpose of a sensemaking framework is to support decision-making for the respective arena of action. And at the exact point of action, real business is Chaotic – always. At the very least, it will always include some elements of the Chaotic. Which means that in our architectures we need to treat it as Chaotic – and not as anything else. If we fail to do that, then by definition we will create architectures that are guaranteed to fail in inherently-‘unpredictable’ ways, and riddled with wicked-problems that can often lead, all too literally, to a ‘mess’ of truly epic proportions. In short, treating the Chaotic as anything other than Chaotic is not a good idea…

That’s the point I’ve been trying to make all along, in my critiques of Cynefin and the like: to me it’s always seemed to be trying to treat the Chaotic solely as a subsidiary ‘feed’ into the Complex, or co-opt the Chaotic into the Complex in ways where by definition it cannot fit – and despite various protestations to the contrary, I’ve not yet seen anything that has convinced me otherwise. In effect, Cynefin to date has to me seemed ‘Complex-centric’ in very much the same sense that TOGAF is IT-centric – and with much the same risks for enterprise-architectures. I first wrote about this way back in June 2008 – more than four years ago now – and have been struggling with it ever since; it’s why, for quite a while now, that I’ve had to recommend that Cynefin should not be used in enterprise-architecture. Again, this is for exactly the same kind of reasons why I still question the use of TOGAF for anything other than IT-architecture: it’s because the respective ‘whatever-centrism’ presents a ‘term-hijack’ that creates very real risks for whole-enterprise architectures.

So that’s the background from which I’m approaching this review of the Cynefin update on the Chaotic domain. I’m hoping things have changed: but right now I don’t know. Best leave it at that until after the review.