A human view of Simple, Complicated and 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’):
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?
Tom, whilst I don’t think this was your central concern, I think you did a very good job of explaining why some things (in particular dealing with uncertainty) are done better by people than by computers and that, if we are going to use computers, we need to question very seriously whether rules-based systems are the way to do it. What we do, however, need to watch out for is the tendency to try to make people follow rules based systems, which of course is a direct consequence of the Taylorist approach. And of course that tends to be popular with managers because it’s easier to monitor. Which I hope provides a nice segue back into your recent work on management.
One last thing: in the IT community concerned with the management of business processes, I detect an interesting shift away from “orchestration”, which is more or less rules based and rather inflexible (or exceedingly complex) towards “choreography”, which is more cooperative and thus more suited to the extended enterprise. I put those terms in quotes, because I find the metaphors misleading and want to be clear I’m referring to how they are used in BPM. Peter Bakker wrote some interesting stuff around the use of Petri nets in this context recently, which I’m not competent to explain properly. So that’s a cue for Peter…
@Stuart Boardman
Oh dear, I have a cue but not a clue what to do with it 🙂
Stuart I guess you are referring to the unbundling pattern and the Fit element I used in my prototype at http://peterbakker.wordpress.com/tubemapping-the-enterprise/unbundling-nestle-and-nespresso-simulation/ ?
I’ve not much knowledge about BPM other than reading the book Modeling Business Processes A Petri Net-Oriented Approach and some articles about Process Mining from Wil van der Aalst. I just checked the book but it doesn’t contain any references to orchestration or choreography.
In any case my Fit element is about integrating values supplied by service providers into a new (added) value that can be supplied to service consumer. The Fit element is always (in my prototype anyway) connected to the Customer Relation element of the service provider (which bundles the Channels and the Customer Relationships building blocks from the Business Model Canvas) to emphasize that it is an activity that can/will be done in cooperation with the service providers.
I’m not sure if this is the same as choreography but it is certainly different from service orchestration.
Tom I don’t want to get into an argument, but several people have asked me about this post. So for the record:
– the only person I know who talks about the “Cynefin-categorisation” is you, so “often referred” is a bit of a misnomer
– Cynefin can be used as a categorisation framework, but if so then disorder (the central domain) is critical so there are five categories. AND …
-… Chaos in Cynefin is always a transitionary domain, either entered catastrophically (which is why the boundary with simple is drawn differently) or as a phase shift from complexity or via disorder.
-And if course, used properly Cynefin is a sense-making framework not a categorisation model but that is a wider subject
We can agree or disagree whether your drawing is a mashup or a hash-up! However I just want to note the differences – and thanks for making it clear its not Cynefin. I agree with your last paragraph by the way – its an important point
@Stuart Boardman – Stuart: thanks, and agreed re “some things are better done by people than computers” – and we’ve all seen disastrous attempts at BPR and the like that have failed to understand that point. What interests me more in this case, though, is where we don’t have much choice about it: for example, if the IT system goes out of action, and we still want to be able to run the business of the business, we have to be to swap people straight away into doing the same role that the IT usually does (and swap back again when the IT comes back online again). What this cross-comparison suggests is that the way that we need to handle ‘business-rules’ and governance and quite a lot more would need to change, too, over and above just the raw change of process-implementation – which would be a very significant point in business-continuity/disaster-recovery planning.
Re ‘orchestration’ versus ‘choreography’, I’ll admit that I don’t actually see much difference between: they’re essentially the same term applied to two different artforms – music and dance respectively. (Though, yes, the prospect of seeing more people dance whilst they work does have a definite appeal… 🙂 ) In both cases we’re usually dealing with multiple activities happening at the same time, distinct from each other yet interweaving with and through each other, such as the multiple ‘parts’ of a music-score, or the movements of individual dancers or groups of dancers. The more important difference – and the one I presume you’re actually alluding to? – is between something more constrained or predefined, versus more freeform and improvisational: and that distinction isn’t actually implicit in the difference between the two terms. So yes, we do have to be cautious about taking a metaphor too far…
On Petri Nets, I will likewise have to defer to Peter: I still know almost nothing about them, and what I do know, I mostly learnt from him! 🙂
@Peter Bakker – Peter, about all I can say to this is “More, please?” The work you’re doing on that ‘unbundling’ thought-experiment looks like it’s going to be very valuable indeed: do keep us informed on it, if you would?
@Dave Snowden – Dave, thanks for joining in: and I too am extremely keen to avoid an argument, as I hope you can see from the care with which I address any unavoidable references to Cynefin or the ‘Simple, Complicated, Complex, Chaotic’ category-set.
It’s quite possible I’m the only person who refers to the ‘Cynefin-categorization’. I use the term mainly when someone else in my field – Nigel Green, in this case, but quite a few others over the past few weeks – uses the term ‘Cynefin’ in a way which does not conform to your required standards. (In Nigel’s case, as in some others I’ve seen recently, a 2×2 grid has been used, which I’m acutely aware is anathema for Cynefin proper.) In other words, I’m working very hard to make sure that when someone in EA or related fields refers to ‘Cynefin’, they either use the proper version (i.e. as a sensemaking framework, rather than ‘just a bunch of categories’), or else make it clear they’re just using the domain-labels (usually only four of the five, as you say) for some other purpose that’s not actually related to Cynefin-proper. So I am trying to help you in that regard – and I do appreciate that you do seem to acknowledge this a bit more these days.
I’m not sure whether your ‘Chaos’ comment relates to the theme of the post, or in relation to Cynefin-proper? If the latter, yes, I agree, and as I’ve said above and elsewhere, people do need to refer to you for any definition or interpretation on that. But as you’ll see from the content above, and even more from Nigel’s post, the ‘Chaos’ being referred to here is significantly different – closer to non-pattern chaotic forms such as irrational-numbers (e.g. digit-distribution in pi) or nuclear-fission or true white-noise or (particularly important in EA) triggers for eventuation of kurtosis-risks. It’s the same term – ‘Chaos’ – and, scientifically-speaking, an equally-correct usage of the term: but it does happen to be different from the usage in Cynefin. That’s why, again, I go to some trouble in these posts and elsewhere to help others understand that if they use ‘Chaos’ and ‘Cynefin’ in the same breath, they need either to apply your usage, or make it clear that it’s this other usage that they mean – in which case, yes, it should not be called ‘Cynefin’. It’s the latter (non-pattern) usage that tends to be most common in EA and related fields.
“Used properly Cynefin is a sense-making framework not a categorisation model”: yes, exactly – I fully understand and agree with that. That’s why I’m very careful to make it clear in my own posts, and to others, that whenever the category-set ‘Simple, Complicated, Complex, Chaotic’ is used other than specifically in terms of Cynefin sensemaking, the term ‘Cynefin’ should not be used. Since people do insist on calling that category-set ‘Cynefin’, or ‘based on Cynefin’, I do make it clear each time, to every person, that it’s only the categories that are being used – not Cynefin-proper. Hence the term ‘Cynefin-categorization’.
The practical problem is that that category-set has been around a lot longer than Cynefin, and in use in many other disciplines before and, more recently, in parallel with Cynefin: and being realistic, we can’t prevent every other possible usage of that category-set solely because they happen to be used in a different specific way in Cynefin. In respect to how most people in the broader context tend to use those terms, it’s Cynefin’s usages that would have to be described as ‘non-standard’ special-case: hence it’s both unfair and unrealistic to expect everyone else to force themselves to throw away all of their past practice and re-align to your definitions just because it would make your professional-life less complicated if they did. The other related problem is that when people come across that category-set from a different usage or context, they tend to say “oh, it must be Cynefin” – which of course it isn’t. Hence why I’m doing as much as I can to intercept any sources of confusion – much of that work on your behalf, I might add.
A gentle request: if you truly dowant to avoid argument, you could perhaps not throw in unwarranted backhand-putdowns about “mashup or hashup!” and the like? You know, you could be a bit more polite, and acknowledge that whilst you have your own way to do sensemaking, that does not automatically make all others invalid? Oh well: your choice, of course.
But thanks, anyway.
@Tom G
For the difference between ‘orchestration’ versus ‘choreography’: http://en.wikipedia.org/wiki/Service_choreography#Service_choreography_and_service_orchestration
Reading this I think my Fit element is orchestration nor choreography…
I will keep you informed about my unbundling thought-experiment although I’m running it a lower pace (at the moment paused because of my temporary shifted focus on conceptual vs. factual architecture and some heavy reading about visual semiotics…)
Tom, the complicated-complex distinction has been around for a bit and is best expressed by Cilliers as the difference between an air craft and a mayonnaise. Simple, Chaos etc are all terms in common use. There is no particular reason to refer to them as Cynefin-categories and I’m not sure why you do, especially as there are five Cynefin categories not four. But I’m not complaining, I just posted to put the record straight on what Cynefin is.
As to the gentle request, I put humour on/off tags around the mashup or mashup comment, but I think they got lost as fake HTML. Nothing in that comment or anything else could possibly imply a view that I view other approaches to sense-making are automatically invalid. But I am entitled to the view that yours is in certain essential aspects.
@Dave Snowden Dave – my apologies, I was foolish enough to forget who you are and how you behave, foolish enough to forget why I blocked you from this site, and foolish enough to think that for once I would have a chance of a professional-level discussion with you that does not seem to consist primarily of you seeking one way after another after another after another to demean and denigrate both me and my work.
Oh well. Your choice. Let’s just leave it at that.
To satisfy your stated need regarding any mention at all of the ‘Cynefin’ term, from now on I will use and will recommend to everyone else that they use a separate term such as ‘SCCC’ or ‘SC3’ (i.e. acronym of Simple Complicated Complex Chaotic) for that categorisation. I will likewise advise anyone I see using the ‘Cynefin’ term to be careful to use it only in the specific sense that you desire, or to use an alternative term such as ‘SCCC’ instead.
In regard to my interactions with you, I turn to Bob Sutton’s tests from his book ‘The No Asshole Rule‘:
“Two tests are specified for recognition of the asshole:
1. After encountering the person, do people feel oppressed, humiliated or otherwise worse about themselves?
2. Does the person target people who are less powerful than he?”
That’s how feel after every interaction with you. In most cases – as with both of your comments above – I am left with a debilitating sense of dread that usually takes at least a day to shift. I have no idea whether that’s the effect that you intend – and likewise I make no assumptions or assertions about that – yet that is the effect that you have on me every time.
I need to protect myself from this: we’re now back to where any interaction with you at all is costing me days of productive-time that I can ill afford to lose, especially as the many people who do value my work lose out as well.
So I’ll keep things simple, and re-invoke Bob Sutton’s rule: avoid any interaction whatsoever.
Hence back to where we were: of necessity, all emails from you will be deleted, and all comments by you to this website will be blocked. On my side, I will seek to avoid any references to you or to Cynefin, throughout my work and correspondence with others, and likewise advise all others in this industry to do the same, so as to give you no reason to need to come here.
I’ll have to trust that you’ll respect this – especially as in the longer term it’s for your protection as much as mine.
Thank you.
[A brief note: having been explicitly requested not to comment further, Dave Snowden did indeed send in yet another denigratory comment. As previously notified, that comment has been deleted, as will any further attempts at communication from Snowden. I am holding strictly to Sutton’s ‘No Asshole Rule’ on this point, and to be frank I recommend everyone else to do likewise.]
@Tom Just a quick response. Yes, you got the distinction I wanted to make dead right. I didn’t invent the usage of the terms orchestration and choreography in BPM and don’t like either of them – exactly because they have remarkably little to do with the meaning in music and dance. Nonetheless they are in common use and both have modeling and markup languages associated with them, so I think we need to understand that usage and live with it. The distinction is essentially that an orchestration has a conductor (i.e. someone or something that actively coordinates the process across the various activities (or sub-processes) it encompasses), whereas choreography is a collaboration across parties where each party independently carries out an action in response to some event or other and therefore allows room for the creative process . You could regard the former as involving direct messaging (regardless whether it’s a human or machine implemented process) and the latter being more publish and subscribe.
@Peter, I agree that your Fit element is neither of these things, which is why I referred to it separately. Maybe I didn’t make that very clear.
Does any of this matter in the context? Well only because the “choreography” kind of approach (or any other which gets away from rigid, rules based systems) seems to me to be the most promising whether we are looking at human-human or human-machine interactions and potentially for machine-machine interactions of any complexity, although I have my doubts about the latter, which I’ll articulate another time and perhaps somewhere else. So what’s developing under the heading of choreography (whether one likes the metaphor or not) is, I think, worth following.