Sense, make-sense, decide, act

A bit more on methods for whole-enterprise architecture – and for many other domains, for that matter.

We can summarise the suggested core-method for whole-enterprise architecture as follows:

We need to take some care around keeping it simple, and maintaining clarity about meanings for the phase-labels, but otherwise it’s usable for any scope, any scale, any context, any content, across any iteration-timescale, fractally, from a few years down to a few minutes.

Below that kind of timescale, though, even this structure starts to get a bit cumbersome… – in essence, it’s a set of emphases to apply within assessment and the like, rather than the means of assessment itself.

To understand what’s really going on – and how to do it better – we need to dig a little deeper into the underlying processes for sensemaking and decision-making. Again, this needs to be fully fractal, but this time right down to much tighter timescales, from minutes to seconds to sub-seconds and even below.

The grand-daddy for this is probably John Boyd’s ‘OODA‘ – Observe, Orient, Decide, Act:

It’s often referred to as ‘the OODA loop’, but in practice that can be dangerously simplistic, misleading people into thinking that there’s only one single-level loop, repeated step by step, mechanically. Instead, we need to see it more as a meshwork of intersecting, interdependent loops, all of them fractal in nature – as per Boyd’s diagram above. (Haeckel’s ‘Sense, Interpret, Decide, Act’ sense-and-respond cycle is somewhat similar – a point we’ll return to later here.)

To get at what’s really going on, it seems useful to build a series of crossmaps.

First, we take the SCAN sensemaking / decision-making framework, which in this example maps typical tactics for sensemaking and decision-making (or, in OODA terms, Orient and Decide) against time-before action on a vertical-axis, against certainty / uncertainty or predictability / unpredictability on a horizontal-axis:

Next, we take the sensemaking / decision-making paradigm-archetypes from the ‘swamp-metaphor‘:

And then crossmap those two frames together, to outline where the paradigm-archetypes tend to be used within the relative timescales and complexity-levels within sensemaking and decision-making:

Then crossmap all of that to the SCAN edge-transitions:

And finally crossmap the basic structure of OODA onto that fractal pattern – which gives us something like this:

Which shows us quite a lot. I won’t go into the full details here, but some key examples we might note:

— We describe the sequence as ‘Observe, Orient, Decide, Act’, but Observe is actually in the past – identifying the outcomes of the previous iteration – whereas the next phase, Orient, is the first that is actually in the future, as a prelude to Decide and thence to Act. This ‘back to the future’ change of direction is one of the key determinants for the effective speed of the overall cycle.

— Whenever there’s uncertainty, there’s often a fair bit of back-and-forth between the different archetypes – particularly the horizontal pairing between Scientist / Complicated and Technologist / Ambiguous. (Any real-time back-and-forth between the Believer and Artist archetypes must somehow transition each time across the ‘edge of panic’ between Simple and Not-known – a fact that often makes that necessary back-and-forth a whole lot harder…)

— Although many sort-of decisions may occur earlier, the key Decide takes place on the respective boundary between plan and action (the green dashed-line on the vertical-axis). This Decide feeds rules to the Believer-archetype, to Act in Simple (predictable) contexts; and/or principles to the Artist-archetype, to guide each often-unpredictable Act within the inherent-uncertainty of the Not-known.

— By definition, Act always occurs at the moment of ‘NOW!’ – though note that each apparent ‘NOW!’ is itself made up of an infinity of other ‘NOW!’-moments, fractally, and always moving forward.

— Only Observe has any chance of being real – though even this can be somewhat subject to ‘echo-chamber‘ filtering, ‘policy-based evidence‘ and suchlike. Everything else relates to an imagined future, and by definition is inherently subject to assumptions, cognitive-bias, hype, wishful-thinking and more.

Yet let’s stop for a moment, pull right back, and, whilst acknowledging that all that underlying richness and complexity is still there (and needs to be there), we can reframe the model with simpler and more accessible terminology, as sense, make-sense, decide, act (SMDA) – in effect again starting at the outcome of the previous iteration, with Sense:

It’s still much the same as OODA, yet without being dominated by the latter’s overt complexity. It’s perhaps even closer to Haeckel’s SIDA, ‘Sense, Interpret, Decide, Act’. Yet there are key distinctions from this reframe that are useful to emphasise here:

— Sense is more than just ‘Observe’ – it must include looking inward at the inner, personal, subjective world, every bit as much as observing the nominally-‘objective’ external-reality.

— Make-Sense is more than just ‘Orient’ or ‘Interpret’ – in addition to orienting or interpreting what is sensed in terms of the believed or known, it must often also find some way to create sense from the new or unknown.

— Decision is more than selection of options from an hypothesis – it is often deeply fractal, sometimes more like deep-iteration around a chaotic-attractor in a fitness-landscape, than a Simple-style Yes/No choice.

— Act is more than a single testable moment – as with Decision, it is often deeply fractal, and also across all of the asset-dimensions and decision-dimensions that apply within the respective context.

(Beware also of possible confusion with similar-seeming decision/action-cycles such as PDCA (‘Plan, Do, Check, Act’) and the later PDSA variant (‘Plan, Do, Study, Act’). The ‘Act’-phase in this cycle, and in OODA and SIDA, actually aligns more with the ‘Do’-phase in PDCA/PDSA; whereas the ‘Act’ in the latter pair is sometimes more accurately described as ‘Adjust’, because it’s more about changing the underpinnings for Orient / Interpret / Make-Sense, to create different and more ‘on-purpose’ decisions and actions (‘Do’) in subsequent iterations of that cycle.)

Remember too the fractality here. One side-effect is when we’re assessing one larger-scale SMDA iteration, other smaller-scale iterations are likely to be happening ‘within’ it. This includes those where the whole iteration takes place ‘below the line’ relative to the action-decision for the iteration that we’re assessing – other words, where sensemaking and decision-making become blurred with the action itself:

Where the iterations are too tightly linked, in part this is how sensemaking and decision-making can both be driven by unchecked assumptions and the like. To truly make sense of something, we need always to be able to move ‘outward’, ‘above the line’. The catch is that doing so usually requires time for such more considered-sensemaking to take place – time which may not be available under the pressure of real-time action…

For machines and most current computer-based systems, the SMDA loop can work reliably and well only when it’s applied via the certainty-oriented side of the SCAN ‘boundary of effective certainty’, with sensemaking and decision-making guided by certainty-based algorithms and business-rules:

Humans can of course emulate the sensemaking and decision-making processes of machines – though they’re usually not as reliable or as fast at doing so as machines are:

Unlike machines, humans can also do sensemaking and decision-making over on the far side of the ‘boundary of effective-certainty’ (the red dashed-line on the horizontal-axis of the SCAN frame) – able to work with ambiguity, uncertainty and the unknown, with sensemaking, decision-making and real-time action all supported by guidelines and principles:

However, in tightly-regulated or rule-bound contexts – such as in Taylorist-type organisations dominated by hierarchical ‘top-down’ decision-making – those people are in effect constrained to act no different from machines. The result is that all of the advantages of engaging humans in the work are lost, whilst keeping all of the disadvantages, limitations and fragility of the machine-only model – perhaps Not A Good Idea…?

We can just about get away with that kind of constraint and, bluntly, stupidity in purely robotic work – though that type of work is best done by machines anyway, wherever we can. But in knowledge-work we must be able to call upon any and all of those swamp-metaphor archetypes; we must be able to apply any and all of those SCAN tactics, both ‘above the line’ and ‘below the line’ – because it’s only way in which we’ll be able to cover all of the needs for action within the overall context-space. In short, we must be able to allow people to be people, working with the real-world as only real people can:

Remember too that, by definition, each Act takes place in the travelling-NOW – whereas Decide and Make-Sense both take place at some distance from that respective NOW. And the greater the distance from that NOW, the greater the risk that the sensemaking on which decisions should be made will get lost or filtered-down or reinterpreted by the fractality of other sensemaking and decision-making closer to the point of action. In practice, ‘above-the-line’ or ‘considered’ decisions will not be Acted on unless there’s some way to repackage them as real-time ‘below-the-line’ Decisions – hence the very real importance of work-instructions, rules, checklists, guidelines, principles, vision and all the rest, and the means by which ‘above-the-line’ decisions can be converted into those ‘below-the-line’ forms.

And finally, no, this SMDA cycle doesn’t claim to be a replacement for OODA, SIDA, PDCA/PDSA or any of the other well-known frameworks, or ‘better’ than any of them: it’s just another potentially-useful way of working with the same overall kind of context-space – nothing more than that.

It does provide a useful crosslink with SCAN and suchlike tools for sensemaking and decision-making in whole-enterprise architectures, and it does provide clarity about what happens (or needs to happen) in the fine-detail of the suggested Five Element core-method for whole-enterprise architectures. But that’s about it, really – yet hope it’s useful, anyway.

Over to you for comments and suchlike, if you wish?