9 years, 4 months ago

A human view of Simple, Complicated and Complex

Link: http://weblog.tetradian.com/2011/10/08/human-view-of-simple-complicated-complex/

What is simple, complex, complicated, or chaotic? And from whose perspective?

For a long time now I’ve been using those context-categories – often referred to as the ‘Cynefin-categorization’ – with a straightforward cross-map to levels of repeatability, somewhat analogous to the states or phases of matter:

Although we do need to be wary of misusing the proper Cynefin framework, it can be valuable to use the common Cynefin-style sort-of-cross-grid depiction of those categories as a base-map for context-space mapping. This example, from an earlier post here on business-rules, cross-maps those categories with repeatability, timescale and logic-modality (‘truth’ versus ‘value’):

Time, interpretation and abstraction

That spectrum of ‘levels of abstraction’ here is about the way in which various assumptions about ‘how the world really works’ are a kind of overlay or ‘abstraction’ on top of actual reality. Rules (‘high abstraction’) overlay many assumptions onto reality – and often the most fixed assumptions, too – whereas principles (‘low abstraction’) are much more fluid, more a choice of how to interpret rather than an assertion of ‘truth’.

(In case anyone’s concerned, this is not Cynefin – it’s just a routine ‘mashup’-style diagram for context-space mapping, where we intentionally mix and cross-map different and perhaps nominally-incompatible schemas as a way to generate potentially-useful ideas and views about some context of interest. The Cynefin frame is a useful base-map for this, but there are many other base-maps we can use – see Everyday Enterprise Architecture for more detail.)

So anyway, as in that diagram, I’d long since ended up with a fairly fixed view about the relationship between different types of context, and the kind of guidance that we use to work with each context:

  • Simple: rule-based
  • Complicated: algorithms
  • Complex: patterns and guidelines
  • Chaotic: principles

Hence, for example, that’s the mapping that I used in reviewing Nigel Green’s cross-map of application-types, in my recent post ‘What can we simplify in enterprise-architecture‘.

All of it a safe set of assumptions that we can make about the nature of reality. Simple, straightforward, obvious. Or so I’d thought…

(Yes, you can see where this is heading… :-| )

What finally woke me up from my metaphoric slumber was the following, from my futurist colleague Marcus Barber, in a comment to the ‘What can we simplify’ post:

Thanks for the article – some thought bubbles for me are

  • Simple: ‘guidelines’
  • Complicated: ‘Rules based’
  • Complex: ‘Algorithms’
  • Chaotic: ‘patterns and non patterns’

As the user, simple is what works without me needing to think too heavily about it – ‘rules’ rarely allow me to do things simply, though they may simplify by offering me a checklist to follow. That makes them structured but not simple. So a guideline would be something that works generally well enough for me not to have to think too hard as a user and fits in with your idea about simplification being addressed in different ways

Complicated therefore embraces the rules structure as in ‘if this, then that’ and ‘if not this, then that, or that or not that’

Complex – for the algorithms, is where as a user, my head hurts. In this space I sense that complex means that what ever is happening is knowable to me, and that I’d need much effort to gain a serious understanding

Chaotic is for a user where sometimes I see a pattern, sometimes I don’t. Only the very few would discern the potential what and how from amid the morass of outputs.

My first response was “He’s wrong!”, followed by a slightly-more-honest “Why is he wrong?”; and then the blaring realisation that it’s not wrong at all, in fact it’s very right – and that what had been ‘wrong’ was my too-simplistic and perhaps too-smug certainty on this… oops… :-|

It gets worse. Here I am, frequently railing against IT-centrism and the like – yet that simple mapping of ‘simple = rules’ etc is actually just about as IT-centric as it can get. By contrast, Marcus’ mapping actually is a human-oriented view into the Cynefin-categorization: no doubt about it.

Hmm… oops… :-|

(For what it’s worth, I suspect that the ‘official’ Cynefin view is somewhere between those two views, but that’s something for Snowden to describe, not me. I do know that many IT-folks use the term ‘Complex’ in a way that at first can look similar to Marcus’, but more as ‘very-Complicated’, ‘things we should be able to control but haven’t found the right algorithms for yet’ – which I still do believe is misleading, because it doesn’t allow any space for inherent-uncertainty, but that’s just me, I guess…)

Machines find repeatable rules easy to follow, and non-repeatability impossibly complex; whereas real people often find a rule-laden environment all but impossible to bear, yet may well thrive on the uncertainty and unrepeatability of ‘chaos’. That’s a very important distinction of which we do need to be aware.

If we don’t take enough notice of that distinction, we end up with something like Taylorism’s ‘scientific management’ or a feudal-style ‘command-and-control’ culture, which only ‘succeed’ through requiring people to act as literally robotic machines. Which, yes, those people can do – but as Deming and others demonstrated, it’s almost the least-effective way of using people’s abilities in a work-context. (So much so that ‘work-to-rule’ has long been used as a form of workers’-protest – because it really screws things up, yet in a way that can’t be challenged by ‘the bosses’…)

All of which has huge implications for enterprise-architecture and the like. For example, a mismatch between what IT-folks would think of as ‘simple’, versus what people doing the work would regard as ‘simple’, would lead directly to the kind of process-redesign disasters that we saw so often in business-process reengineering. People can navigate their way quite easily through the myriad of minor variations in a typical real-world business process; but for a rule-based IT-system those same variations can quickly become an impossibly-complicated mess of exceptions on exceptions on exceptions to the supposedly-simple ‘business-rules’. There’s a major task of translation needed here, one that’s all too often missed or ignored: hence Nigel Green’s book Lost In Translation, and the VPEC-T framework that it describes.

And we’ll need the same kind of translation, but in the opposite direction, for most planning and design for business-continuity and disaster-recovery, where people need to take over the tasks of out-of-action IT-systems. Expecting people to follow the exact same ‘business-rules’ as an IT-box might not only be nearly impossible in practice – way too much ‘picky-petty-detail’ for almost anyone to remember – but would also be incredibly inefficient and ineffective. It’d be much more effective instead to trim all of those business-rules down to a much simpler set of principles and priorities, matching more closely to the way that real people really work – and then use skills-development and governance to clean up any rough edges at run-time and beyond.

That’s what’s obvious – when I remember to use my own tools on my own thinking, that is… Oh well… :-)

So there’ll be a lot of options and ideas to explore there: Simple may not be as simple as it looks, and Complex may not be so complex, either. A point well worth pondering a bit more, I think?