“I don’t understand the recursion you speak of and the real time nature of decision making and how that is different from ‘considered’ decision making.”

I’ll deal with the easy bit first: real-time versus ‘considered’. Let’s use a really simple (and, at present, topical) example: New Year’s Resolutions.

• Did you make any New Year’s Resolutions? If you did, that’s a ‘considered’ decision, at some distance from the point of action – an intent.
• Assuming you did make a New Year’s Resolution, did you actually keep to it, in terms of what you actually do and did? – because that’s a real-time decision.

Given the above, notice how well (or not) the ‘considered’ decision-making lines up with the actual decisions made at the point of action. Overall, that’s an important part of enterprise-effectiveness. That’s what I’ve been working on, with the SCAN posts and the like.

[There's also how review-processes such as PDCA and After Action Review etc link up with all of this: how the review of what we intend versus what we actually did is used to challenge and re-align the linkage between what we intend and what we do next time. If there is a 'next time', of course: it gets even trickier if there isn't... ]

The other point: recursion. For this context, recursion occurs when we use a framework on itself, to review or work with or refine itself. Let’s use the just the sensemaking side of the SCAN frame for this, it should (I hope!) be a safe and uncontroversial example.

So, we would say that this frame has four domains:

• Simple
• Complicated
• Ambiguous
• Not-known, None-of-the-above

And the boundaries of those domains are defined by two axes:

• horizontal: modality – true/false on left, uncertain (‘possibility/necessity’) on right
• vertical: distance in time (or time-available-until-irrevocable-decision) – from point-of-action to potentially-infinite time-available

At first glance, that’s a really simple categorisation. Note the word ‘Simple‘.

Then we notice that our Simple categorisation starts to get Complicated. The boundaries between the domains aren’t as fixed as they might at first seem: although there’s a definite ‘bump’ on the horizontal axis (what I’ve termed the ‘Inverse-Einstein test’), it’s actually a continuous spectrum of modality, from predictable to somewhat-variable to a lot of variation to everything inherently-unique with no pattern at all.

[The Inverse-Einstein test: on the 'order' side (Simple/Complicated), if we do the same thing, we expect to get the same result; on the 'unorder' side (Ambiguous/None-of-the-above), if we do the same thing, we may get a different result, or we may need to do different things in order to get the same result.]

And the vertical axis is always a completely continuous spectrum: there is a clear transition somewhere, between the ‘Newtonian’ (Complicated/Ambiguous) and ‘quantum’ (Simple/Not-known) levels, but we can’t define explicitly where it is.

Then our Simple-but-also-Complicated categorisation starts to get Ambiguous as well: we’ll see this especially when we use cross-maps, such as that one about skill-levels, where each skill-level represents a different mix of ‘order’ or ‘unorder’, again with no clear boundaries, and with a fair few emergent-properties arising as well.

And then we recognise also that there are aspects in this Simple-and-Complicated-and-Ambiguous categorisation that are inherently-unique, scattered all the way through everything we’re looking at, with some bits that are definitely Not-known or None-of-the-above. (In fact that’s the whole point of this kind of exploration, trying to make sense of those Not-known items and come to some useful actionable decisions about them.)

And, yes, once we dig deeper, we’ll find that the same kind of pattern recurs at another level, and then deeper again, and so on.

Fractal, self-similar, recursive; Simple, Complicated, Ambiguous, None-of-the-above, all of them weaving through each other, all at the same time.

That’s what I mean by recursion here: the framework used to explore itself, and explore the exploring of itself, and – of course – of what it is itself being used to explore.

Makes sense? I hope?

• destivia: @ebuise @tetradian @richardveryard Never forget a ‘model’ is always only a preliminary version of how we see or want to see reality.

After which, yes, the whole happy ‘passel o’ rogues’ piled in, all in their different ways:

• richardveryard: @destivia @ebuise @tetradian We can only replace a model with a better model, despite what Saint Paul says (1 Corinthians 13).
• ebuise: @destivia @tetradian @richardveryard Nice! In a way, a (coherent) set of principles is a special kind of model… #insight
• richardveryard: @ebuise @destivia @tetradian I have difficulty with the idea that a set of principles is supposed to represent some aspect of reality.
• destivia: @ebuise @tetradian @richardveryard Indeed.
• ebuise: @richardveryard @destivia @tetradian A few hours ago @krismeukens tweeted: “The core of strategy work is discovering the critical factors and designing a way of “coordinating” and “focusing” actions to deal with them.”
• Aren’t principles derived, directly or indirectly, from this proces? And as such related to reality and steering into future realities?
• ebuise: @richardveryard @destivia @tetradian Can’t aspired directionality of the future be related to reality?
• krismeukens: @ebuise (cc @richardveryard @destivia @tetradian) indeed, that is my current thinking
• krismeukens: @tetradian In near-realtime would sensemaking not just be limited to deal with it as either simple/chaotic?  Sense-catorize or just act?

I caught up with the conversation at this point, and given that my name had been invoked right the way through the above – even though I hadn’t been there – I thought I’d better join in:

• tetradian: @ebuise cc @richardveryard @destivia ‘aspired directionality of future’ – agreed: that’s a primary role of principles

And, of course, the ongoing problem with Cynefin had been invoked as well:

• tetradian: @krismeukens Cynefin’s Act>Sense>Respond is inadequate/incomplete – see later part of http://bit.ly/AxCDSB and posts linked from there

I ought to expand that Tweet here, because the above ‘explanation’ suffers from the dread 140-character limit on Twitter. As described in the SCAN posts – perhaps particularly in ‘Comparing SCAN and Cynefin‘ and ‘Belief and faith at the point of action‘ – I would answer ‘Yes’ to Kris Meukens’ question “In near-realtime would sensemaking not just be limited to deal with it as either simple/chaotic?” (‘Chaotic’ being the nearest Cynefin equivalent to what I’ve termed the ‘Not-known/Faith’ domain for sensemaking and decision-making respectively). The point is that in near-real-time, there isn’t time for anything else: in particular, no time to think, hence, no time for Complicated or Complex (the equivalent of the latter described in SCAN as the ‘Ambiguous/Use’ domain).

The catch is that whilst Cynefin’s definition for tactics for the Simple-domain – ‘Sense-Categorise-Respond’ – does match up quite well with what happens on the Simple/Belief side, the defined tactics for the Chaotic side – ‘Act-Sense-Respond’ – for the most part do not line with what actually happens. Or rather, they sort-of-describe one particular type of tactic that can be used in that domain, but in many if not most cases those tactics are exactly what not to do.

More on that in a moment; for now, back to the Twitter-stream:

• tetradian: @krismeukens one-liner: Cynefin is to Chaotic as SixSigma is to Complex: its basic concepts dont match to the needs of the context
• transarchitect: @tetradian @krismeukens True Tom.
• krismeukens: @tetradian @richardveryard I have the impression that often the ‘dynamics’ aspect of cynefin is forgotten http://bit.ly/sXeDBp [PDF]
• tetradian: @krismeukens it’s the ‘dynamics’ of Cynefin that are the problem… for Chaotic, they all consist of ‘running away’… //  Cynefin’s so-called ‘Chaotic’ is domain of uncertainty in real-time action: ‘running away’ is not sustainable/viable tactic…

This obviously needs some further explanation, so we’ll go to the original source as pointed in Kris Meukens’ link above: Kurtz & Snowden, ’The new dynamics of strategy: Sense-making in a complex and complicated world‘ (2003). The following (presumably (c) Kurtz & Snowden, used here under ‘fair use’) is its Figure 4, ‘Cynefin Dynamics’:

The Simple and Chaotic domains are on the lower-right and lower-left respectively. For now, we’ll ignore the paths that only go between Complex, Complicated and/or Simple (3, 4, 5 and 6), and focus only those that apply at real-time, Simple<->Chaotic (1, 2) and Chaotic<->Complex (7 and the various orange-line paths).

[Path 3 links to Simple, but tends to occur at significant distance from real-time: it's typified by PDCA-style learning-loops and the like.]

Paths 1 ‘Collapse’ and 2 ‘Imposition’ are generally well-known and (fairly)-well-understood. When the expectations of Belief (Simple) don’t match up to reality, there’s often some kind of ‘Collapse’. (That’s actually a failure-mode: it doesn’t describe how we can intentionally move into the ‘Chaotic’ when we acknowledge that the current belief-set doesn’t work.) Once in the Chaotic, and if panic is allowed to take hold, very often there’s an attempt at ‘Imposition’ of order – an assertion of ‘truth’ that pulls the context back into the Simple. (This too is often a failure-mode, by the way – especially if the imposed ‘truth’ likewise doesn’t match up with reality.) That Imposition typically occurs because someone decides to ‘take action’, the Act-Sense-Respond sequence: but what it causes is usually a failure-mode, a collapse back into the over-Simple.

The unnumbered orange-line paths illustrate well what I mean by ‘running away to the Complex domain’. Having arrived in the Chaotic domain, the Act-Sense-Respond tactic is used to elicit and grab at a momentary idea or sense-item and ‘escape’ to the Complex domain, to assess or analyse or analyse what it is or how it could be used. Rather than ‘holding the space’, the Act part of the tactic itself causes the retreat to the Complex. And in doing so, it moves out of real-time: it doesn’t work with the Chaotic as it is.  We might also note that whilst some of the orange pathways dead-end in the Complex domain – for example, ideas that, once assessed, turn out to be unusable – the paths that do ‘succeed’ all end up in the Complicated-domain. In effect, what the Cynefin-dynamics are suggesting here is that the only valid place for new ideas is ultimately in the domain of Complicated ‘control’ – in other words, right back in the same old trap of Taylorism and ‘scientific management’ again.

[This is one of several aspects of Cynefin that make it all too easy to misuse to delude worried business-folk into believing that the the deep complexity and chaos of the real-world can indeed all be subject to 'control'. Still seems to me that there are some real ethical concerns about the structure of Cynefin that really do need to be addressed... but that's just my opinion, of course...]

Path 7 ‘Divergence-Convergence’ indicates a slightly more refined version of the orange-lines paths: iterative rather than ‘one-shot’, but still centred on the Complex-domain, away from real-time action and real-time decision-making. This is what I mean by ‘dipping the toes into the chaos’: it’s a useful and valid way to garner new ideas, yet it still doesn’t work with the Chaotic as it is – like a mouse snatching the cheese, it’s grabbing some tasty morsel and then running away as fast as it can.

What there isn’t in any of the Cynefin-dynamics or other Cynefin descriptions is anything that does work with the actual nature of the Chaotic mode: for example, all the classic tactics for keeping the panic at bay, such as meditation and so on – and also ‘pre-seeding’ the space with principles and the like (which is where we started this long Twitter-conversation ). In fact many of these tactics are the exact inverse of the Cynefin pattern: rather than the “don’t just stand there, do something!” of Act-Sense-Respond, what we often most need is “don’t just do something, stand there”! That’s what I mean when I say that the Cynefin required-tactics are too limited here: Act-Sense-Respond does apply in certain cases, but it only matches up with a small subset of what we need to do (or not-do), and often it is just plain wrong.

Note too that, in terms of the Cynefin-dynamics above, the only pathways that remain in the near-real-time space are the Collapse/Imposition pair – which happen to represent a classic cyclic failure-mode.

In short, the Cynefin-dynamics give us a very incomplete picture and, at best, rather unhelpful picture of decision-dynamics at real-time, and tell us almost nothing about what actually does work in the near-real-time space.

So I hope you can see from this that there are some serious problems here that are just not being addressed in Cynefin: this is serious critique, and certainly not deserving the kind of petty personal putdown-attacks that have been the usual response from that direction. Sigh…

Anyway, back to the Twitter-stream:

• krismeukens: @tetradian it is not exactly running away, it is approaching it for the moment being in a “simpler” way through a reduction of reality
• tetradian: @krismeukens ‘reduction’ – sort of. I’ve gone into this in a lot of detail in my SCAN posts http://bit.ly/wSOAm0 (still a work-in-progress)
• krismeukens: @tetradian categorization versus sensemaking?
• tetradian: @krismeukens categorisation is sensemaking – (mostly Simple-domain sensemaking, in essence, but still a form of sensemaking)
• krismeukens: @tetradian Well yes // But there are 2 things here: 1 categorize in which domain the problem is, the meta-level so to say. 2 how the make sense of it.
• tetradian: @krismeukens ’2 things here’ – yes: recursion. without which Cynefin doesn’t make sense. and which it apparently does not allow. go figure? // ”does not allow” – at least, I’ve been savagely attacked each time I’ve tried to introduce the topic. Your Mileage May Vary etc
• tetradian: @transarchitect addendum to one-liner: Cynefin fits well with Complex, as SixSigma fits well with Simple: problems arise when out of scope
• transarchitect: @tetradian @krismeukens let’s not get too academic about this. C. is just another usable lens. #complexity
• tetradian: @transarchitect yeah, true. it’s just I’ve been attacked so often about trying to make it work that it’s something of a red-rag now…
• transarchitect: @tetradian above understands what’s below; not the other way around. I’ve been defending myself #complexity 2 decades: useless
• tetradian: @transarchitect “defending myself” – my commiserations, good sir… [don't quite agree re 'above/below' - more like mis-intersecting sets?]
• krismeukens: @transarchitect @tetradian yes, lens that is excellent metaphor
• tetradian: @krismeukens @transarchitect “lens” – yes – which brings @richardveryard’s concept/practice of ‘lenscraft’ back into this picture? // problem with Cynefin is that it claims to have full lens-set for all contexts, but does not cover ‘Chaotic’
• krismeukens: @tetradian @transarchitect this must be an attractive discussion as it gains new followers in search of a? date fo?r this w?eekend haha
• tetradian: @krismeukens are there other followers to this? – i thought we were just having a Standard Academic Argument between ourselves…

I had to duck out at that point, to do some promised tech-support for a colleague: we parted, with quick thanks shared all round. But a few other Tweets popped up in the stream somewhat later:

• hjarche: @tetradian just dipping into this discussion but “Act = running away” not an inference I ever made w/ Cynefin // I’ve no time to get too deep on this today but I will dig through all the refs & links later @transarchitect @snowded
• ImaginaryTime: @hjarche @tetradian @transarchitect @snowded Neither did I. Important to note one can also enter Chaotic domain intentionally (innovation).

Innovation is described above: quick summary is that it’s sort-of implied in the Cynefin-dynamics path 7 ‘Divergence-Convergence’, but note that it only links to the Complex: there’s no path described for innovation at real-time, the Simple <-> Chaotic link.

On “Not an inference I ever made w Cynefin” – a valid point, though I hope from this post above that the reasoning behind that inference is now clear. And, in turn, the reasoning why I now strongly recommend to not use Cynefin in its standard form in enterprise-architecture.

Anyway, enough for now: over to you, perhaps?

• simplicableanna: 7 Reasons You Need Architecture Principles http://bit.ly/xqzDkl #entarch

Gerold Kathan retweeted it, and I passed it on again as what I thought of as a useful summary. Nothing unusual there. But then one of my favourite EA thinkers, Richard Veryard, suddenly weighed in, in typically contrarian mood:

• richardveryard: @tetradian @gkathan @simplicableanna Have difficult #entarch decisions ever been resolved by appealing to bland uncontroversial principles?

Which triggered off one of those interesting back-and-forth enterprise-architecture debates:

• EricStephens: @richardveryard @tetradian @gkathan @simplicableanna #entarch Principles provide objectivity for decisions, even if pedestrian in nature
• richardveryard: @EricStephens @tetradian @gkathan @simplicableanna Is there objective evidence that principles improve decision-making? #entarch #groupthink
• chrisdpotts: Yes. #strategy | RT @richardveryard Is there objective evidence that principles improve decision-making? #entarch #groupthink
• EricStephens: @richardveryard @tetradian @gkathan @simplicableanna I have anecdotal stories only. Great question and research topic. Need to define metrix
• tetradian: @richardveryard: @EricStephens @gkathan @simplicableanna Is there objective evidence that principles don’t improve decisionmaking? #entarch
• richardveryard: @tetradian The lack of evidence that something doesn’t work is not a good enough reason to waste time on it.
• tetradian: @richardveryard plenty of anecdotal evidence (eg. I use principles often in my own decisions) – claims of ‘objective’ may be spurious here
• richardveryard: @tetradian I guess there are many popular #entarch beliefs that would be impossible to disprove. #pseudoscience

I would agree there – though it’d be the popular belief in the efficacy or even the possibility of  ’control’ that would be my first pick to question in this sense, with use of principles quite a long way down the list. But never mind – others continued the debate, anyway:

• BakedIdea: @tetradian @richardveryard where i work discussion +agreement on principles is essential part of decision making process… // not sure how youd empirically prove their value though. more, quicker, better decision? no way to measure success
• tetradian: @BakedIdea @richardveryard “no way to measure success” – yes, exactly. (or even ‘non-success’, in many cases)
• leodesousa: @richardveryard @tetradian in the early days of our #entarch practise principles helped us manage complexity – reduced dev platforms 7 to 3
• BakedIdea: @tetradian @richardveryard imo if you view part of #entarch as movin down a funnel of possibility then agreement on principles help movement
• krismeukens: @tetradian (cc @BakedIdea @richardveryard) So we’re actually in the chaos domain? No causality. Just act? Act-Sense-Respond? Mmm #cynefin
• tetradian: @krismeukens (cc @richardveryard @BakedIdea) principles are most use in ‘chaos domain’, as ‘seeds’ to provide equiv. of causality in Simple
• krismeukens: @tetradian (@richardveryard @BakedIdea) ok, makes sense, I’ll think about that.
• tetradian: @krismeukens (@BakedIdea @richardveryard ‘Act-Sense-Respond’ a bit misleading re principles: see http://bit.ly/w5kU1r , http://bit.ly/zQKAWi

I’ll admit that that last point from Kris Meukens about the Cynefin ‘Act-Sense-Respond’ sequence in the ‘Chaotic domain’ is a mild red-rag for me, given that I’ve spent literally years now trying to resolve the consequences of that one subtly-misleading mistake… I’ll agree that the sequence does occur, and is sort-of valid in its own way, as a sort-of method for sensemaking and decision-making in a high-variability context (i.e. ‘chaos’). But in essence that ‘method’ consists of ‘running away’ from the chaos as fast as possible, or preferably never be there at all. Which isn’t really much use for dealing with chaos as it is - and it also kind of defeats the object of the exercise anyway when we need to go into that chaos, intentionally, in order to create new ideas and options.

[For more on this, perhaps take a look at some of the posts on sensemaking with SCAN, such as 'Comparing SCAN and Cynefin', or the posts on belief and faith, decision-making, and the series on linking intent and action (Part 1), (Part 2), (Part 3), (Part 4).]

This is where principles and the like come into the picture, because they provide a means to ‘pre-seed’ the variability, leveraging Gooch’s Paradox that “things not only have to be seen to be believed, they also have to be believed to be seen”. In effect, the principles provide a stabilising anchor in the midst of chaos, reducing the natural tendency to panic and ‘run away’.

The panic-state often triggered by the infinity (or near-infinity) of possibility within a chaos tends to be expressed in the classic adrenalin-responses: fight, flight or freeze.  In practice, the functional purpose of the Cynefin Act-Sense-Respond sequence is to provide a means to shift the response-mode from ‘freeze’ to ‘flight’. What it doesn’t do is allow any option to remain in the chaos-space.

A much more useful approach is to centering-disciplines and the like to keep the panic at bay for as long as practicable, in conjunction with vision, values and more-actionable principles to provide a form of guidance within that space, all of it taking place in real-time.

The Act-Sense-Response sequence is only helpful in a high-variability context where principles are not used, and hence no guidance or ‘pre-seeding’ to re-constrain the variability towards a more useful outcome. As the published dynamics in the Cynefin framework make clear, the real risk of the Act-Sense-Response sequence is a collapse back to over-simplistic concepts of ‘control’; at best, it delivers a rather thin form of iterative sensemaking that kind of ‘dips its toes’ into the chaos and then runs back to the Complex-domain to make sense of what it’s seen – a cumbersome process that really slows things down. Hence, not recommended.

Given all of the above, I still don’t know why Richard Veryard was/is so vehement against the use of principles in real-time sensemaking and decision-making in enterprise-architecture. He didn’t seem to say much in those Tweets, other than that he sort-of regarded them as ‘pseudo-science’, without saying why. No doubt we’ll find out, here or elsewhere? But it seemed a conversation worth recording, anyway – I hope you find it useful!

[Update: later the same day]

Another Tweet came through from Kris Meukens, via Gerold Kathan:

• krismeukens: #principles are invariable inclusive/exclusive statements as a tool to constrain the space for emergence in a complex domain #cynefin

Yes, in Cynefin that’s true, and as far as it goes, I’d agree with it. However, there are a couple of very important points that are glossed over in Cynefin, which to me seem part of the cause for Cynefin’s fundamental flaws in what it labels the ‘Chaotic-domain’.

First, although we might say that “principles are invariable/exclusive statements … to constrain”, that’s not actually how it works in practice: in fact that’s more a Simple-domain true/false concept of principles than a fully-modal Complex-domain one. (Again in my experience, Cynefin’s structure makes it all but impossible to see the recursions that apply here.) Principles are the actionable expression of vision and values, and there’s always a set of trade-offs that we need to make between them – a contextual prioritisation that varies with every context, in line with Requisite Variety and the like. Which means that whilst the principles themselves may purport to be “invariable/exclusive”, the way we use principles is not. That’s a rather important difference.

Second, although Cynefin does work well for ‘considered’ sensemaking (i.e. in what it terms the Complex and Complicated domains), there seems to be no grasp at all in Cynefin that the ‘decision-physics’ change as we approach close to real-time – almost exactly analogous to the shift from Newtonian-physics to quantum-physics at very small scales. (The distinction may not be so obvious with sensemaking, but it’s absolutely crucial in decision-making – summarised by a phrase I used throughout the last series of posts on decision-making, that at the moment of action, no-one has time to think.) Cynefin seems to try to treat the sensemaking/decision-making processes as if they’re exactly the same at ‘considered’ and real-time timescales, which does not work in practice: hence why its handling of the Simple-domain is poor, and its handling of the Chaotic-domain woefully-inadequate.

Unfortunately it’s proved impossible to discuss any of this with Snowden – a fact illustrated all too well in his comments on this website. Since there’s no way to resolve these glaring flaws in the framework, I have, somewhat sadly, had to give up entirely on Cynefin, and restart from scratch. To be frank, I would strongly recommend that others in EA and related disciplines should do the same: useful as Cynefin may be in some other contexts, it’s simply not worth the problems that it creates in ours. Your choice, of course.

]]> http://weblog.tetradian.com/2012/01/13/how-useful-are-principles-in-ea/feed/ 28 http://weblog.tetradian.com/2012/01/10/decision-making-linking-intent-and-action-4/?utm_source=rss&utm_medium=rss&utm_campaign=decision-making-linking-intent-and-action-4 http://weblog.tetradian.com/2012/01/10/decision-making-linking-intent-and-action-4/#comments Tue, 10 Jan 2012 15:07:29 +0000 Tom G http://weblog.tetradian.com/?p=4610 How is it that what we do doesn’t necessarily match up with what we plan to do? How can we best ‘keep to the plan’? Or, alternatively, how do we know how to adapt ‘the plan’ to a changing context? What governance do we need for this? How do we keep everything on-track to intent in this? And what implications does this have for our enterprise-architectures?

What we’ve been looking at in this series of posts is a key architectural concern: at the moment of action, no-one has time to think. Hence to support real-time action, the architecture needs to support the right balance between rules and freeform, between belief and faith, in line with what happens in the real-world context. And it also needs to ensure that we have available within the enterprise the right rules for action when rules do apply, and the right experience to maintain effectiveness whenever the rules don’t apply.

As we saw in previous parts in this series, this implies is that within the architecture we’ll need to include:

• a rethink of ‘command and control as a management-metaphor [see Part 1 of this series]
• services to support each sensemaking/decision-making ‘domain’ within the frame [see Part 2 of this series]
• services to support the ‘vertical’ and ‘horizontal’ paths within the frame [see Part 3 of this series]
• governance (and perhaps also services) to dissuade following ‘diagonal’ paths within the frame

So this is Part 4 of the series, the final part: exploring the architecture of governance – and architecture-governance too – that we need for all of this to work well.

[Those two key reminders again: this is 'work-in-progress'; and all of this is recursive - so you'll likely need to do some work of your own here too.]

Within the architecture, we will need governance and governance-services to cover all of the issues that we’ve seen in the previous parts to this series. This would include guidance and governance on the services that support each of the SCAN sensemaking / decision-making domains and the links between them, and on any changes to those services and facilities.

Governance itself is usually outside of the remit of architecture – or probably should be, even if architecture sometimes ends up being landed with the role by default. A better role for architecture here is to identify what it is that needs governance, what kind of governance it will need, and where in the overall structures and story are the gaps that need to be filled – in other words, the governance to help create and maintain what does not yet exist.

As we’ve seen, the overall themes here that governance would need to cover would include:

• techniques for sensemaking and decision-making at the point of action, across the whole range of modality of possibility and necessity (described in SCAN as a spectrum between Simple <-> Not-known, and between Belief <-> Faith)
• techniques for sensemaking and decision-making at varying distance-from-action – loosely categorised as operational, tactical or strategic – and again across the whole spectra of modality (described in SCAN as between Complicated <-> Ambiguous, and between Assertion <-> Use)
• techniques to bridge across the sensemaking and decision-making at real-time (Simple <-> Not-known, Belief <-> Faith) and at distance-from-action (Complicated <-> Ambiguous, Assertion <-> Use) for operational, tactical and strategic distance-from-action
• improvement-processes that link between techniques at distance-from-action and at real-time action, constrained at distinct levels of modality, from true/false (Complicated <-> Simple, Assertion <->Belief – eg. Six Sigma, Taylorist ‘scientific management‘) to fully-modal (Ambiguous <-> Not-known, Use <-> Faith – eg. OODA, improv)
• processes and techniques to develop skills and competence across the full range of modalities applicable within the context
• validation of, training in and usage of all of such techniques

And as we’ve also seen, the governance would need to maintain a balance across all of these themes:

• theory and experience
• ‘objective’ and ‘subjective’
• ‘science’ and technology
• ‘control’ and trust
• true/false and fully-modal
• organisation and enterprise
• structure and story
• sameness and difference
• ‘best-practice’ and (understanding of) ‘worst-practice’
• ‘sense’ and ‘nonsense‘
• certainty and uncertainty
• caution and agility
• rules (‘the letter of the law’) and principles (‘the spirit of the law’)

Ideally the governance should also cover any applicable management-structures, with a strong emphasis on ‘management as a service‘ rather than as a dysfunction-prone pseudo-hierarchy. At present, though, that’s still likely to be too ‘political’ and problematic for architecture alone to face… – for now, probably best to class it as an architectural-waiver, to be addressed if and when the opportunity should arise.

Decision-physics

There’s a further point that I don’t think has come through clearly enough in the previous parts in this series. This is what we might term ‘decision-physics’, by analogy with mainstream physics.

Mainstream physics has three distinct layers: the very-small, the mid-range, and the very-large.

Most of what we deal with in terms of ‘the laws of physics’ is in the mid-range: Newtonian physics and the like. Everything seems to follow identifiable rules or ‘laws’; classical physics focusses on the direct impacts of those apparent laws, whereas in some cases there are contextual ‘emergent properties’ that arise from interactions between entities – though note that it’s still the same physical-laws beneath those interactions.

Our mainstream ‘decision-physics’ – what I’ve described as ‘considered’ sensemaking and decision-making – likewise seems to make sense across a very broad mid-range, from strategy to tactics to operations. And we see much the same distinction between all-predictable ‘hard-systems’ (Complicated / Assertion, in SCAN) versus complex, iterative, emergent ‘soft-systems’ (Ambiguous / Use) – though note again that’s still ultimately the same ‘laws’ on either side of that spectrum.

Yet some of those key ‘laws’ break down when we move to the far extremes. In cosmological-physics, for example, the speed of light seems to be an absolute constant across almost all timescales – yet not for the first infinitesimal instants of the Big Bang, or for the furthest reaches of time. Somewhere our present physics, there’s presumably some kind of circular self-referential assumption – but we don’t yet have the means to work out what it is.

Much the same applies in our ‘decision-physics’. Most of the time – such as in most enterprise-architecture work – the usual assumptions and decision-methods work well enough. Yet once we move to the scale of the very-large – with longer timescales, for example, or what I’ve termed ‘really-big picture enterprise-architecture‘ – some of those assumptions begin to be more evident, and become much more problematic. When we do have to work at those scales – and some enterprise-architects do so already – then we need to be aware that a somewhat-different decision-physics may apply: for example, conventional notions of ‘possession‘ and the like may no longer make sense.

The certainties of mainstream physics also tend to break down at the scale of the very-small, as we move into quantum-physics and the like. It’s actually the same underlying physics, but all manner of assumptions that we could get away with at the everyday Newtonian scale become visible as assumptions. This applies particularly around certainties versus probabilities, which at the quantum scale gives us seemingly-impossible phenomena such as ‘particles’ that can be in more than one place at the same time. (This also gives us occasional oddities in larger-scale physics, such as in signal-theory, where to guarantee perfect signal-transmission we would need a conductor of infinite size.)

In the same way, many of the assumptions of mainstream ‘considered’ sensemaking and decision-making start to break down once we get at or very close to the moment of action. The key ‘takeaway’ that I hope you get from this multi-part exploration with SCAN is that what happens at the point of action is real: everything else is an abstraction.

And it’s an abstraction that may not have much connection with reality at all. All of so-called ‘rationality’ is an abstraction: hence, for example, why ‘rational-actor theory’ and much of current mainstream economics has been such a disastrous bad-joke, and why ‘control’ is a such a misery-inducing myth in most current forms of business-management.

What we actually have at the point of action are literally-emotive decisions made on belief and faith. Just as quantum-physics underpins the larger-scale Newtonian-physics, all of our abstractions are actually underpinned by real-world emotion – literally, ‘that which moves’.

Thinking is extremely important, of course, because it clarifies intention. But neither thinking nor intention actually do anything on their own: for something to happen, we need to link intention to emotion. Which in most cases also means that we need to link the type of intention to the matching type of emotion-that-drives-action – and likewise match the emotion back to the required intention, to get the maximum effectiveness from expenditure of energy.

[Not every emotion is effective, of course: aggression, panic or 'awfulising' - otherwise known respectively as 'fight, flight or freeze' - can use up a lot of energy without achieving anything useful at all... Likewise the same does also apply to machines and IT-systems, but kind of at one step removed: plenty of motion without emotion as such, it's true, but it's human emotion and human choice that links all of that activity back to intent.]

So at the point of action – the quantum-level of our ‘decision-physics’ – what we actually have is a range of emotion applied across that scale of modality. And it’s here that the Inverse-Einstein Test becomes crucially important, because it provides the key distinction between what I’ve termed ‘belief’ and ‘faith’:

– belief is grounded in certainty, and in the centrality of self

Belief expects the world to work in a specific way: doing the same thing will – or should – lead to the same results. We proceed with the conviction that this is true. An abstract idea – a ‘law of physics’, perhaps, or a more mundane work-instruction or checklist-item – becomes actionable in real-world practice when we attach ourselves to it, as a personal commitment to its ‘truth’.

[Perhaps the starting-point for all belief is faith - as we'll see in a moment - but belief itself provides a stable anchor from which to act.]

For the most part, this how most things are actioned in business and elsewhere: we follow the rules, to get the same results. For the most part, and in many if not most everyday contexts, this is what we want in business and the like: the right beliefs deliver the right results. Yet there are couple of important catches that we need to note here, both of which have their roots in that personal commitment, and both of which are common causes for ineffectiveness and overall failure.

The key to both of these is the Latin word ‘credo’ – literally, ‘I believe’. Note the ‘I’ here: I, me – the commitment of self to the belief. The commitment is what creates the drive to action, power as ‘the ability to do work’. Yet if we shift too far over to a self-centred view, ‘I’ as the centre the world, we risk falling into the social misperception that power is the ability to avoid work: ‘the rules’ are deemed to apply to others, and to drive others’ actions – with those others being viewed as extensions of self that ‘should’ be under our control yet without requiring any actual action or responsibility on our part. Hence those endless ‘shoulds’ – applied to the world in general, to machines and systems, and even more to other people. (‘They should’; ‘everyone ought’; ‘it must’; so many phrases like that – though noticeable is the relative rarity of ‘I should’…) In effect, the emotion shifts away from doing useful action, and toward trying to ‘control’ others instead – a well-proven recipe for wasting all one’s energy in ineffectual anger… There are some real governance-issues here, and some useful tools for this, such as the SEMPER diagnostic I developed some years back.

The other side of this is a classic give-away for dubious discipline in the sciences and elsewhere: getting overly emotional about the ‘truth’ of ideas, theories and beliefs. Belief is emotional, a driver for action; yet in itself, thought is neither emotional nor actionable. So when we see someone getting emotional about ideas, aggressively asserting that their ideas are ‘the truth’ – or, more especially, that someone else’s ideas are ‘wrong’ – it’s not actually about the ideas at all: it’s about that person’s ego, a demand that others’ action should place that person at the centre of their world. This is the basis of ideology, where the ‘truth’ of the belief-structure deemed to be more ‘true’ than the messy complexities of the real-world – and where those who hold that ‘truth’ deem themselves to be ‘better’ than any others, solely because they hold to that ‘truth’. (There’s a nice Freudian pun here: ideology as ‘id-eology’…) Hence, again, why ‘office-politics’ is actually a hugely-important governance-issue in enterprise-architectures.

The key effect of both of these is a disconnect from the real-world: a demand that the world ‘should’ conform to our expectations, and an assertion that the world itself is ‘wrong’ if it fails to conform to those expectations – all often coupled with a daft dependence on circular-proofs and ‘other-blame’. So whilst emotion and ego are essential to get things going, we do need to keep them in their place… hence, again, the need for appropriate governance right down to this level, all the way across the whole enterprise.

– faith is grounded in uncertainty, and in relation to ‘that which is greater than self’

Faith is what happens when we’re in the Not-known – where doing the same thing leads to different results, or to get the same result requires that we do different things. Faith is the emotive mechanism that we use when we don’t know what to do, yet don’t allow ourselves to get caught up in the classic Belief-driven panic-responses of ‘fight, flight or freeze’ – in other words, to use Susan Jeffers‘ phrase, we ‘feel the fear and do it anyway’.

Whenever we come across any context that has some component of Not-known or None-of-the-above, this is what we have to do. Somehow. Some people find this easy; yet for many people, so important is the sense of safety that comes with certainty, that this kind of ‘letting-go’ can be very hard to do… and organisations and organisation-structures that assert the absolute primacy of ‘The Rules’, and deny the inevitability of the Not-known, will make that letting-go that much harder. Hence there are some significant design and governance-issues here for enterprise-architecture.

What doesn’t work well in this space is ‘flailing’ – doing something just for the sake of doing something. Often what’s needed first is the exact inverse of the old adage: “Don’t just do something, stand there!”. We keep the panic at bay – and avoid a fallback to literally-incompetent Belief – by coming to a calm centredness within the space, and (usually metaphorically, though sometimes almost literally) allow the space itself to speak to us, to show us what to do. And at that point, take action – all in real-time.

At the first point of contact – and especially so at the further extremes of modality – this is literally a context of chaos: in principle at least, anything is possible there. That’s the advantage of the Not-known; it is, obviously, also its disadvantage, since any number of things that we don’t want to happen also become equally possible at that point. Hence the need for appropriate tactics that work within the chaos, and provide guidance towards the results that we need.

There are any number of well-known tactics that don’t work well here: for example, ‘take control!’ might be the preference for any Taylorist manager, but in practice all it does is pull us back over to Simple Belief – which is not where the solution to a Not-simple problem is likely to reside… And there are a fair few would-be ‘The Answer’ options that contain fundamental flaws in this regard – a point we’ll come back to later.

Although there’s an element of Schrodinger’s Cat in this, what does seem to work is ‘seeding the chaos’: bringing explicit aims and intentions into the space, yet also allow the space to be what it is. (I’m at some risk of making this sound a bit like “hey, ’60s counterculture, man”, but actually there’s a lot of practical sense in Timothy Leary’s notion of ‘setting and set‘, even within everyday business-contexts.) Hence, in enterprise-architectures, the real importance of ‘setting the scene’ with vision, values and more-actionable principles – all of which provide an anchor of a direction and intent which is ‘greater than self’. ‘Success-stories’ in business – especially those about the grass-roots operational levels – will often revolve around use of such ‘seeding’ to guide context-appropriate action in unexpected circumstances.

Dysfunctional diagonals

One of the key points that came up in the previous post was the importance of having explicit processes and methods to link intent and action, and also to link across the modalities. In SCAN, we would describe these as ‘vertical’ and ‘horizontal’ links:

What we don’t want, though, are ’diagonal’ transitions that link one type of modality at the ‘considered’ level with a different modality at the point of action – such as Assertion misapplied to a Not-known context, or introducing the Ambiguous at the very moment of Belief-based action:

Probably the classic example of this is the myth of ‘control’, typified by the many, many misuses of Taylorism and its descendants and derivatives. For example, Six Sigma makes perfect sense, and is very valuable, when applied to contexts with very low variation; but it doesn’t make sense, and is often dangerously misleading, when attempts are made to apply it to anything other than a context consisting solely of literally millions of nominally-identical events. Business-process reengineering was another infamous example: one of its leading proponents, Michael Hammer, is quoted on the Wikipedia-page as later admitting that:

“I wasn’t smart enough about [the human impact]. I was reflecting my engineering background and was insufficiently appreciative of the human dimension. I’ve learned that’s critical.”

In SCAN terms, each of those is a ‘diagonal’ link of Complicated <-> Not-known – which doesn’t work. We also get the same effect, though, if we take something that does work well as a link of Complicated <-> Simple, and implicitly apply it to a modality beyond its specific true/false constraints. One example that comes to mind here is Roger Sessions‘ work on Simple Iterative Partitions as a method to reduce or eliminate ‘complexity’. It does work extremely well within the relatively-narrow scope of IT-systems themselves – where, in SCAN terms, ‘complexity’ is an undesirable excess of Complicated, leading to system-applications that are not Simple enough to work effectively in real-time action. Yet it’s misleading if we use the same concepts to talk about the application of IT-systems in real-world contexts which, because they’re real-world contexts, frequently must deal with a different type of ‘complexity’ that can’t and sometimes shouldn’t be ‘eliminated’. In effect, that’d be Complicated <-> Simple applying an Assertion that Ambiguous <-> Not-known doesn’t actually exist – taking us straight back to the Taylorist myth of ‘control’, which is not a wise move.

[A quick somewhat-personal note here: Roger has always been a great sparring-partner on this question - perhaps best described on my part by the old phrase "I disagree with every word you say, but I will defend to the death your right to say it"? ]

Going the other direction, we could use the example of Andrew McAfee’s ‘Enterprise 2.0‘, ”the use of emergent social software platforms within companies, or between companies and their partners or customers”. Nothing wrong with that definition itself, but the point here is that the application is about collaboration across the organisation – Ambiguous <-> Not-known, or Use <-> Faith – whereas McAfee placed inordinate emphasis on the technologies instead, or Ambiguous <-> Simple. Ignoring the real complexities of the human-factors was exactly the same mistake that caused so many business-process reengineering projects to fail – a point which was quickly picked up by many practitioners with real-world experience. Surprisingly, McAfee took a long while to acknowledge the problem, eventually coming out with a blog-post ‘It’s not not about the technology‘ – which was true, but still kind of missed the point.

Another example has been a bane of my professional life for the past few years: David Snowden’s Cynefin framework. In SCAN terms, it purports to cover the Ambiguous <-> Not-known link – somewhat like McAfee’s ‘Enterprise 2.0′, but with more emphasis on complexity-theory and social-systems in general rather than in one specific application. The problem here – and despite many, many explanations of this, Snowden still emphatically refuses to acknowledge the problem – is that Cynefin explicitly locks out the linkage to the Not-known / Faith space, for which the nearest equivalent in Cynefin is termed the ‘Chaotic domain’.

The Cynefin framework states that the standard tactic in the Chaotic is ‘Act > Sense > Respond’: which in principle might seem fair enough, except that in many cases – as described above – ‘doing for the sake of doing something‘ is exactly what we should not do as a response to ‘chaos’. Even when action is appropriate, the catch is in what happens next, because the documented ‘Cynefin dynamics’ in effect insist that our only method of dealing with the Chaotic domain is to not be there: our only apparent options are to ‘take’ control’ and collapse back to the Simple domain, or return to ‘considered’ sensemaking in the Complex domain. In SCAN terms, the former is a diagonal-link of Ambiguous <-> Simple, which is clearly not a good idea; the latter is a self-referential loop of Ambiguous <-> Ambiguous, which looks impressive and gives us more and more information about complexity and emergence and the like, yet clearly is not going to go anywhere that’s any actual use. In that sense, Cynefin actively prevents us from applying its insights in real-world practice: it’s valuable for ‘considered’ sensemaking, but literally useless for real-time decision-making. So although Cynefin does claim to cover the whole ‘complexity’ space, the only way to use it in practice is to not use it – which is not exactly helpful…

[There's more on this in other posts here, if you're interested: for example, see 'Using Cynefin in enterprise-architecture' and 'Comparing SCAN and Cynefin'.]

For a final example, we could turn to something that’s perhaps more familiar to many enterprise-architects: Agile software-development. In principle, it’s a good response to the reality that software-development takes place in a world that has a great deal of Not-known about it. And it’s also a response to the ‘traditional’ Taylorist-style Waterfall model of software-development, in which everything would be rigidly defined ‘up front’ without acknowledgement of the reality or probability of changes in the context. In effect, it aims to take the Assertion <-> Belief link on which all conventional IT-systems depend, but apply it via a disciplined Ambiguous <-> Not-known link such that the overall development-process can adapt in near-real-time to changing needs.

That’s the principle: and with experienced, adaptable developers who know what they’re doing and how to work with inherent-uncertainty – in other words, Master skill-level, or Journeyman with a bit of mentoring from Master – it does work well. Unfortunately, it doesn’t work well with developers who don’t have that kind of skill or experience – the Apprentice or, worse, the Trainee. So what we get there instead, all too often, is an undisciplined mess: not enough skill or discipline to work with Faith-style uncertainties and the Faith <-> Belief axis, coupled with a rejection of the formal disciplines demanded by the Complicated / Assertion domain. In other words, not only a problematic ‘diagonal’ of Complicated <-> Not-known, but the worst of both as well. Oops…

And yet somehow we do still need that agility: hence this is one aspect of enterprise-architecture governance where the need for balance is perhaps better-known and better-understood. You’ll find various posts here on what I’ve termed the ‘backbone’ – for example, see ‘Agility needs a backbone‘ and ‘Architecting the enterprise backbone‘; there’s also a good summary by Vikas Hazrati on the InfoQ website, ‘Agile and Architecture Conflict‘. But perhaps I ought to leave the last word here to a software-architect I greatly respect, Simon Brown, who’s frankly brilliant at describing the practice of how to ‘seed the chaos’ to get the best results in agile-development: see his presentations and videos to explore the trade-offs that we need so as to derive an agile-architecture that works, and how to resolve the architecture-challenge of “How much architecture is ‘just enough’?”

—

Okay, that’s it for now. Plenty more to say on all of this, of course, but I’d guess it’s been more than enough already?

And many thanks reading this series: hope it’s been useful? Over to you for any comments and questions, anyway.

What we’ve been looking at in this series of posts is a key architectural concern: at the moment of action, no-one has time to think. Hence to support real-time action, the architecture needs to support the right balance between rules and freeform, belief and faith, in line with what happens in the real-world context. And it also needs to ensure that we have available within the enterprise the right rules for action when rules do apply, and the right experience to maintain effectiveness whenever the rules don’t apply.

As we saw in previous parts in this series, this implies is that within the architecture we’ll need to include:

• a rethink of ‘command and control as a management-metaphor [see Part 1 of this series]
• services to support each sensemaking/decision-making ‘domain’ within the frame [see Part 2 of this series]
• services to support the ‘vertical’ and ‘horizontal’ paths within the frame
• governance (and perhaps also services) to dissuade following ‘diagonal’ paths within the frame

So this is Part 3 of the series: exploring the architecture of how we link together the various domains of sensemaking and decision-making within the enterprise.

[Two key reminders here: this is 'work-in-progress', so expect rough-edges and partly-baked ideas; and although I'll aim to keep the descriptions as simple of possible, note that all of this is recursive, with many intersecting layers of simple and definitely-not-simple - so please do expect to have to do exploratory-work of your own here too.]

On services to support the ‘horizontal’ and ‘vertical’ transitions:

We can summarise this part in terms of the following diagram:

Although sensemaking and decision-making tend to be blurred together within these transitions, there’s usually a clear set of distinctions:

• services that work across the modalities in real-time action
• services that bridge between certainty and uncertainty in planning for action and reflection on action
• services that improve how we apply certainty in action
• services that improve how we work with uncertainty in action

The first two sets of services are primarily ‘horizontal’ across the SCAN frame, linking across the modalities but at a single timescale; the other two sets are primarily ‘vertical’, crossing timescales but on either side of the Inverse-Einstein boundary. There’s obviously enormous scope here, but to keep things simple I’ll stick to a single scenario for each.

For real-time, imagine starting this off with a checklist – a pilot’s pre-take-off check for an aircraft, perhaps.

This gives us a Belief-based structure for decision-making – ‘belief’, because the ‘correct method of working’ is embedded in the sequence of the list. It also gives a Simple true/false method for sensemaking – ‘simple’, because either something checks off against the list, or it doesn’t. After much repetitive practice, using this checklist is ‘second-nature’ to the person doing this work – yet the list is also followed with care and attention.

And because the checklist is followed with care – as ‘the truth’ – the pilot notices that something doesn’t check off correctly. For this example, we’ll assume it’s the radio: there’s no response and no apparent signal from the control-tower.

The moment that we hit something that ‘doesn’t fit’, by definition that throws us across the other side of the SCAN frame, into the Not-known. Notice that for a (very) brief moment, there’s a sense of panic – at which point all the previous training and skill and experience should kick in, together with Faith-based decision-making, to cope with ‘a context larger than that covered by the rules’.

[I've deliberately chosen a fairly minor yet everyday example here: an incorrect radio-setting. For a far less everyday example where the same principles and processes apply, moving back-and-forth across the real-time spectrum, see the section 'Sensemaking in real-time' in the post 'On sensemaking in enterprise-architectures [Part 2]‘.]

In a fully-structured process, there would be another checklist here, specifically to guide sensemaking and then decision-making around what’s (not) happening with the radio – in other words, a tool to pull this back over to the left-side of the frame again, with Simple / Belief. But if the checklist doesn’t exist, or isn’t found, the sensemaking and decision-making remains over on the Not-known / Faith side of the frame.

It’s a high-risk context, so the pilot can’t afford to ignore the problem, and also can’t ‘go on faith’ – the checklist makes it clear that that radio must be working correctly before take-off can be allowed. So notice what happens next: the sensemaking remains on the unorder side, but drops out of real-time. Everything slows down: the pre-take-off process has to stop whilst the pilot carries out a quick series of experiments – in other words, moving somewhat up into the Ambiguous / Use space.

Most of these are Simple true/false tests (is the radio switched on? is the headset connected? is the frequency-setting correct?), which in principle are rule-based, except that the pilot is creating these tests on the spot, from past experience and knowledge of the equipment, rather than following a (non-existent) checklist. One of these tests shows that the frequency has been set for the destination airport rather than this one. The pilot looks up the correct frequency from a reference-chart – another Simple tool – and then changes the channel – a Belief-based decision.

Going back to the original checklist – in other words, now back in real-time again, over on the left-side of the SCAN frame – the pilot re-checks the radio-call: this time it does confirm correctly. The pilot then completes the pre-take-off checklist without any further Not-known interruptions.

From an architecture perspective, notice two points here.

The first is that real-world sensemaking and decision-making at the point of action will often bounce back and forth between Simple / Belief and Not-known / Faith. Most typical business-processes will start over on the Simple / Belief side of the frame – in other words, ‘follow the plan’; yet anything unique, anything different, anything unexpected that doesn’t fit the predetermined ‘the Rules’, will automatically force a transition over to the Not-known / Faith side of the balance. And in most cases, only skill and experience will bring it back over to the Simple side again, to deliver the required result. That’s what skill is, and largely what it’s for.

The second point is that systems which can only work with rules – which in practice includes almost all machines, and most IT-systems – cannot actually cope with that transition into the Not-known. And many if not most real-world contexts do include uncertainties of some kind or other. In such cases – which, again, is most cases – rule-based systems cannot be used to address the whole context: there must be a human skill-based component both to identify when the rule-based system is out of scope, and to take over when it does go out of scope.

The danger here is that IT-systems can sometimes simulate full-context capability from sheer speed applied to a sufficiently large rule-base – which gives the illusion that it can cope with the full context. Fact is that it probably can’t – that uncertainty again – but if we design on the assumption that it can, we’re going to be in real trouble when (not ‘if’) it fails. The architecture needs to take great care on this point: yet the sad fact is that most current architectures – especially IT-centric ones – don’t take anything like enough care with fallbacks and the like here. You Have Been Warned?

For reflection-time – moving back-and-forth across the frame, but at some distance from real-time – what we need are processes that focus on pragmatics and praxis: distilling theory from practice (right-to-left on the SCAN frame), and applying theory to preparation for practice (left-to-right on SCAN) in the unordered-realms.

This is the transitions between what’s described in SCAN as Complicated / Assertion and Ambiguous / Use. What we’re looking for here in the architecture is support at various different timescales – strategic, tactical, operational – for a whole swathe of interactions and trade-offs across the two sides of the frame. As mentioned back on the post ‘Decision-making – belief, fact, theory and practice‘, some of the keywords we’d look for on each side of that balance would include:

• theory versus experience
• ‘objective’ versus ‘subjective’
• ‘science’ versus technology
• ‘control’ versus trust
• true/false versus fully-modal
• organisation versus enterprise
• structure versus story
• sameness versus difference
• ‘best-practice’ versus (understanding of) ‘worst-practice’
• ‘sense’ versus ‘nonsense‘
• certainty versus uncertainty
• rules (‘the letter of the law’) versus principles (‘the spirit of the law’)

For example, this is – or should be – the ‘applied science’ transactions between the assertions of science and the usefulness of technology, each lifting the other to new levels of capability. And we’ll only achieve a real effectiveness via a fully-nuanced ‘both/and’ balance across all of these dimensions, and more – which is what the architecture needs to support.

At present, though, most enterprise-architectures and their subsidiary domain-architectures will be hugely skewed towards the left-side of that balance: theory and ideology, ‘objective’, ‘science’, structures, sameness, ‘sense’, rigid rules, near-random re-use of others’ supposed ‘best-practice’, true/false ‘proof’, abstract organisation (rather than human enterprise), and, above all, certainty and predictability. Yet the end-result of such imbalance is an architecture that is all but incapable of coping with either uncertainty or change – and relies instead on a stream of management-fads to give a spurious sense of certainty where none actually exists. Which is not a good idea, especially in the increasing uncertainties of most present-day business contexts. We need that balance…

The simplest way to work towards a better balance is that, for each item that seems to fit in either the Complicated / Assertion domain or the Ambiguous / Use domain:

• what is its counterpart in the opposite sensemaking or decision-making domain on the other side of the frame?
• what processes link these two items together, such that each can learn from and support the other?
• how do these processes vary at different distances from the point of action?
• how do these processes vary for different skill-levels or for use with different real-time process-implementations?

(We’ll come back to that last question shortly.)

So, for example, Complicated-domain analytic, algorithmic hard-systems theory has its Ambiguous-domain counterpart in experimental, emergent soft-systems theory: in what ways do these link together? How do they support each other, inform each other, conflict with each other, enhance each other? How do we identify (make sense of) which approach would apply better to any given context? What are the trade-offs that would guide such decisions?

[For some great examples of how this kind of interaction works in scientific research, see WIB Beveridge's 1950 classic The Art of Scientific Investigation.]

Using those tests and guidelines, work your way across all aspects of the architectures, to identify gaps and imbalances across the SCAN domains.

For improvement of real-time action, the processes would, in principle, be partitioned across either side of the Inverse-Einstein test: those processes that focus ensuring that the same actions lead to the same results, versus those processes that focus more on skills-development, such that we can achieve the required variation in similar contexts or the required ‘sameness’ in different contexts. In very quick summary:

• improvement on the left-side (‘order‘) will focus primarily on efficiency (typically described in quantitative terms, and often regarded as synonymous with effectiveness)
• improvement on the right-side (‘unorder‘) will focus more on broad-spectrum effectiveness (with an emphasis on qualitative factors and human-concerns)

That order-versus-unorder partitioning is valid in itself – the Simple true/false methods used by machines and IT-systems, versus the full modality of methods available within skills-work. Yet it’s also in itself too simple, or too simplistic, rather: we need the framework to give guidance on skill itself.

This is where we come back to that question about reflection-processes that vary according to skill-levels. In essence, it’s not really a skill unless there’s some inherent-uncertainty involved in the context: before that, all the way over onto the Simple side of the spectrum, everything is literally mechanical, rule-based.

For this, we can turn to a cross-map of the SCAN frame with a spectrum of variability or predictability – shown as the blue curve in the diagram below:

The diagram is perhaps slightly misleading here, because the impact of variability doesn’t come out well enough: the blue line is itself another kind of continuous spectrum, rather than the Simple true/false implied by the colour-shading here.

[Part of the reason is that I don't yet know how to how to do multi-layer multi-colour graded-shading in Visio: accept it as it is for now, if you would?]

What is relevant here is the the way in which skills-development follows the same effective path of increasing variability – including that increased distance-from-action in the middle of that curve.

What we actually have in skills is not so much a Simple ‘either/or’ – Simple or Not-simple, order or unorder, as implied on the diagram – but more a ‘both/and’ mix of order and unorder. Higher levels of skill also implies or requires the ability to cope with higher levels of modality, variability and unorder. We can split this in terms of five distinct skill-levels:

• Robot: no skill as such – Simple rule-following only
• Trainee: low level of skill – mostly Simple / Belief, aware only of ‘here and now’, requires active supervision to cope with variability
• Apprentice: some level of skill, still primarily order-based but able to manage more Complicated / Assertion contexts with broader factors and feedback / feedforward loops, with some active supervision
• Journeyman: significant skill, able to cope with higher levels of Ambiguity and context-dependent Use, with supervision mainly in the form of mentoring
• Master: high skill, able to cope with inherent-uniqueness, balance of ‘big-picture’ with ‘here and now’, and ‘supervision’ only in the form of peer-review

So when we look at the ‘vertical’ improvement-processes implied by the SCAN frame, we tend to find that they work best when they act on specific mixes of order and unorder, sameness and uniqueness – in other words, in alignment with these skill-levels.

We can also see the classic ISO-9000 quality-system derivation-sequence at work here, between each of those steps:

• work-instruction: context-dependent rules used by Robot and initial Trainee – emphasis on What and How
• procedure (basis for new work-instruction): used by Apprentice and above, defined by Journeyman and above – emphasis on Who, Where and When
• policy (basis for new procedure): used by Journeyman and above, defined by Master – emphasis on Why
• unchanging-vision (permanent-anchor for quality-system, used as basis and cross-check for new policy): used by Master, defined by Master in peer-review – the ‘Because.’ behind the Why

There are many, many types of review / improvement-processes – PDCA (Plan, Do, Check, Act), for example, or AAR (After Action Review) or OODA (Observe, Orient, Decide, Act). Yet almost all of them have this ‘vertical’ character, to link:

• from real-time action – where there’s no time to think
• to distance-from-action – which creates thinking-space and review-space, to enable improvement
• then back to real-time again – to apply that improvement in real-world practice

There’s a usually a slight sideways-move in there somewhere – because wherever practicable the aim should be to enhance those skill-levels, not leave them solely as they are. But what we don’t want are ‘diagonal’ moves that try to link one type of order / unorder mix at ‘thinking-time’ with a very different mix at real-time – because it all but guarantees failure in practice. We’ll explore that point in more detail in the next part in this series: for now, we’ll focus more on the ‘verticals’.

We can again summarise these processes in terms of those five distinct skill-levels:

– Robot: Simple / Belief only (typically machines or real-time IT-systems) – aim is to optimise efficiency within a specific defined context

This is the classic realm of Taylorist time-and-motion study, of Six Sigma and suchlike: if we assume that everything in the work-context remains the same, what can we do to improve the efficiency of that ‘sameness’?

The crucial point here is that the Robot can only follow the rules that it’s given: it can’t change anything by itself – or even adapt to any significant change in its context. The Robot must rely on an external ‘expert’ to redefine its rules whenever the context undergoes any significant change, yet the ‘expert’ does not have to deal with real-world consequences: a fact which, if misused, can lead to a dangerous co-dependent relationship between Robot and ‘expert’, based on mutual evasion of responsibility – something that we see far too often as an outcome of dysfunctional blame-based management-structures.

– Trainee: Simple / Belief <-> Complicated / Assertion – aim is to develop ‘rule-following’ efficiency and to develop awareness of the ‘larger picture’, to place own work in context, and to begin to cope with variability

We typically see two types of review-processes here. One type concentrates on practice – embodying ‘the rules’ through constant repetition, mainly focussed on method, on the ‘what’ of those rules as applied to real-time action. The other type, typified by the US Army’s ‘After Action Review’, begins a focus on enhancing personal ‘response-ability’ – a concern that will continue all the way through the skills-development sequence.

– Apprentice: Complicated / Assertion <-> Simple / Belief (with some bridge over to Ambiguous, e.g. via experimentation) – aim is to develop ability to use formal-theory to redefine own rules as the context changes

This is the classic realm of formal education, with an emphasis on theory and on the mechanics of the skill, the ‘how’ behind its processes and methods. However, the focus is almost more on ‘order’ than at the Trainee level, defining rules as ‘objective truth’ to be applied by others in real-time action. The main contextual-shift is a developing awareness of more and more Complication in those ‘rules’ – a layering nicely described by Jack Cohen and Ian Stewart as an increasing sophistication of “lies-for-children” – in which additional factors, interaction-loops and delay-impacts are added to the rule-definitions. One of the hardest parts of this stage is re-simplifying these ever-more-complicated algorithms and ‘rule-sets’ down to a form that can be used in real-time action…

– Journeyman: Ambiguous / Use <-> Not-known / Faith (with some bridge over to Complicated, e.g. as ‘applied science’) – aim is to enhance ability to work with increasing levels of variation and near-uniqueness, such as by applying patterns and guidelines

This is typified by the crucial shift in awareness that theory alone is not enough: in the real world, ‘truth’ is often highly contextual. This is the realm of ‘real’ complexity, of emergence, of iterative exploration and experimentation, and also a more explicit acknowledgement of the inherent unorder that underlies wicked-problems and the like. It’s also a realm of probability and improbability – hence a strong focus on concerns such as the uncertainties of statistics, on kurtosis-risks, long-tail opportunities, and so on.

[Note the danger of failure to understand the probabilistic nature of statistics - that they always embed and embody some degree of unorder and uncertainty. It has its rules, but they're not the same order-based rules as in the Complicated domain: for example, it's true that chaos-mathematics can enable us to be very precise about the degree of uncertainty in a context - but it does not remove the uncertainty itself. Another important 'You Have Been Warned' that we need to pass on to our architecture-clients?]

There would also be a stronger emphasis here on guidelines and patterns, and on what we might describe as the approaches to each skill – the unorder of the ‘other mechanics’ of the skill, such as in the psychological and emotional drivers, and in ergonomics and individual difference. Continuing and expanding the theme of the After Action Review, this is the realm of responsibility-oriented continuous-improvement processes such as PDCA and kaizen, of simulators and ‘sandboxes’ and other ‘safe-fail’ learning-spaces, and also of context-exploration tools such as the skills-labyrinth.

– Master: Not-known / Faith <-> Ambiguous / Use – aim is to enhance effectiveness, being able to work with any level of variability and uniqueness at real-time, in line with overall vision and values

It’s at this level that we return to real-time practice, but this time aiming to be able to work with unorder, rather than fight against it (or even pretend that it doesn’t exist…), as in the rule-based assumptions of the Robot space. Here there’ll be a strong emphasis on enhancing capability for improvisation, and for coping with inherent uncertainty, such as with innovation and with Black Swans and other opportunities and risks at the extreme end of unorder. For skills, this would also bring together the previous themes in active acknowledgement that method = mechanics + approaches – hence true skills are both same and different for everyone at every time. On a practical level, there’s also a strong emphasis on the use of principles, vision and values to provide a stable anchor for guidance amidst inherent-uncertainty.

[Notice that, again, all of the above sequence is recursive: we may well be at Master level in some skill-domain, but barely at Trainee-level in another - a fact that can at times be somewhat challenging... ]

Implications for enterprise-architecture

For enterprise-architects, there’s a lot to review here, because all of those items need to be in place if the overall architecture is to work well for the organisation and enterprise:

• services that bridge across the modalities of certainty and uncertainty in real-time action
• services that bridge between certainty and uncertainty in planning for action and reflection on action
• services that improve how we apply certainty in action, how we work with uncertainty in action, and the skills of each person to work with these

We’ll need to identify each of these items, for each of the respective ‘horizontal’ and ‘vertical’ contexts; and wherever there are gaps in the needed support, identify what needs to be done to create and embed the respective items.

We also need to be aware of and act on some really nasty booby-traps that, if we’re not careful, can damage or even destroy the entire enterprise. Dysfunctional management-structures and misapplied Taylorist ideas are well-known examples of these: the real problem there is that the illusion of ‘control’ is so comforting to so many that these muddle-headed mistakes keep on coming back to bite us time and time again, like the proverbial ‘bad penny’.

Another serious danger that’s a bit more subtle can arise from those seemingly-relentless demands to do more and more, faster and faster. Part of this is that the sheer pressure to produce can cause a disconnect between strategy and tactics and even between tactics and operations: when everything has to happen now, there’s no time to think about what’s being done, or why. Not a good idea…

But a corollary of that is that if there’s no time to think, there’s also no time to develop skills – a point which again is made clear in that cross-map between SCAN and the variability-curve above. All too often we’ll come across an organisation that in essence consists of Masters and Robots (such as machines or IT-systems, or ‘crowdsource’ structure such as Mechanical Turk which in effect treat real-people as Robots), with nothing in between – perhaps a few Trainees to do the grunt-work, but that’s about it.

There’s little question that this can be highly profitable in the short term. Yet it’s a model that, almost by definition, cannot and does not scale – hence the constant complaints we see about ‘skills shortages’ and the like – and why so many startups seem to crash-and-burn so soon after their first flush of sweet success. And if there’s no means within the organisation’s architecture to develop those skills, there’s also no way to learn the contextual information needed to create the next generation of Masters – see the post ’Where have all the good skills gone?‘. Ignoring the skills-development issues may seem profitable at first, but it’s actually a guaranteed path to commercial suicide. Once again, You Have Been Warned?

Anyway, enough for now: more on this and other related themes in the final post in the series.

Any comments or questions so far, anyone?

This is Part 2 of this exploration: the first part is in the post ‘Decision-making – linking intent and action [1]‘. (Once again, please note that this is ‘work-in-progress’, so expect rough-edges and, uh, partly-baked ideas in various places?)

What we ended up with the previous post is that we what we do want is strong ‘horizontal’ connections across the modalities at the same time-distance to action, and strong ‘vertical’ connections across the time-scales at the same modality:

What we usually don’t want – unless intentionally, and with considerable extra care – is ‘diagonal’ connections across both timescale and modality in the same link:

The key point for architecture is that at the moment of action, no-one has time to think. Hence everything that we build in the architecture to support real-time action also needs to support the right balance between rules and freeform, belief and faith, in line with what happens in the real-world context.

It needs to ensure that we have the right sets of rules for action when rules do apply, and the right experience such that the fallback into faith is as effective as possible whenever the rules don’t apply.

What this implies is that, within the architecture, we’ll need to include:

• services to support each sensemaking/decision-making ‘domain’ within the frame
• services to support the ‘vertical’ and ‘horizontal’ paths within the frame
• governance (and perhaps also services) to dissuade following ‘diagonal’ paths within the frame

It also implies the need for a radical rethink of ‘command and control’ as a management-metaphor, which is where we finished in the previous post. What we’ll turn to here is the other items in that list immediately above.

Before we start, though, one important point to note: all of this is recursive. For sanity’s sake, I’ll need to keep things as Simple as possible here, using bullet-point lists and the like: but in reality all of it is also Complicated, Ambiguous and None-of-the-above – and each of those aspects likewise has components that are simple, not-so-simple and so on. It’s clear-cut and simple, and it’s blurry and messy – all of it recursive, ‘self-similar’ and different, all at the same time. Which gets more than a bit complicated or complex or even chaotic if we try to describe it all in one go…

So for now I’ll take the easy way out: I’ll aim for just a brief-as-I-can-make-it summary, and go into more detail where necessary in later posts. Or you can ask for clarification in comments here: it’s up to you. Point is that, of necessity, this is only scratching the surface: I’m well aware that it ain’t as Simple as I may make it seem, and I’ll trust that you’re aware of that too.

On services to support each domain:

For this section we’ll explore both sensemaking (left) and decision-making (right) together:

In both cases, the domains here split into two distinct sets, ‘horizontally’ either side of the Inverse Einstein test:

• on the left-side (‘order‘), our sensemaking and decision-making tactics (Simple / Complicated, Belief / Assertion) assume that things are predictable – and hence that doing the same thing should lead to the same result
• on the right-side (‘unorder‘), our sensemaking and decision-making tactics (Ambiguous / Not-known, Use / Faith) assume that things may not be predictable – and hence that doing the same thing may lead to different results, or achieving the same results may require doing different things

The vertical distinctions between the domains are often rather more subtle, but it’s crucial that our architecture does provide support right down to the exact moment of action. We need to make a point of this, because there’s an all too common tendency to assume that what works well distant-from-action – Complicated analysis and Complex experimentation, for example – will also work well at the point of action. Yet as the old joke warns us:

In theory there’s no difference between theory and practice. In practice, there is.

‘Distant-from-action’ and real-time action are related, yet qualitatively different, in much the same way as Newtonian physics differs from quantum-physics. Hence these pairs of domains in the ‘vertical’ dimension as well.

So: order-domains:

What support do you have for Simple sensemaking: ordered, ‘controlled’, at real-time? What kinds of sensemaking are needed within the work at or close to the exact moment of action?

• examples: checklists, comparison-charts, mechanical sensors, real-time signals

What support do you have for Complicated sensemaking: ordered, ‘controlled’, predictable, but some distance away from real-time – either before the event as preparation, or after it, to make sense of what happened? What different types of support do you need for different ‘distances’ from real-time, from seconds to minutes to hours to days to months to years to decades and beyond?

• examples: analytics, dashboards, computational filters, aggregation

Going back the other way, from sensemaking to decision-making:

What support do you have for Assertion-based decision-making: decisions that assume the existence of order, ‘control’, predictability, yet also are some distance from – usually prior to – the moment of action? What different types of support are needed over the different timescales that we might describe as strategic, tactical and operational?

• examples: algorithms, hard-systems theory, computation or business-rules IT-systems

What support do you have for Belief-based decision-making: real-time decisions based on certainty, on rules, on assumed predictability? In what ways does this decision-making differ when there’s no time to think, no separation between decision and action?

• examples: rule-sets, rote-learning, step-by-step checklists and work-instructions, physical machines, real-time IT

And: unorder-domains:

What support do you have for Ambiguous sensemaking-contexts: some distance from the action, yet still known-uncertain? What different types of support do you need before and after action, and for different ‘distances’ from real-time?

• examples: experimentation, pattern-matching, statistics, trend-analysis, futures techniques, crowdsourcing

What support do you have for None-of-the-above sensemaking-contexts: right at the moment of action, yet inherently uncertain in some or all aspects? What kinds of sensemaking need to take place here?

• examples: listening, ‘flow‘, managing panic, social structures for ‘safe to fail’

(Note that most of that last set of examples would address not so much the sensemaking itself, but providing appropriate conditions for real-time sensemaking in inherent-uncertainty.)

From sensemaking to decision-making:

What support do you have for Use-based decision-making: decisions that are some distance from the action, yet do not assume certainty or predictability? What different types of support are needed over the various different timescales of distance-from-action?

• examples: patterns, guidelines and values, soft-systems theory, prioritisation, probability and necessity (modal-logic), social methods (from meetings to voting-systems etc)

What support do you have for Faith-based decision-making: decisions that must be made in the heat of the action in the midst of inherent-uncertainty?

• examples: principles (i.e. actionable values), skills and experience, context-design to maximise safe-fail or ‘graceful failure’, trust in ‘that which is greater than self’

(That last item is by far the hardest to describe, but it’s a key reason why I use the term ‘Faith’ here. I suppose this might perhaps be a kind of ‘hive-mind’ effect, but the point is that decisions here will often carry a feeling of ‘it was the right thing to do’, an ‘intuitive’ decision that aligns with a broader collective-purpose without conscious knowledge or certainty of how it does so. Deep familiarity with shared principles and values is a known key driver and anchor for this type of decision-alignment – hence their importance as and at the core of an enterprise-architecture.)

Review those lists above: which of those items would you currently include in your enterprise-architecture or process-architecture? Most conventional architectures will describe only the left-side (‘order’) items – yet support for all of these forms of support will need to be in place for the enterprise and its architecture to work well. Note any gaps in the architecture, and, even more important, gaps in support; and then move on.

In the next part of this series we’ll explore the architecture of how we link all these domains together. Any questions for now, though? Over to you, anyway.

This extends the previous posts on SCAN sensemaking and real-time decision-making, ‘Belief and faith at the point of action‘ and ‘Decision-making – belief, fact, theory and practice‘, this time to explore the linkage – or lack of it – between ‘considered’ decision-making and real-time decision-making.

[As before, most of this is 'work-in-progress', so be gentle with it, okay? It should be usable as-is, but do expect odd gaps, rough-edges and wobbly-bits in various places, and please give constructive feedback where you can. Thanks!]

We started from the SCAN sensemaking-frame:

And reviewed it from a perspective of decision-making rather than sensemaking:

It’s actually the same frame, so the two axes are the same in both views:

• a ‘horizontal’ axis of modality of sensemaking and decision-making, from simple true/false on the left, to infinite-possibility on the right
• a ‘vertical’ axis of time-to-decision or time-to-action, stretching from a real-time ‘now!‘ to a potentially-infinite future (and some symmetry with time-from-decision etc, into the past)

The vertical-axis is essentially continuous, but the horizontal-axis has a distinct phase-shift where the modality of decision changes from a simple-true/false [0..1] to an open n-ary [0..n] choice. To the ‘left’ of this point, the apocryphal Einstein dictum applies: doing the same thing should lead to – or is believed to lead to – the same results; whereas to the ‘right’ of that point, doing the same thing may lead to different results, or doing different things may lead to the same results.

On the left-side, there is what purports to be ‘objective certainty’; on the right-side, there is, by definition, some degree of inherent-uncertainty, always somewhat context-specific, and often somewhat personal and subjective. A conventional ‘control’-based concept of the world assumes that everything can somehow be forced onto the left-side of the frame; Reality Department and real-world practice indicates that such concepts of ‘control’ are still wishful-thinking at best, and that alternate decision-strategies must be available, dependent on context.

Hence one of the key tasks of an enterprise-architecture is to ensure that all required decision-methods are supported, and also ensure that appropriate methods are applied to each context.

The previous post, ‘Decision-making – fact, belief, theory and practice’, mainly looked the ‘horizontal’ dimension of this frame; here we’ll explore the impacts of the ‘vertical’ dimension – specifically, the separation between intent and action.

Two parallel paths

We have a plan. An intent. We’re sure we’ll know what to do when the time comes. And yet, to paraphrase von Clausewitz, no plan survives first contact with Reality Department. What we intend doesn’t happen the way we’d planned. (Or perhaps, even stranger, we were equally sure that we wouldn’t know what to do, and yet we discover that we did know what to do – but have no idea how.)

In short, there’s a difference between intentions and expectations beforehand, and what actually happens in real-time action. And we’d like to find some way to close that gap, and create better results overall – whatever those intended results may be.

That’s where continuous-improvement or continuous-reassessment tools come into the picture – techniques such as PDCA and OODA, for example. Likewise the US Army’s After Action Review, four questions that cross-link with the PDCA cycle:

• “What was supposed to happen?” – to answer that, we need some grasp of Plan or intent
• “What actually happened?” – to answer that, we need to be able to observe what we Do and did
• “What was the source of the difference?” – to answer that, we need to be able analyse, assess, Check and compare
• “What do we need to do different next time?” – to answer that, we need to find the courage to face up to change, and to Act to align our capabilities to align better with that actual or needed change

All of these review/reassess processes cycle through the ‘vertical’ dimension, always returning to real-time action, yet catching a variously-brief breath away from the action to create space for reflection and change. There’s often a lot of recursion in this, of cycles-within-cycles – as is particularly clear in OODA – yet in essence it always depends on availability of some time away from the action. If the only time allowed is the ‘now!‘, that also blocks access to any means to adapt to changes in context – and that’s an all-but-guaranteed recipe for decision-disaster…

So to make it work – to create effectiveness within the enterprise – we’ll usually need a lot of vertical movement in SCAN terms. Yet as we saw in the post ‘Belief and faith at the point of action‘, there’s usually also a lot of to-and-fro across the horizontal direction, between closed belief and open faith. And between those two different movements – cyclical and recursive in one direction, a more context-driven back-and-forth in the other – this can get real confusing real fast if we’re not real careful: mixing up the different modes usually leads to unintended outcomes.

Yet the Inverse-Einstein test – that horizontal distinction between true/false versus modal n-ary decision-making – runs right the way through the frame, giving us something that we can use as an anchor to keep the decision-making and capability-development more stable. That anchor gives us a means to keep the moves separate:

• at real-time and at any given distance-from-action, move back-and-forth horizontally across the decision-modality, to identify or apply appropriate decision-rules
• review-processes apply vertically, at a given level of decision-modality – which often also aligns in practice with a given skill-level

So the Inverse-Einstein test gives us two distinct parallel paths in the ‘vertical’ direction, for review and capability-development: one whose core focus is on ‘truth‘, based in true/false logic; the other on usefulness, or ‘value’ in a subjective sense, based on a fully-modal decision-logic. In effect, that’s CP Snow’s ‘Two Cultures‘:

• the sciences emphasise certainty, linking Simple to Complicated, Assertion to Belief
• the humanities emphasise personal-experience and trust, linking Not-known to Ambiguous, Use to Faith

In reality, of course, they do connect horizontally with each other – technology being the obvious example. But the connection only works well when it’s at the same time-level, the same distance-from-action.

What we don’t want – what we need to avoid – are unintended ‘diagonal’ moves across the frame. Ambiguous ideas will confuse and fail as Simple rules, for example, whilst Complicated assertions applied as certain ‘truth’ in the Not-known at real-time are rarely a good idea:

• markwfoden: RT @webisteme : Simple rules lead to complex behavior. Complicated rules lead to stupid behavior

In short, what we do want is this:

And what we don’t want is this:

The next question, of course, is how we support all of that in our enterprise-architectures.

Implications for enterprise-architecture

Probably the key point for architecture is this: at the moment of action, no-one has time to think. And yet we still have to do the right things, and do them right, without being distracted by the need to think.

Things have to work according to a combination of very simple, immediately-accessible, no-thinking-required rules, and free-form trust and faith, a letting-go into the ‘flow‘ of the moment. In practice, that’s what we most need our architecture to support: or, to put it another way round, everything else exists to support what happens in that real-time action.

Everything we build in the architecture also needs to support the right balance between rules and freeform, belief and faith, in line with what happens in the real-world context. It needs to ensure that we have the right sets of rules for action when rules do apply, and the right experience such that the fallback into faith is as effective as possible whenever the rules don’t apply.

The key role for an organisation is to help make ‘the right things happen right’, in accordance with the needs of the extended-enterprise that’s shared with that organisation’s customers, clients, suppliers, partners and other stakeholders. The organisation aligns itself with the enterprise-story, and brings its resources and capabilities to bear on some selected subset of that enterprise’s problems, desires and needs. Hence, in turn, the role of the enterprise-architecture and domain-architectures for that organisation is to provide appropriate support to identify, track, design and change those ‘response-abilities’ of the organisation.

All of that should be straightforward enough, I hope. Yet what it implies is that, within the architecture, we’ll need to include:

• services to support each sensemaking/decision-making ‘domain’ within the frame
• services to support the ‘vertical’ and ‘horizontal’ paths within the frame
• governance (and perhaps also services) to dissuade following ‘diagonal’ paths within the frame

- part of which, in turn, requires:

• a radical rethink of ‘command and control’ – especially its (mis)use as a management metaphor

Deal with the last point first, perhaps: rethinking command and control. As described in the post on insuperordination, we’re still often stuck with a legacy management-model that is grossly inappropriate for most current business-needs, and perhaps always was. In conflating genuinely-useful for ‘tree’-type service-oriented aggregation-structures with largely mythical notions of hierarchy and importance, we’ve ended up with management-structures that assign ‘rights of command-and-control’ over ‘subordinates’, regardless of whether the ‘superiors’ actually have the competence and knowledge to make the required decisions – which, in many of the highly-volatile business-contexts of today, they generally don’t. The result, in all too many cases, is a management-mess: the near-total antithesis of efficiency, effectiveness or relevance.

In short, far from being the ‘solution’ that it purports to be, Taylorist-style hierarchies of one-way ‘command and control’ from ‘owners’ to ‘managers’ to ‘workers’ are one of the most serious sources of problems in enterprise-architectures. The way forward, architecturally speaking, is to rethink the nature and role of ‘command and control’, and to separate it from those redundant management-myths.

Perhaps surprisingly – or perhaps not – some of the most active proponents of such a rethink are the US military: in particular, the work of David Alberts and others at the (US) Dept of Defense Command & Control Research Program. To be blunt, they’re literally decades ahead of where most business-organisations are today: see, for example, ‘Command Arrangements for Peace Operations‘ (1993) [PDF] or ‘Understanding Command and Control‘ (2006) [PDF]. (The mini-book ‘Power to the Edge‘ is rather better-known outside Defense circles, and is a must-read for anyone involved in organisation-architectures or enterprise-architectures.)

[Quick note: for enterprise-architects and others, I would strongly recommend any of the work of Alberts' and his team, such as those books above and their most recent book, 'The Agility Advantage' [PDF]. For managers and other business-folk, perhaps think of this as Sun Tzu’s The Art of War, brought up to date? – and just as important, too.]

In essence, the classic hierarchical model assumes that command and control are essentially the same: a command from the ‘superior’ is expressed as orders that control the actions and results of the ‘subordinates’. Alberts’ work indicates that command and control are radically different – in particular, that the concept of ‘control’ only makes sense for things that can be controlled via simple true/false logic, such as machines. For anything else – including real people – the closest that we can have to ‘control’ is ‘commander’s intent’: a ‘command’ that explicitly acknowledges the existence of inherent-uncertainty and, preferably, the degree or extent of that uncertainty. In short:

• ‘control’ applies primarily to decision-making on the left-side of the SCAN frame (Assertion and Belief)
• ‘command’ applies primarily to decision-making on the right-side of the SCAN frame (Use and Faith)

It’s perhaps useful to compare this with the Cynefin framework, especially at real-time. On the left-side or ‘control’-oriented side of SCAN (the equivalent of Cynefin’s ‘Simple’-domain), the Cynefin dictum of ‘sense > categorise > respond’ does make practical sense: whatever is sensed is matched against predefined categories, which then elicits responses in terms of that structure of ‘control’. Yet on the right-side of SCAN at real-time (equivalent to Cynefin’s ‘Chaotic’-domain), the Cynefin dictum of ‘act > sense > respond’ makes little to no sense at all: in effect, it assumes the absence of any guiding ‘commander’s intent’ or equivalent – which could indeed lead to the wrong kind of chaos.

[Cynefin works well enough at a good distance-from-action, but in this sense can be actively misleading relative to any real-time context. Yet real-time is literally where the action is. It's a problem...]

This again is where the distinction between ‘organisation’ and ‘enterprise’ is useful. An organisation is bounded by rules, roles and responsibilities, which does allow for the possibility of something that resembles ‘command = control’, though only within the scope of that organisation. Yet once we move beyond that scope, or have to work with partners and other stakeholders who are beyond the remit of the organisation’s rules, and may well conflict with them (as Alberts describes in ‘Command Arrangements for Peace Operations’), we are then in a context which is literally ‘beyond control’ – and we need a form of ‘command’ that does not assume indisputable equivalence with ‘control’. For those purposes – in fact for anything on the right-side of the SCAN frame – we need to move to a form of command based more on the shared-enterprise, bounded by shared (or at least agreed) vision, values and commitments.

Hence enterprise-architecture, rather than solely organisation-architecture – and rethinking ‘command and control’ to match that broader scope.

(I’ll split this here and tackle the remainder in another post. Any comments so far, though?)

This extends the previous post on real-time decision-making, ‘Belief and faith at the point of action‘, to crosslink with the earlier ideas on SCAN and sensemaking, and especially about where there is more time available to review and reflect on action.

[A gentle warning and polite request: much of this is still 'work in progress', so do beware the rough edges and knobbly bits, and use it with some caution; and whilst I do need critique on this, please don't be too quick to kick down the scaffolding that's holding it all together. Fair enough?]

The previous post was about how options for sensemaking become more constrained as we approach real-time. Right at the point of action, the options reduce to either a Simple interpretation in terms of of true/false categories, versus a Not-simple interpretation based on a modal-logic of possibility and necessity, which is much harder to explain or even to describe to anyone else. In SCAN we’d depict that compression as follows:

In much the same way, decision-making becomes compressed down to Simple belief versus Not-simple faith – neither of which are actually explainable, and both of which, at the root, are primarily emotional rather than ‘rational’:

In both sensemaking and decision-making, the crucial distinction – indicated in SCAN by where the red-line time-axis crosses the green-line axis of decision-modality – is what I’ve termed the ‘Inverse Einstein test’. Einstein is said to have asserted that “insanity is doing the same thing and expecting different results”: but whilst that’s true in a simple rule-based world, it’s not true – or not necessarily true, anyway – in a more complex world where many things are context-specific or even inherently unique.

So our ‘horizontal’ test is this: if doing the same thing leads to the same results – or is believed to lead to the same results – then it’s a Simple decision; if doing the same thing leads to different results, or if we need to do different things to get the same results, it’s Not-simple.

[Yes, I do know that that's a Simple true/false distinction across a spectrum that in reality is fully modal. If you want to apply the appropriate recursion here, please feel free to do so: I thought it wisest here to keep it as simple as possible, because this can get complicated real fast, and unless we're careful to keep the complexities at bay we could end up with a right old chaos of confusion. Which is, yes, yet another recursion... Hence best to keep it simple for now, as best we can, acknowledge that much of it isn't Simple, and allow the recursions to come back in later when there's a bit more space to work with it.]

The crucial point about real-time is that there’s no time available for a distinct sensemaking-stage: decision links directly to action, and vice-versa. (That’s why it’s called ‘decision’: the same linguistic roots as ‘incision’, it’s literally ‘cutting away’, ‘cutting apart’, the cutting-edge for action in the ‘now’.)

For sensemaking to take place, there must be a gap in time between one decision to the next. The key to John Boyd’s ‘Observe, Orient, Decide, Act’ (OODA) loop – which, importantly, is also not a loop as such – is that it still allows distinct sensemaking (‘Orientation’) to take place, but keeps it as close to real-time as possible: that’s what’s meant by ‘getting inside the opponent’s OODA loop’.

As time-available – the red-line ‘vertical’-axis in SCAN – extends outward either side of real-time, the OODA-’loop’ can become recursive, and thence, given enough time, simplified-out to a Deming-style ‘Plan, Do, Check, Act’ (PDCA) continuous-review cycle, such as is also implied in the US Army’s ‘After Action Review‘:

• “What was supposed to happen?” – what was our Plan?
• “What actually happened?” – what did we Do?
• “What was the source of the difference?” – what do we need to Check?
• “What do we need to do different next time?” – about what do we need to Act?

As I’ve described in other posts, sensemaking-choices tend to split as described in SCAN: there’s a ‘bump’ on the path, indicated by the jump between simple true/false logic versus fully-modal logics of ‘possibility and necessity’ on the ‘horizontal’ axis, contrasted with a much smoother spectrum of choices as available-time extends in the ‘vertical’-axis. Although the ‘vertical’ boundaries are less clear-cut than the ‘horizontal’ ones, this gives us the four SCAN quadrants – Simple, Complicated, Ambiguous, Not-Known:

Those distinctions determine the appropriate tactics for sensemaking, as described in those earlier posts.

Decision-making seems to follow a similar, closely-related pattern – though that’s the part I’m having trouble pinning down right now.

[Boyd's OODA is in part another attempt to pin down the same relationships; likewise Snowden's Cynefin, if rather less so. Jung's frame of 'psychological types' is probably a closer fit than Cynefin for this: I've used a generic decision-types adaptation of it for some decades now, though it's still not quite right. Hence this exploration here.]

So again, it’s ‘work-in-progress’, but this is where I’ve come to at present:

It’s a decision-making frame based on the same horizontal (decision-modality) and vertical (time-available) axes as in SCAN, and hence the same sort-of-quadrants but with a decision-oriented re-labelling: Belief (Simple), Assertion (Complicated), Use (Ambiguous) and Faith (Not-known).

On the left-side of the Inverse-Einstein test, the mechanism that links Assertion and Belief is a drive for certainty, for ‘control’. On the right-side, linking Use or ‘usefulness’ with the real-time openness of Faith, is more a focus on experience, underpinned by a deeper kind of trust – a trust which is often conspicuously absent in any concept of ‘control’.

[For this post I'll focus more on what happens across the horizontal-axis, the relationships between theory and practice, or 'truth' versus 'usefulness'. I'll explore more closely the interactions along the vertical-axis - between what we plan to do versus what we actually do - in a following post.]

In terms of decision-making tactics:

• on the left-side, theory takes precedence over practice – or, in some contexts, ideology rules, which is much the same
• on the right-side, practice takes precedence over theory

In essence, this is CP Snow’s classic ‘The Two Cultures‘, the sciences (left-side) and the arts (right-side). Notice, though, that technology sits on the right, not the left: it uses theory, but that isn’t its actual base – hence the very real dangers in the often-misleading term ‘applied science’.

Bridging the gap, from left to right, is praxis,”the process by which a theory, lesson, or skill is enacted, practised, embodied, or realized”; and from right to left, is pragmatics, “a process where theory is extracted from practice”. As enterprise-architects would be all too aware, the latter always starts from pragma, from “what is expedient rather than technically ideal”: and it usually includes the joys of ‘realpolitik’, of carefully filtering reality to fit in with other people’s prepackaged assumptions…

That boundary denoted by the Inverse Einstein Test is all too real: whether the beliefs in question are ‘scientific’, religious, political or whatever, the ‘need’ for certainty will often trigger huge resistance against anything that doesn’t fit its assumptions. For example, there’s a very close mapping between this frame and the classic scientific-discovery sequence of idea > hypothesis > theory > law, which align with Faith, Use, Assertion and Belief respectively.

In real scientific practice, it’s not a linear sequence, there’s a lot of back-and-forth between each of the steps. And in principle, it should be a continuous-improvement cycle, a broader-scope form of PDCA. But as Thomas Kuhn and many others have documented, that same ‘need’ for certainty often places a near-absolute barrier between supposed ‘scientific law’ and any new ideas – in other words, between Belief and Faith – that brings that cycle to a sudden halt, sometimes for years, decades or even centuries. All too often, in practice, if we take the real-time ‘short-cut’ from Belief to Faith, we will be forcibly forbidden to return along the same path: instead, we’re forced to go ‘the long way round’, via Use and Assertion (hypothesis and theory) – which we may not have time to do. Which is a very real problem. And one that applies as much in enterprise-architecture as in any other field – as we’ve seen with the inane IT-centrism that has dominated the discipline for far too long.

It gets complicated…

What I’ve been seeing, as I’ve explored this frame, is a whole stream of often-subtle misunderstandings and ‘gotchas’ that I’ve noticed time and again in practice in enterprise-architecture and elsewhere. These seem to be where many unnecessary complications and confusions arise – so it’s worth noting them here.

For example, fact arises from experience: its basis is on the right-side of this frame – not the left. What’s on the left-side often purports to be fact: yet it’s not fact as such, but interpretation of fact – a very important difference. The left-side operates on information, an interpretation of raw-data – but it often has no means to identify the source or validity of that information, or its method of interpreting it. (This is the same inherent problem whereby a logic is incapable of assessing the validity of its own assumptions: by definition, it must call on something outside of itself to test those premises.) So on the left-side, there’s actually no difference between ‘real’ and ‘imaginary’ – which can lead to all manner of unpleasant problems if the left-side is allowed to over-dominate in any real-world context…

Importantly, there’s no real difference here between ‘objective’ versus ‘subjective’: that distinction is actually another dimension that’s somewhat orthogonal to this plane. What I feel, or sense, is subjective, but it’s still a fact; whereas how I interpret that feeling or sensation is not a fact – it’s an interpretation. Telling someone that they should or shouldn’t feel something is just plain daft: the feeling itself is a fact – something about which we don’t actually have any choice – whereas the ‘should’ is an interpretation arbitrarily imposed by someone else.

[What we do in response to a feeling is a choice - literally, a 'response-ability' - and is something that can be guided by 'shoulds' and the like: but not the feelings themselves. That's a very important distinction which, sadly, surprisingly few people seem to understand...]

There is a specific sense in which subjective versus objective aligns somewhat with the ‘less-time’ versus ‘more-time’ on the SCAN vertical-axis. More-time means more time available for experimentation and analysis – and that can allow us to identify what’s shared (‘objective fact’) across many people’s experience, versus experiences that are more specific and personal (‘subjective fact’).

But there seems instead to be a tendency to conflate the objective/subjective distinction with the SCAN horizontal-axis – objective-fact as ‘truth’ on the left-side, subjective-fact as ‘not-truth’ on the right-side. There are ways in which that conflation can work – it’s at the core of the Jungian frame, for example – but we need to be careful about it. Using that conflation to dismiss all subjective-fact as ‘irrelevant’ – as the classic ‘command and control’ models would do – not only makes no sense at all, but is extremely unwise in real-world practice…

There also several other key distinctions across either side of the Inverse-Einstein test:

– ‘science’ versus technology, which also parallels ideology versus practice: on the left-side, there’s an assertion that something is ‘true’, whereas on the right-side we proceed as-if it’s true – which is not the same at all.

– organisation versus enterprise: the nature of an organisation is that it’s about left-side themes such as control, beliefs, repeatability and certainty; the nature of an enterprise is that it’s not certain, “a risky venture” and suchlike – with all that that implies.

– structure versus story: most structures within current enterprise architectures will, again, have a left-side focus on providing repeatability and certainty; story and other forms of narrative-knowledge provide an alternate kind of ‘structure’ that holds many of the right-side themes together

– sameness versus uniqueness: another key enterprise-architecture theme, sameness and repeatability is very much a left-side theme, whereas uniqueness is just as much a right-side theme

– ‘best-practice’ versus ‘worst-practice’: the notion of ‘best-practice’ assumes that practice that worked well in one context will be directly applicable to another, the same success repeatable in another; by contrast, maintenance engineers and others who work extensively with unique or near-unique contexts share their learning more through ‘worst-practice’, stories of what didn’t work in a given context. (I think I first heard that one from Dave Snowden? – credit where credit’s due, anyway.)

The trade-offs across each of these dichotomies all have direct implications for the design and structure of any enterprise-architecture.

Implications for enterprise-architecture

Take a look at those dichotomies again: which side do you think is emphasised by current enterprise-architectures?

The obvious answer is that, almost invariably, the left-side is given priority over the right.

However, this has huge consequences for the effectiveness of the overall enterprise, and for the enterprise-architecture that describes it:

• interpretation takes priority over fact: never a good idea…
• theory and ideology takes priority over practice and experience: that’s almost a definition of (misused) Taylorism…
• the need for (spurious) ‘certainty’ and ‘control’ takes priority over trust of anything or anyone: ditto on Taylorism…
• the reliance on true/false decision-methods can render the organisation unable to cope with any form of uniqueness
• the need to force-fit everything into sameness of content – ‘best practice’, IT-centric BPR and the like – fails to grasp the differences of context
• the over-focus on organisation – ‘the letter of the law’ – literally kills off the spirit of enterprise…

Look at most of our existing EA toolsets, too: can you find any toolset that’s actively designed around anything other than true/false logic? Other than in rare model-types such as ORM (Object-Role Modelling), there’s no means to describe modality in relationships – hence, for example, no directly-supported way to describe a usable reference-model that allows for real-world ifs, buts and perhapses.

And whilst every toolset focusses on structure – and most do that very well, too – how many of those toolsets also help us to focus on the counterpart of story? They might support few use-cases, perhaps, but that’s about it: there’s a huge gap in capability there…

What we need, urgently, is a better balance between structure and story, between theory and practice, between organisation and enterprise. And without adequate support in the toolsets, that means that we have to create that balance ourselves.

The crucial point is that this balance is not an ‘either/or’, but a much more modal ‘both/and’:

• theory and experience
• ‘objective’ and ‘subjective’
• ‘science’ and technology
• certainty and trust
• true/false and fully-modal
• organisation and enterprise
• structure and story
• sameness and difference
• ‘sense’ and ‘nonsense‘
• certainty and uncertainty

We will only achieve a real effectiveness in the architecture via a fully-nuanced ‘both/and’ balance across all of these dimensions, and more.

So take a careful look at your own organisation, your own enterprise-architectures and the like: where is it out of balance, in this sense? In SCAN terms, how much does it over-emphasise the left-side at the expense of the right-side? And what can (and must) you do to bring it back into a better balance overall?

Comments/suggestions/experiences on this, anyone?

This one’s triggered in part by a swathe of complaints from various enterprise-architecture folks about a certain ‘standard definition’ of Complex, and also in part by a double-Tweet by Bruce Waltuck:

• complexified: @tetradian @davegray @Jabaldaia the 1st challenge is to understand the difference between complicated & complex. // 2d, understand different patterns of inquiry & response in each domain (complicated vs complex)

Sounds straightforward, doesn’t it? – define some differences, define the differences of methods that apply in each case, do it, all done. Easy: no sweat!

The reality ain’t quite that simple, though…

[...as I know Bruce knows well, of course - hence 'understand', not 'define', in that Tweet above.]

To see why it ain’t so straightforward, let’s first take the usual definitions from what, for safety’s sake, we’d best call ‘the SCCC-categorisation‘:

– Simple: rule-based, predictable, direct cause/effect relationships; use categories to guide response

– Complicated: rule-based and ultimately predictable but often indirect cause/effect relationships, sometimes with feedback-loops; use analysis and algorithms to guide response

– Complex: meaning emerges from and interacts with context, ’cause/effect’ can be misleading; use patterns, guidelines and ‘seeding’ to guide response

– Chaotic: ‘anything goes’, no discernable ’cause’ or ‘effect’; use action to break out to another domain (usually Simple or Complex)

Yet in reality, judging from some of those complaints, what we actually have is something more like this:

I don’t find rules simple at all, to me they’re crazily complicated, or more like what you’re calling complex. To me, guidelines are much simpler to work with. And what’s the difference between ‘complicated’ and ‘complex’? – complex is just complicated that we haven’t yet worked out how to control, isn’t it? My whole job is about getting rid of complexity, and here you say it’s something we want? – that’s daft! And the service-management guys, all their work is about working with the chaos, not running away from it, so your definition don’t make no sense there neither.

Yeah, my head hurts too, trying to make sense of that… but it gets worse for a while yet… sorry…

What’s going on is that, to use those definitions above, definitions are a Simple tactic imposed on top of a Complex context, resulting in the would-be Simple becoming so Complicated with exceptions and uncertainties that it risks ending up as Chaotic. So to make it Simple, we have to accept that the Simple here is in fact Complex, and hence provide Simple rules to support a Complex anchor that allows for an emergent definition that is experienced as Simple by all those involved in that Complex social context. We avoid it becoming becoming too Complicated by accepting that it is Complex; and we use the uncertainty of the Chaotic to provide the source-experiences that ultimately make it Simple.

Simple, yes?

Uh, no…?

Okay, so let’s do a quick SCAN on this?

As a reminder, here’s the SCAN core-graphic again:

And the Inverse-Einstein test, which determines where we ‘are’ on the horizontal axis:

• if we do the same thing and get the same results, we’re ‘in control’ (whatever that means in the context) – which places us on the left-hand side of the graphic
• if we do the same thing and get different results, we’re not ‘in control’ – which places us on the right-hand side

A reminder, too, that the vertical axis is about ‘time until decision’: the less time we have, the more we’re forced either to a Simple form of ‘control’, or to work with the ‘Not-known’ as it is.

So: a SCAN on definitions and suchlike.

Definitions are good. They are – or should be – Simple, straightforward tools that allow us to make sense and make decisions at high speed.

The catch is that every definition is a Simple abstraction from what happens in the real-world. We choose to define it this way, to support this purpose. It’s true-for-a-given-for-a-given-value-of-’true’, so to speak: one person’s subjective-truth, used ‘as if’ it’s ‘objective-truth’ – which it isn’t. And it’s important we don’t forget that fact…

Definitions may be Simple and unambiguous for each person, for use in one specific context; but they’re highly Ambiguous between different people, and different contexts. So they’re both Simple and Ambiguous – all at the same time.

If we try to use a definition as if it’s only Simple – applies to everyone, everywhere, for everything – and we try to use it for control at business-speed, what we’ll get is lots and lots of arguments, about whose definition is the right one for the context. In other words, by ignoring the Ambiguous, it suddenly gets very Complicated – and thence, when people don’t know which definition is ‘the correct one’, but don’t have time to work things out, a collapse down into ‘Not-known’. Otherwise known as the wrong side of chaos…

So we speed things up by acknowledging the Ambiguity. We ask people what they each understand and use as their ‘the definition’ for that context. If there’s time available, we make a point of exploring those definitions in an explicitly Ambiguous form, to entice a collective definition to emerge from those differences. If we don’t have time to do that, we can impose a definition and still respect the Ambiguity by contextualising the definition, such as “For this purpose, we assert that the definition of… is…” – acknowledging that other definitions are possible, but this is the one that we’ll use.

We treat that definition as part of a Simple checklist, a ‘rule’: we can say “Do it this way, because we know that it works if we do it this way”. And we couple that later with another Simple check such as an After Action Review to verify that it actually does give the same results – the Inverse-Einstein test – and, if not, decide what to do about it. In other words, Simple tactics that work with the Ambiguous, rather than trying to pretend that it doesn’t exist.

Or, in the SCCC terms, a Simple way to deal with the fact that the Simple isn’t Simple.

So to make sense of the Complicated versus the Complex (in SCCC terms again), the first thing we need to do is acknowledge that the definitions aren’t as Simple as they might seem. Once we’ve addressed that, we then have a chance to develop a shared understanding of what each might mean in practice, and how to use that shared-understanding to support decision-making.

Just a quick SCAN there, anyway, to explore something that’s turned out to be surprisingly important in practice.

Hope it’s been useful: let me know, perhaps?

So let’s put these questions into practice.

Several people have asked me for a detailed worked-example of the sensemaking-technique of context-space mapping [CSM]. Recently, though, I’ve also ‘enjoyed’ yet another attack from Dave Snowden, in which he made two key assertions:

• that the cross-map process used in CSM is not a ‘mash-up’ but a “hash-up”
• that the entirety of CSM and, by inference, all of the other sensemaking tools and techniques that I’ve developed for enterprise-architecture and related fields are “invalid … in certain essential aspects”

He gave no evidence or reason as to why the cross-map process is supposedly so invalid as to be a “hash-up”, or any details as to what any of those purported “certain essential aspects” might be: so in essence, all we have from him is a circular ‘proof’, that it must be ‘true’ because he asserts that it’s ‘true’. This is a classic form of unprincipled-attack, one which most of us will face at some time or other in enterprise-architecture and the like.

His assertion is that CSM has no value; yet since that assertion itself has no rational basis, there’s likewise little point in trying to use any kind of rational defence. Probably the only meaningful response is ‘proof-of-the-pudding’, to demonstrate in practice that it does have value. And if it does have value – in other words, that it presents insights that had not previously been available, and might not have been available by any other technique – then, in turn, that should demonstrate that the attack does not have merit. We probably wouldn’t expect the attacker to understand this point: but it may help in our relations with others, in a more professional context.

So perhaps I ought to thank Snowden here, because he’s indicated the obvious candidate for this practical demonstration: what I’ll do here is apply context-space mapping to Snowden’s Cynefin framework.

And let you be the judge as to whether this cross-map technique has any practical value.

(This will, again, be long – my apologies…)

[Important point: for reasons that have been documented all too often on this website, I have had to invoke Bob Sutton's No Asshole Rule: Snowden is welcome to reply in his own website, but will not be allowed to reply here.]

The Cynefin framework

I won’t describe the Cynefin framework in detail here: it’s summarised on its Wikipedia page, but for the full details you’ll need to go to Snowden’s Cognitive Edge website.

(What follows is based on my own background and experience as a ‘registered Cynefin Practitioner’. I did the training-course, delivered by Dave in person, way back in 2003, when Cynefin was still part of IBM – in fact I was told that my colleague and I were the first non-IBMers to do that course. I still have all of the training-material from the course, and not much seems to have changed since then: a few key elements have been dropped – such as the ‘connection-pyramids’ devised by Cynthia Kurtz – but the only significant new element seems to be the ‘Sensemaker‘ software, a simplified adaptation of a public-domain US Government project.)

Cynefin is ‘sold’ as a sensemaking framework. The key idea is that, given an unknown context (the domain of ‘Disorder’), there are four distinct ‘ways of knowing’ that we can apply to that context, and hence four distinct types of tactics that we can then use, as summarised in the Cynefin graphic from the Wikipedia page:

Each of these ‘domains’ has obvious implications for enterprise-architectures and the like:

• we want to keep things simple, and apply best-practice wherever it’s appropriate
• many things we deal with are complicated, requiring good practice and depth-analysis to bring it under control
• when things get complex – such as in business-model development, or the inevitable wicked-problems of a social context – we need iteration and the like to explore the emergent context
• almost every business will face novel or unique elements within their context, and may struggle to avoid it becoming chaotic

So yes, it’s clear that Cynefin sensemaking should be of real value in EA.

There are a couple of other key elements to Cynefin: its theoretical base, and the interdomain ‘dynamics’.

The explicit formal base for Cynefin is ‘complexity science‘: Snowden is emphatic on this point. However, within Cynefin’s own terms, there are two important corollaries from this:

• the effective primary focus for Cynefin sensemaking is the Complex domain
• the focus on science (as opposed to a technology-oriented approach) will naturally pull the emphasis and methods of validation into the Complicated (analytic) domain rather than the Complex (emergent) domain

This implies that there’s an inherent methodological mismatch here, right at the heart of Cynefin. It’s a mismatch that, you may note, is made visible here via a recursive use of Cynefin sensemaking on itself – recursion being a true emergent-technique, yet not a ‘scientific’ one.

[I'll admit that I don't know the science behind the assertion that there are always and only these four decision-making domains: I believe it originally comes from Boisot. To be blunt, though, I'm beginning to doubt there is any fundamental science behind that partitioning of the 'Disorder' space: instead, as with most 'non-exact' sciences, it may ultimately come back to a combination of pragmatics and personal opinion. Useful, yes; but not necessarily 'the truth'.]

The interdomain dynamics are less well-known: it’s possible they may only appear in some of the earlier papers and in the training-course material, and may now be strictly proprietary to the Cynefin brand. In essence, they describe the tactics that we would use to move ‘between’ the decisionmaking domains. In some cases, it may seem that the context forces us to use specific tactics – which in effect also forces us ‘into’ a different domain, where other ‘rules’ than those we expect may now apply.

[For a non-proprietary equivalent of these 'interdomain-dynamics', from a significantly different yet comparable context, see the 'disciplines reference-sheet' that accompanies the book Disciplines of Dowsing.]

Because they may now be proprietary, I won’t go into any detail on the ‘official’ Cynefin-dynamics. Yet there are two ‘moves’ that are described in the earlier publicly-available papers that are especially relevant for EA, that relate to how we should ‘act, sense, respond’ in the Chaotic domain:

• take control (aka ‘the dictator’s move’), to force us into the Simple domain
• find a pattern, to move us into the Complex (emergent) domain

Within those research-papers, these are the only moves (i.e. ‘act’ in ‘act, sense, respond’) prescribed for the Chaotic domain: so in essence, the only decision-choices described in Cynefin for the Chaotic domain consist of getting the heck out of there. (The same can be seen in the much more recent HBR paper: the only examples given for the Chaotic domain can be paraphrased as either ‘take control’ [go to Simple] or ‘set up a crisis-team’ [go to Complex].) Which isn’t exactly helpful advice for when we do have to deal with the reality of uniqueness – which happens a lot in business, and just about everywhere else. We need something that can handle uniqueness as it is – which Cynefin explicitly does not give us.

There’s another worrying implication from those two moves. One of the moves – ‘take control’ – takes us back to an overly simplistic rule-based view of the context, which in real-world conditions will inevitably fall back into the Chaotic again. In other words, it’s not going to be viable. So the only ‘permitted’ move that will seem to be viable is to grab hold of something that seems a pattern, and move to the Complex domain of ‘probe / sense / respond’ – which, strangely enough, happens to be the preferred realm and focus for all usage of Cynefin. Yet Cynefin’s internal focus on the ‘science’ aspects of ‘complexity science’ will in turn tend to drag us into the Complicated domain of ‘sense / analyse / respond’, or even the Simple ‘sense / categorise / respond’ – otherwise known in the business context as ‘hard-systems thinking’ and/or Taylorism respectively, which we know are problematic for any real-world enterprise-architecture. Yet Snowden himself affirms that point, if in a somewhat misleading way, in this diagram from his online seminar on sense-making and complexity-theory:

Concept Lifecycles (© Dave Snowden / Cognitive Edge 2010)

Hence in effect Cynefin here may purport to take us to the Complex domain, but in practice seems to offer us only the choice of ‘take control’, which rarely works well; or a slightly more sophisticated form of ‘take control’, which also doesn’t work well. That’s not good… at the very least, it means that we need to be careful as to how we use Cynefin in EA practice, and constrain its natural tendency to force us to where we least need to be.

A final key concern revolves around whether the Cynefin frame can be used as a categorization-framework. Snowden has asserted here and elsewhere that Cynefin should never be used that way - and he frequently rails against anyone who might seem to do so. Yet oddly, that’s exactly how he himself often seems to use it: for example, the much-cited HBR paper ‘A Leader’s Framework for Decision-Making‘ [PDF] consists almost entirely of a set of descriptions of what happens ‘within’ each of the domains – in other words, a categorisation of contexts. There’s an inconsistency here of which we need to take note – it is important, as we’ll see later.

Context-space mapping

Context-space mapping is another sensemaking framework (or technique, rather) that, like Cynefin, focusses or relies on emergence. Yet it’s fundamentally different from Cynefin in its nature, approach and theoretical basis – which causes some confusion, perhaps especially for Cynefin practitioners. In terms of the SCCC categories:

• Cynefin is a Complex-domain technique with a fallback to Complicated or even to Simple
• CSM is a Chaotic-domain technique with a fallback to Complex

Cynefin’s explicit fallback is from ‘unorder’ into the ‘order’-domains (‘science’); CSM’s fallback is to the other ‘unorder’ domain (Chaotic to Complex). Unlike Cynefin, CSM always remains in the value-oriented ‘unorder’ domains.

[One corollary from that last point is that because CSM resides in the 'unorder'-domains, attempting to use 'order'-domain methods of validation does not make sense. Validation of the technique must always be in value-based terms: in other words, whether it is useful, not whether or not it is 'true' within the terms of some arbitrarily-selected system of 'order'.]

Even more confusing to Cynefin practitioners is the fact that CSM may legitimately use ideas and images and concepts from Cynefin, or any other source at all, in ways that could or would indeed be described as “illegitimate” if the process made any claim to ‘be’ Cynefin or the like – which it doesn’t.

[Therein lie some significant paradigm-problems, which I'd suggest are the real source for a vast amount of flak hurled in my direction by Snowden over the past few years. Oh well. I'll come back to the paradigm-problem later, anyway.]

First, before the demonstration proper, a few key points about how CSM actually works.

As with all sensemaking, the aim is to make sense of what’s going on in some specific context. (When we start off, the bounds of that context may not be very specific at all: perhaps just some vague idea or focus. Just call it ‘the context’ for now.)

By definition, we always start out on this journey because we don’t know something. This space of inherent-unknownness – prior to any sensemaking – is what Cynefin describes as ‘Disorder’, and what I sometimes prefer to describe as ‘Reality Department’. It’s why we do sensemaking: we want to make sense of something in the context that at present doesn’t ‘make sense’.

Some people might want to split that context straight away into ‘problem-space’ versus ‘solution-space’; but enterprise-architects especially will know well the dangers of jumping into ‘solution-space’ too early. So for now, we’ll leave it unpartitioned, and just call ‘context-space’.

A common response to anything unknown is make a map: pick up any fragments of information that we can, and see what they show us. In Cynefin terms, we could perhaps say that this moves us from Disorder into the Chaotic domain. What we need to be careful about, of course, is the old adage that “the map is not the territory”.

In terms of the Cynefin-dynamics, as above, we have two options in the Chaotic domain: ‘take control’ or ‘find a pattern’. This is a key point of divergence between Cynefin and CSM: Cynefin takes the first option, whilst CSM applies an inverse variant of the second option.

As often practised – and certainly as described in the HBR paper - the core Cynefin Framework is not a Complex-domain technique. (Whatever Snowden may claim to the contrary, the Cynefin-dynamics themselves make that point patently clear.) It is a Simple-domain technique, because it ’takes control’: it overlays its map onto the ‘territory’ of the context, and then declares that the map is the territory – or perhaps ‘the only true map’ of the territory, ‘true’ because it’s ‘based in science’ and the like.

At this surface-only level – again, typified by the HBR paper – this makes Cynefin very easy to use and to explain, and to train people in the relatively-rudimentary sensemaking that’s available through a Simple structure of categories, each of whose sub-descriptions have purported ‘truth’-relationships to each other. Commercially speaking, that simplicity is obviously a very desirable trait: but just how valid or usable the end-results would be is a very different question.

Of course it’s true that most of the deeper techniques used by experienced Cynefin practitioners – ‘butterfly-stamping’, ‘clustering’ and the like – are indeed rooted in the Complex domain: but that’s not what most people see or use. Instead, what most people see is just that Simple predefined set of categories and sub-categories – which leads directly to the over-Simple categories-only mistake about which Snowden rightly bewails.

Context-space mapping takes the opposite approach. We first accept the Chaos for what it is – we accept that we don’t know what’s going on. In keeping with the rules of the Chaotic, we throw something else in at random – and then see what happens. We’re not looking for ‘facts’ so much as insights or ideas, something we can use. We play with that for a while, seeing what ideas and images and patterns seem to emerge in relation to those insights – in other words, we move into what Cynefin calls the Complex domain. And whenever a thread seems to peter out, or ceases to be interesting, or whatever, we deliberately drop back into the randomness again. In that sense, context-space mapping is a Chaotic/Complex-domain technique.

In effect, what we do in context-space mapping is run the usual map-making process backwards. In conventional mapping, we pick on some element in the context that can be fixed in some way, either in absolute terms, or relative to some other point; we then keep repeating that process until we come to some usable description that can be described as ‘true’ in some sense or other. By contrast, in context-space mapping, we pick an arbitrary map, and place it into the Chaos of the context to see what coalesces around around that shape. It’s intentionally anarchic: in most cases, any map will do.

A useful metaphor here is that the context-space map acts as a ‘seed’ for crystallisation, with the ‘unknown’ of the Disorder space providing a kind supersaturated solution from within which new ideas and insights can coalesce. And we don’t necessarily expect that what arises will or must align itself to the map: in fact what we’re looking for most often is whatever doesn’t align. And to help that along, we will often deliberately create mismatch – ‘cognitive dissonance’ – in these throw-away ‘true’-only-for-a given-value-of-’true’ temporary maps that we use for this purpose.

The catch is that this kind of technique is highly dependent on skill and experience. It’s not predefined: everything depends on the choices that are made by the person doing the mapping. It’s not science - it’s technology.

[There's a radical difference there that many people miss. In a science the focus should always be on 'truth', on 'how it really works'; whereas in technology the focus is much more on 'value', on usefulness, on 'how it can be worked' - or perhaps even more on 'how it can be worked better'.]

That’s the bad news. The good news is that that’s exactly the kind of skills and experience that people in enterprise-architecture and suchlike do aim to develop over time – hence context-space mapping is a natural fit to EA, whereas a single-function framework like Cynefin tends to be very limited in its usefulness for our needs.

So let’s develop a real example.

Context-space mapping with Cynefin on Cynefin

What we’re going to do here is develop a context-space map that can explore the role and usefulness of Cynefin in sensemaking for the type of business-contexts that are the typical concern for enterprise-architecture, business-architecture and the like.

In context-space mapping, we typically start with some kind of diagram that we use as a ‘base-map’. In essence, as above, any map will do: there are vast numbers of different diagrams and model-types in use in enterprise-architecture and business-architecture and so on, and we could choose any one that, in the moment, seems to fit with our needs for a ‘throwaway’ context-map. (For example, the Enterprise Canvas model-type initially arose from a cross-map between Business Model Canvas, BPMN, Zachman and Viable System Model.) Since we’re talking here about Cynefin, the obvious choice is the Cynefin diagram itself – hence we’ll use the basic layout and categories of Cynefin as the base-map for this exercise.

We could just stick with that for a while, perhaps using that Cynefin base-map recursively to explore itself – applying Cynefin to Cynefin. That’s a form of context-space mapping in its own right – in fact that’s the means via which I derived many of the insights about Cynefin above.

More usually, though, we would overlay other models on top of that base-map, creating a cross-map that incorporates and contrasts often dissonant ideas. For this exercise we’ll use four distinct overlays.

[Note again that there's no 'science' to this choice - or rather, this is as per science as practised, as opposed to the cleaned-up, seemingly-logical but often somewhat spurious 'science-as-presented-for-public-consumption'. The focus for each choice of base-map and overlay is always on usefulness, driven by an intent to elicit meaningful insights - exactly as per the 'Idea' and 'Hypothesis' stages in the classic 'Idea / Hypothesis / Theory / Law' cycle in scientific discovery.]

The first overlay actually comes from Cynefin itself: the concept of ‘order’ versus ‘unorder’. In Cynefin, ‘order’ is usually described as applying primarily to the Simple and Complicated domains, whereas ‘unorder’ (a very useful term invented by Cynthia Kurtz) applies primarily to the Complex and Chaotic domains. Conceptually, order and unorder also align well with notions of ‘truth’ versus ‘value’ respectively. We’ll apply this as a spectrum horizontally across that Cynefin base-map.

For the second overlay we’ll use something that doesn’t seem to be addressed in Cynefin as such: the timescale in which we have to respond to events. (Cynefin tells as that we should ‘act, sense, respond’, etc, but doesn’t tell us how fast we need to do so.) For reasons that will become clear later, we’ll apply this as a spectrum vertically across that Cynefin base-map, from real-time at the bottom to infinity at the top.

The third overlay is about skill-levels and decision-drivers – see the Sidewise posts ‘10, 100, 1000, 10000‘ and ‘Where have all the good skills gone?‘ for more on this. This gives us the following mapping, cross-mapped to the four Cynefin-making domains:

• trainee (>10hrs): rule-based decisions [Simple]
• apprentice (>100hrs): algorithm and experiment [Complicated]
• journeyman (>1000hrs): guidelines and patterns [Complex]
• master (>10000hrs): principles [Chaotic]

The final overlay, about levels of abstraction, or, conversely, repeatability, will need a bit more explanation. The closest analogy is the four states or ‘phases’ of matter: solid, liquid, gas, plasma. There’s a spectrum of variability, of constraints, yet with explicit ‘phase-boundaries’ between them: entities in a solid are fully bounded, in liquid can move around within distinct bounds, in a gas are essentially unbounded, and in a plasma the boundaries of the entities themselves break down. In terms of how the constraints and boundaries operate, we could map those four ‘phases’ of matter onto the same terms as used for the Cynefin domains: Simple, Complicated, Complex, Chaotic.

There’s a spectrum there too, with explicit boundaries: but we can’t do a simple straight-line overlay onto the base-map as we did with the other two spectrum-overlays. Instead, we have to kind of bend it round to make it fit. And yet, when we look the end-result – the cross-map – it does all fit together well:

This gives us a map that we can now use to elicit ideas and suggestions about the context – which in this case is the Cynefin framework itself.

[Before we start that exploration, though, we need to emphasise one essential point: this is not Cynefin. It's not a 'non-standard version of Cynefin', nor a 'new version of Cynefin', nor actually 'an extension of Cynefin', and nor is it 'an illegitimate use of Cynefin', either. It's a context-space map that happens to use some aspects of the standard Cynefin diagram as its base-map - and that's all that it is. And it's laid out in this way because it happens to be useful to lay it out in this way: there's no claim whatsoever that that's somehow 'the truth' - which, by the way, also means that it doesn't make sense to declare that it's 'not the truth', either.

Since some people may still have missed this point, I'll say it again, louder: this is not Cynefin - it's a context-space map. They're not the same thing: don't get confused here.

Okay? Let's move on.]

What comes up for you when you look at that diagram? (“A mess”, some people might say? – fair enough, but bear with me for a moment, if you would?)

What comes up for you when you compare that diagram with the ‘official’ Cynefin diagram, earlier above?

The first and most obvious point is that they’re not the same. Good: that means there’s the potential for cognitive-dissonance there. That’s the whole point: that’s what we want – because it’s from that dissonance that ideas and images and cross-comparisons are most likely to arise.

I don’t know what comes up for you when you compare and explore those two diagrams: that’s up to you, that’s your sensemaking, not mine. We’re dealing with subjective ‘truth’ here, not a purported ‘objective’ ‘the truth’: what makes sense for you is what makes sense for you – and it may not make sense in that way to anyone else at all. In a quite literal sense, it’s none of my business.

But here are some of the things that I see when I do that cross-comparison. I’ll describe them in relation to each of those overlays, though not in quite the same order as above.

[Note again that this is merely what I happen to see - what 'makes sense to me', and so on. None of it purports to be 'the truth': it's only about insights that arise, nothing more than that. The difference here is, unlike with Snowden's unsupported assertion that this technique has no value, here you can see all of the steps via which I arrive at each insight. What we then might do in response to each insight is a different matter, of course.]

The order versus disorder overlay would probably be the least controversial for Cynefin aficionados: it’s in the original description, even if it’s rarely shown on the diagram as such. The mapping with ‘truth’ versus ‘value’ is useful, because it suggests that IT-systems and other processes that depend on a simple ‘true/false’ logic are inherently going to have trouble in the Complex and Chaotic domains – which is exactly what we see in real-world practice.

There’s also another way to interpret the Cynefin description of context-space (which doesn’t contradict the ‘official’ version, by the way). This is that if the ‘Disorder’ domain is, in effect, the whole of a context before we make any decisions about it, then the other four ‘decision-making’ domains can also be seen as the valid way to act on that aspect of the whole: every context will include some proportion for which we can use the Simple tactics ‘sense, categorise, respond’, another proportion where we’d have to use the Complicated tactics, and so on. Every context will contain some Simple, some Complicated, some Complex, and some Chaotic. In which case, any attempt to use, for the whole of a context, a system that can only work on ‘order’, on simple true/false logic, by definition it’s going to fail in Complex and Chaotic ways. Which again is exactly what we see in practice with disaster-areas such as IT-based ‘business-process reengineering’ and many of the ‘business-rules engines’ and the like. The visual simplicity of standard-Cynefin can be very useful here as a tool to help hammer home this harsh fact to the overly-IT-obsessed.

Note, by the way, that the graphic layout is significant here: we probably wouldn’t have been able to elicit these insights without using that specific layout. One up for the Cynefin domain-layout, then – even though it wasn’t designed to be used this way.

Next, let’s look at the abstraction/repeatability overlay, and cross-compare it with the skills-type/decision-guide overlay. These do map cleanly together: we can use rules in domains of high-repeatability, and we can use ‘trainee’ skill-levels to do that type of work – and so on for the other domains. (Yes, the domains are used here as categories: but that’s exactly how the domains are used and described in the Snowden/Boone HBR article.)

We now cross-compare this with the ‘domain-tactics’ from the original Cynefin diagram: ‘sense, categorize, respond’, and so on. This gives us the following table:

• trainee: rule-based decisions; sense, categorize, respond [Simple]
• apprentice: algorithm and experiment; sense, analyze, respond [Complicated]
• journeyman: guidelines and patterns; probe, sense, respond [Complex]
• master: principles; act, sense, respond [Chaotic]

Which for the most part again does make sense: a trainee would sense what’s going on, make a decision based on predefined categories, and respond in accordance with the respective rule. By contrast, someone with apprentice-level skills should start to be able to analyse what’s going on, and identify and act on the respective factors for the required algorithm. The journeyman skill-level fits well, too; yet for me there’s an odd sense that the master skill-level isn’t quite right. Come back to that later.

But there are a couple of booby-traps that aren’t obvious in standard-Cynefin. In fact one of them isn’t even that obvious here: that people often find rules Complex, and guidelines Simple – the opposite way round to this mapping. (There’s more on that in the post ‘A human view of Simple, Complicated and Complex‘.) So in a sense this mapping is ‘wrong’, and could perhaps lead us to seriously-wrong decisions in real-world practice – if we were working primarily with real-people in that context. If we think more in terms of that ‘truth/value’ spectrum, and therefore assign machines and IT-systems to do the Simple and the Complicated, reserving the Complex and the Chaotic for real-people, then the mapping actually is ‘correct’. Remember, though, that ‘right’ or ‘wrong’ really don’t make sense here: the only valid distinction is ‘useful’ versus ‘not-useful’.

The other booby-trap is potentially even more serious in the longer-term, and relates to skills-development in the context. To make sense of it, though, we also need a better grasp of the impact of timescale – hence we’d better turn to that first, and come back to the skills-problem later.

The cross-map with timescale is perhaps the most important of all, because it highlights what is to me a fundamental flaw in standard-Cynefin: its handling of inherent-uniqueness. Or more accurately, its lack of any usable means to handle uniqueness.

Remember that, in essence, Cynefin’s stated method of handling the Chaotic is to ‘get the heck out of there’. Snowden himself has said many times that we’re never in the Chaotic domain as such: instead, he’s said, we should always grab hold of some piece of information and try to make sense of it with some kind of pattern or rule – which would automatically move us into the Complex or Simple domain respectively.

In practice, though, this doesn’t make sense – unless, that is, we happen to use the term ‘Chaotic’ in a circularly-defined way that also doesn’t make sense in terms of real-world practice.

Where does that insight about standard-Cynefin’s paucity in the Chaotic-domain come from? Answer: it’s derived directly from that cross-map between the Cynefin domains and the timescale.

The timescale stretches from real-time (which we’ve placed against the base of the Chaotic and Simple domains) to infinity (which we’ve placed against the top of the Complex and Complicated domains). If we think about it for a moment, that mapping does make sense: one of the classic dangers of decisionmaking in the Complicated domain is ‘analysis-paralysis’ going on to infinity, and much the same happens too with experimentation – ‘probe, sense, respond’ – in the Complex domain. Going the other way, towards real-time, the practical point is that it takes time to do analysis and experimentation: so the closer we get to real-time, the more we’re forced out of the Complex and Complicated, and into the Chaotic and Simple. Yet Cynefin insists that the Chaotic domain doesn’t actually exist, or at least that we can’t do anything there: which means that – according to Cynefin – as time gets more and more compressed, the only possible option is that we go back to the Simple, where everything is strictly rule-based. Which isn’t what happens in the real-world. Oops…

What actually happens in the real-world is that we have analysts (Complicated) and experimenters (Complex) who need time to do their work – which is why we usually find them in the back-room, or somewhere ‘upstairs’, well away from the real-time pressures of the ‘front line’. Down at the front-line, we usually have rule-based systems (Simple), that may be IT, human or machine – it doesn’t matter that much here, that’s just an implementation-detail. And we also have people – usually not machines – with high skill-levels, who deal with the ‘exceptions’ and other uniquenesses and inherent-uncertainties that the rule-based systems can’t handle. That’s the Chaotic domain, as far as anyone in business is concerned. But that’s the domain that Cynefin insists doesn’t exist, or that no-one stays there for anything more the briefest instant: yet the reality is that that Chaotic domain is where anyone with ‘master’-type skills and experience will spend most of their time.

That Cynefin provides no means whatsoever to address this sensemaking-need in the Chaotic-domain, within that domain’s own terms, is problematic enough. Worse, though, Snowden’s required methods for use of Cynefin actively prevent us from addressing that need, because they insist that we shouldn’t be there when, plainly, we not only are there, but need to be there and stay there. We can’t ‘run away’: staying in the Chaotic-domain is what sensemaking in that real-time, often-inherently-unique business-context will demand. Hence I’m sorry, but that aspect of Cynefin is just plain daft.

[There's a real challenge for Cynefin to prove its value here: and, from the above, I don't think it can do so. There's no escaping the fact that, as it stands, Cynefin explicitly makes itself neither useful nor usable for any part of this sensemaking-domain - in fact for the entirety of what is probably the most important domain for business-sensemaking. But that's not my problem, fortunately, so best leave it at that for now.]

Anyway, back to that booby-trap around skills-development and the relationship to timescale. Almost every business will face relentless pressure to shorten turnround times, product-development times, any kind of time-period: in other words, a constant push to compress down towards real-time. The cross-map between timescale and the Cynefin base-map shows us what will happen if – or more likely when – we push that process too far: the Complicated and Complex domains – analysis and experimentation – slowly get squeezed out of the picture, until there’s nothing left. And yes, the business probably can keep going for a while – as long as nothing changes. Even then, the pressures and lack of analytic or emergent backup will cause more and more exceptions, creating more and more overload in the Chaotic, until it finally collapses in a literally-chaotic heap. In other words, that cross-map not only shows us that excessive time-compression is a guaranteed way to kill the business, but also shows us exactly how and why it will happen – and hence the warning-signs to watch for, in case the risk gets too high. That’s a very important point that comes straight out from this cross-map.

If we now add to this picture the cross-map to the skills-development sequence – trainee, apprentice, journeyman, master – we can now highlight the real longer-term booby-trap. Remember that in that time-compression we squeeze out the Complicated and Complex domains. In doing so, we also squeeze out the support for the Apprentice and Journeyman stages of skills-development. The result is that we risk creating a context staffed by people with Master-level skills – doing all the Chaotic-domain work – and people with Trainee-level skills – doing all the Simple work – and no means to develop the trainees’ skills to become the next generations of masters. (There’s more detail on this in the Sidewise post ’Where have all the good skills gone?‘) This is a huge kurtosis-risk for almost any organisation – and yet very few people seem to have acknowledged even its existence, let alone just how serious it really is. So again, this is another very important point that comes straight out of the cross-map.

Finally, there are some disturbing intimations of potential for misuse. These arise from specific points in the cross-maps above:

• Cynefin purports to be a Complex-domain technique, and hence explicitly aims to address true complexity and unorder
• its purported base is in complexity-science, which tends to place it more naturally within the order-domains (particularly the Complicated domain)
• certain key aspects of Cynefin techniques – such as category-selection for filtering in Sensemaker – by definition derive from value-based decision-making (unorder), yet still purport to be ‘scientific’ (order)
• the purported ‘scientific’ base tends to give a spurious sense of ‘fact’ or ‘truth’ (order) in contexts which, by definition, are actually value-based (unorder), subject to arbitrary personal interpretation – a point not acknowledged at all in the basic Cynefin-framework diagram, and barely hinted at in public presentations such as the HBR paper
• most people see only the Cynefin diagram and other base-level categories and cross-maps, which would naturally place it within the Simple domain – yet it purports to be about sensemaking in the Complex domain

Other related concerns not covered in cross-maps above include the way in which the statistical modelling within the SenseMaker tool can give an illusion of working with uniqueness – ‘outliers’ – yet without actually working with the Chaotic-domain in its own terms, as ‘act / sense / respond’ in real-time. In effect, such use of Sensemaker veers dangerously close to ‘Complex masquerading as Chaotic’ – which is not helpful to anyone.

If we put that together with those other points above, which – as we’ve seen earlier – tend towards ‘Complicated masquerading as Complex’, or even ‘Simple masquerading as Complex’, what we’re left with is a framework whose domain-boundaries and discipline-boundaries are almost too blurred and confused to make much sense to anyone, other than perhaps its original creator. And that blurriness of the boundaries also means that many (most?) of the standard checks on safety, professional-discipline, ethics and the like are either unusable, actively blocked or entirely absent – in other words, it’s inherently wide-open for misunderstanding or misuse.

And it’s clear that such misuse could be both unintentional and, unfortunately, intentional. Given Cynefin’s current structure and presentation (as in the HBR paper), it’s all too easy to present something as ‘true’, and then jump around between domains to avoid any challenge. As it stands – to be blunt – the framework is structured in such a way as to make it all but perfect for (mis)use by a consultant who wanted to pander to the fears of worried executives, and provide them with spurious ‘evidence’ that they’re ‘in control’ of something that, by definition, cannot be controlled. To say the least, that’s not good, for anyone: and yet at present that temptation is built right into the very fabric of the framework…

One of the easiest ways in which such misuse can occur is if the framework is presented as a Simple categorisation: hence, I presume, one very good reason why Snowden is so adamant against anyone using the framework in that way – and I do applaud him for that. It’s true that that overall ‘blurriness’ can be helpful, in that it does enable some undoubtedly-useful workarounds in practice; but it also means that usage of the framework needs much more active ‘policing’ than would otherwise need to be the case – and whilst Snowden may be willing to take on that task at present, that inherent fragility means that it will always be an uphill struggle, always somewhat fraught. And behind it all, there still remain those serious ethics-risks – arising from the structure itself – that cannot and must not be ignored.

A difference in paradigm

I suspect that much if not most of the ongoing unpleasantness around Cynefin and context-space mapping has arisen from a clash of paradigms.

Snowden is explicit that he places himself within the scientific tradition, the domain of ‘provable truth’.

I don’t. Almost all of my work is in the technological tradition, the domain of ‘proof by usefulness’. Where the scientific tradition would focus solely on ‘truth’, the primary driver here is effectiveness – which I usually summarise via the keywords efficient, reliable, elegant, appropriate, integrated.

The unorder-domains do have their own ‘truth’ – but it’s a fundamentally-different type of ‘truth’ to that which applies in the order-domains. In fact, each of the SCCC domains has its own distinct form of ‘truth’. And the key point here – too easily missed by too many people, it seems – is that these different types of ‘truth’ don’t mix. For example, I’ll freely admit that some aspects of CSM do have significant similarities with something as ‘unscientific’ as a deck of Tarot cards, because we choose images that are ‘information-rich’, to allow appropriate insights to arise from the ‘chaos’ of intentional cognitive-dissonance. The point is simply this: it works – and the fact that it’s supposedly ‘unscientific’ doesn’t matter in the slightest in this context. (Yes, it might well matter in other contexts, but that’s the point: it’s context-dependent.) We know the conditions under which it works, and which it doesn’t – in other words, it’s a technology. In this particular case, it’s a known, proven technology for working with uniqueness in the Chaotic-domain, where, by definition, no ‘science’-based model is going to work.

But the problem I’ve had, time and time again, from Snowden and other ‘science’-oriented folks, is that they’ve attempted either to apply ‘scientific’ forms of validation – which, by definition, does not and cannot make sense – or else, as in this example, they’ve fallen back to various forms of unprincipled-attack. Neither of these type of tactics are helpful, to anyone. What is needed is solid, rigorous challenge in technological terms – without getting lost in spurious non-’science’.

My real focus here is meta-methodology – the methods and methodologies for developing methods and methodologies. To be blunt, I’m still not sure that Snowden understands the difference: in fact many of his attacks over the years only make sense if in fact he doesn’t understand that point. If one can’t tell the difference between a framework such as Cynefin, versus a metametaframework such as context-space mapping, then clearly nothing much is going to make sense. Either way, the difference in paradigms is enough to cause serious friction in itself: but in practice, all we should need do is take note of that fact, respect that the paradigms are indeed different, and move on.

A practical summary

Okay, I know it’s been long, but I hope it’s been worth it: in any case, thanks for sticking with it this far. All we have to do now is wrap this up, and then we’re done.

The wrap-up is really simple, consisting of just one question: in reading this, did you gain any insights about Cynefin, or about context-space mapping, that you didn’t have before?

If you gained no insights at all – no new information, no new thoughts about how to use either of those two tools or techniques, or anything else – then Snowden has a fair point: context-space mapping is of little value to you.

But if you did gain any insights, of any kind – perhaps not even about either of these two tools – then context-space mapping does have value, for you at least.

Yet you and your experience here are the judge of this: the only judge. The only ‘truth’ here is yours.

Perhaps let me know your results in this?

Thanks again, anyway.