The starting point here was a post by IT-architect Roger Sessions, on “Why I Focus On Complexity”:
When it comes to IT failure, there is no lack of “the usual suspects”. … Yet given [the] extensive collection of failure factors any of which can doom an IT project, why do I focus almost exclusively on the issue of complexity? I see all of the failure factors as falling into one or more of three categories:
1. The factor is caused by complexity.
2. The factor is greatly exacerbated by complexity.
3. The factor is solved as a side effect of solving the complexity problem.
Agreed – and the rest of the post is well worth reading, too. But what exactly is meant by the term ‘complexity’? – it seems to be a given, but is never explained. And it’s a question that we do need to ask, because there are fundamental concerns here that can lead to seriously wrong ‘solutions’ if we don’t get this right.
From Roger’s description, it’s clear that he’s mainly focussed on ‘IT complexity’ – in other words, technical complexity. Social complexity is acknowledged, but it’s not regarded as a core concern – unlike the great IT consultant Gerry Weinberg, who asserts in his classic The Secrets of Consulting that “whatever it looks like, it’s always a people-problem”. It’s also clear that Sessions regards all such problems as solvable:
Solve the problem of complexity, and these problems become much easier to solve.
Yet when we compare this to the Cynefin model of organisational complexity, it becomes clear that he’s not talking about ‘complexity’ in the Cynefin sense. Instead, like many people, he’s using ‘complex’ as a shorthand for ‘very complicated’ – which is not the same as ‘complex’ in the Cynefin sense.
Complicated problems still follow Aristotelian-style causal logic; they’re difficult to solve, but they can be solved, usually via analysis to reduce them to simpler sub-problems, as Roger suggests.
Problems that show true complexity are fundamentally different from this. They usually include at least one inherent dilemma or paradox which renders them impossible to reduce to a single ‘correct’ solution – hence, for example, a ‘wicked problem‘:
“Wicked problem” is a phrase used in social planning to describe a problem that is difficult or impossible to solve because of incomplete, contradictory, and changing requirements that are often difficult to recognize. Moreover, because of complex interdependencies, the effort to solve one aspect of a wicked problem may reveal or create other problems.
Wicked-problems and other complex problems follow a Zen-like acausal logic in which incompatible statements may both be true at the same time. As a result, complex problems cannot be solved by conventional Aristotelian analysis. Because the underlying factors are dynamic, not static – and likewise the tensions between them – complex problems also cannot be solved by breaking them into simpler sub-problems: doing so will at best give the dangerous illusion that the problem has been solved, when in reality the ‘solution’ is valid only for the specific circumstances that apply at that specific time. Attempting to break the problem into smaller sub-problems also often conceals the true complexity and interdependencies between underlying factors, making the problems even harder to resolve in practice.
There is no way to “solve the problem of complexity”. Complex problems cannot be solved: they can only be ‘re-solved’, dynamically, adapting continuously to the changing balance of factors, through use of systems-oriented tactics and techniques such as the Viable System Model.
So when we use terms such as ‘complex’ or ‘complexity’, we need to be very clear about what we actually mean – highly complicated, or true complexity – because the way we tackle the respective issues is fundamentally different:
- highly complicated: use analysis to break down to simpler sub-problems; systems-theory tactics will be confusing ‘overkill’
- true complexity: use of analysis alone will guarantee failure; systems-theory tactics will be essential
If you describe your current project as ‘complex’, which ‘complexity’ do you mean? The answer may literally be a matter of life and death…
I have found the work of Roger Sessions to be interesting. But as someone who have an interest in systems thinking, complexity science and the Cynefin framework, I have been a bit puzzled as to his definition of complexity.
Roger’s version of ‘complexity’ is a common usage, and often the only usage for many IT-folks, in the conventional Aristotelian true/false logic of the _internals_ of most software. But it becomes problematic as soon as we hit complexity in the Cynefin sense, such as in social-complexity or the social/technical interface.
So Roger’s description is not ‘wrong’: it _is_ a good approach to take as long as you’re dealing only with the subset of the context constrained _within_ the IT/software-only boundary – in effect, an idealised if very complicated ‘world’. Just not so good an approach for dealing with the rest of the real-world outside of those rather artificial bounds, where the radically different rules for true complexity (in the Cynefin sense) would apply.
[site-administrator note: this comment was manually transferred from previous web-host during the site-move – gravatar shown is mine as editor, not Akintomiwa’s]
i am a masters student researching on enterprise architecture complexities, i would like to hear your view on the root causes for complexity in enterprise architecture
Hi Akintomiwa – sure: what types of complexity interest you most? Technical complexity, human complexity, security complexity, supply-chain complexity, many other types of complexity – take your pick! 🙂