What happens when people get too fixated on the ‘boxes’ in our models and frameworks? And what can we do about it in enterprise-architecture?
This one’s actually a follow-on to the previous post about ‘It depends…‘, but it starts with a Tweet:
RT [someone]: OMG. Now we get spiral dynamics, even worse than NLP. Why do people fall for these simplistic categorisation tools?
There’s a certain amount of presumably-unintended irony there, because the exact same could be said of that person’s own model – in fact the colleague who forwarded me the Tweet added the wry comment, “I sure hope nobody tweets “why do people fall for these simplistic categorisation tools?” during his presentation tomorrow…”. Which, though, should in turn lead us to some important insights about the role and use of frameworks and models in generalist disciplines such as enterprise-architecture.
The real problem here is that it’s not so much that a model itself is overly simplistic, but more in the way in which it’s described or used: which is a rather important distinction. In my experience, even the simplest-looking model can be used in ways that are Simple, Complicated or Complex; and when used in recursive, iterative, intentionally-‘Chaotic’ techniques such as Causal Layered Analysis or context-space mapping, even the simplest of single-axis models can deliver richly-serendipitous insights.
The real catch is that if we can only describe a model in Simple terms, we’ll only be able to get Simple use from it – which may not be much use in practice. And if we do so, then the fault is ours, and not in the model itself: again, another important distinction.
(Choosing to describe others’ models in selectively-Simple terms does make them much easier to mock as ‘simplistic’, of course. But that’s the result of a subjective choice, not an objective ‘fact’ – and that’s another story…)
The challenge we face here, in enterprise-architecture and elsewhere, is yet another variant of that age-old clash between ‘boxes’ versus ‘between-the-boxes’. Any reasonably-complete model will have a good mix of both built-in; and almost every less-complete model – such as a classic ‘two-axis four-boxes’ framework – can be re-used in much richer ‘between-the-box ways. The option is always there somewhere, if we make the effort to look for it.
The catch is that the graphic version of models is usually much-simplified in order to fit in with the constraints of visual representation – and in most cases it ends looking like little more than a bunch of variously-labelled boxes. The real catch that follows from that is most people will default to the linear-paradigm: and the linear-paradigm does tend to see things only in terms of Simple ‘boxes’. Which means that most people, when presented with a typical enterprise-architecture framework, will tend at first to think that the whole model consists solely of that Simple set of ‘boxes’ – which it isn’t. And that’s where things get messy…
We can illustrate this well with the Cynefin framework:
At first glance, many people interpret this as a single two-axis frame – which it isn’t. (And is, and isn’t, and then is again, sort-of – as described in Cynthia Kurtz‘s initial Cynefin work on order versus unorder and the relationship-‘pyramids’, for example. That’s the kind of complexity that we should expect – and need – within any well-designed rich-model like Cynefin, of course. We can skip over that kind of detail for this purpose here, though.)
When people do see Cynefin only as a simple categorisation-tool, with nothing else behind it, almost all of the useful power of the model is lost. Which is not helpful: Snowden rails against this kind of misuse of the Cynefin frame, and I think he’s right to do so. The catch is that this is what most people will naturally tend to do, whenever they first come across a new model: and we therefore need to design for that fact, rather than merely complain that it ‘shouldn’t’ happen.
One immediate tactic to make people more aware of the model’s real richness is to make sure that there are multiple versions of the base-graphic, that each illustrate different aspects of the model. Juxtaposition between multiple views will then all but force people to ‘break out of the box’ of the boxes-only view. A good example of this is the illustration for the Cynefin-dynamics:
This shows us that there’s a lot more going on beneath the surface in this model – in this case, showing explicitly that something happens ‘between-the-boxes’ here. (This also helps to suggest that if we’ve found the basic idea of the model relevant for our work, we’ll need to study at least some of the detail of the model rather than solely look at the pictures.) It’s also the same base-frame here as in the main Cynefin graphic, yet carrying different information – enabling the kind of comparisons and crossmap-overlays that form the foundation for ‘cognitive-dissonance’ techniques such as context-space mapping.
Another useful tactic illustrated in the Cynefin frame is to not use a simple box-type layout for graphics. The curved domain-borders play an important part in this, giving the intended sense that the four main domains are spread outward from the central-domain of ‘Disorder’.
We can see the same kind of tactic in use in one of the model-types mentioned in that Tweet above, Spiral Dynamics:
If we look at this solely as a ‘bunch-of-boxes’, it’s quite easy to dismiss it as a “simplistic categorisation tool” – especially given the ways in which so many people do seem to (mis)use it. Yet like Cynefin, there’s a lot more behind it, including detailed description of the symptoms of the inter-domain transitions, and practical examples of how they can be applied in real-world concerns – hence, exactly as with Cynefin above, it’s important not to get too hung up on the surface-appearance of the base-graphic.
For what it’s worth, my understanding is that the original core work by Clare Graves back in the 1950s is sound: he was a contemporary and close colleague of Abraham Maslow (of ‘Maslow’s Hierarchy’ fame). The ‘stepping-stones’ concept also aligns closely with what I learnt about child-development when working with Mary Sheridan in the 1970s. Yet although the model does seem to work well for individuals, I don’t think the attempt in Spiral to apply the same principles to whole societies works well at all – especially in the ghastly ‘manifest destiny’-style ‘spiritual-imperialism’ of the so-called ‘Integral’ version championed by Ken Wilber and his followers. As I’ve explained in various posts on this blog – such as ‘Dimensions of a Spiral‘, ‘Another note on Spiral Dynamics‘ and ‘Maslow’s Hierarchy isn’t a hierarchy‘ – I also don’t think it’s actually a linear spiral-development anyway: to me it seems much more like a set of Gray-code-like transitions in a multi-dimensional context-space.
Some of my own models do use box-like layouts, which is perhaps a bit problematic, but it does accurately reflect the underlying structure. For example, on the surface, SCAN looks almost like the most simplistic type of two-axis-matrix model:
The reason for that layout is that it is indeed based on a two-axis frame: but the axes themselves are not as simple as they look. The divider across the horizontal-axis is explicit and real: but in effect it does move around – or rather, the context bounces from side to side of that boundary – in accordance with the dynamic variety of the variety in the context. The divider on the vertical-axis is also real – the transition between ‘considered’ (pre-action) versus ‘real-time’ (point-of-action) – but in practice its effective position in terms of ‘distance from the ‘now” is highly variable. In other words, yes, four ‘boxes’, but in practice the effective size of each of those boxes is changing all the time. And we’re usually far more interested anyway in the transitions between the boxes: the boxes themselves – the ‘domains’ – are placeholders for descriptions of typical symptoms and tactics whenever a context is ‘in’ that space.
It’s much the same with the ‘swamp-metaphor‘, another of my models with an explicit underlying two-axis frame:
On the surface, yes, again, it looks like just another ‘simplistic categorisation tool’. But as explained in the detailed instructions on how to use the frame, it’s much less about the categories themselves, and much more about using those categories as anchors for an active-checklist to identify and select appropriate tactics according to the real-time dynamics of the respective context.
Onward into more mainstream enterprise-architecture, the same kind of issues apply also to methods-frameworks such as the TOGAF ADM:
In this case, yes, the ‘boxes’ are actually circles, but the same principles apply. At first glance, most people will read it as a linear sequence: which is why we’ve seen so many enterprise-architecture-as-project near-disasters that try to do everything in one go, taking at least a couple of years to execute, at huge expense and for very little direct business value. Which is one reason why some people are overly-dismissive of the ADM as an architecture-development method.
Yet the crucial point – which in principle does appear in the diagram, but you’d need to know the model well to recognise that it’s there – is that it’s actually not constrained to a linear sequence: it’s iterative and recursive, and we can do any part of it in just about any order. In other words, there’s nothing in the model itself that would stop us doing a complete ADM mini-cycle in a couple of hours, or less – which would be much more likely to be able to deliver tangible value on timescales that make more visible sense to everyone else in the business. The only thing that stops people from recognising this point is the assumption and expectation that it’s a strict linear sequence of ‘boxes’, and that there’s only ever one way to move ‘between the boxes’ – which isn’t true at all.
We also see this same kind of problem in the ‘grand-daddy’ of enterprise-architecture models, the Zachman framework:
It is, all too obviously, an array of ‘boxes’. It’s described very much in terms of ‘boxes’ – or ‘primitives’, to use Zachman’s term. Hence, for example, one toolset-vendor has carefully categorised all of the toolset’s model-types in line with that specific layout of boxes – ensuring that there’s at least one tool in each ‘box’, and that no tool ever appears in more than one box.
Which is daft: that’s not architecture, that’s linear-paradigm-gone-mad… 😐
It’s true that to do the ‘why’-oriented stage of architecture, we’ll often need to split things apart into a ‘primitives’-type structure, to clarify what we have and to prevent us from getting too hung up on the implied ‘bundling’ of our existing ‘solutions’. But once we’ve done that, and we then need to move back ‘downward’ again towards design-realisation, implementation and deployment, we need to recombine those ‘primitives’ into new configurations that bridge across the boxes. By the time we get right down to the real-world – below the ‘Detailed’ layer – we must have a configuration that links across all of the framework-columns: that’s reality.
There’s no way to make the architecture work at that level if we’re still thinking only in terms of the framework’s ‘boxes’. Without a solid grasp of the ‘between-the-boxes’ links, we won’t have an architecture, all we’ll have is a cute collection of lists of parts, all in catalogued in ‘excruciating detail’ as per the Zachman spec, yet that have no connection with each other at all – in other words, an unusable mess. The only way to avoid that kind of mess is to recognise, right from the start, that although the framework looks like ‘a bunch of boxes’, and is almost always described as ‘a bunch of boxes’, in reality there are implied relationships between every pair, row and column of boxes – and if they’re not in the description of the model itself, we need the professional nous to realise that they’re needed!
That’s why architects are architects: we know that whenever we see ‘a bunch of boxes’, there’ll be ‘between-the-boxes’ relationships there as well. But we also need to remember that most people probably won’t see those relationships unless they’re in some kind of in-your-face explicit form: which is why we so often need to be explicit about displaying those relations in our models and frameworks.
In practice, any model can be used in this broader ‘boxes and between-the-boxes’ way: the limitations are far more in how we approach modelling in general, rather than in the models themselves. To be blunt, anyone who dismisses some model as a ‘simplistic categorisation tool’ is not only missing the point, but doing little more than displaying their own lack of imagination and modelling-skill. Which is odd, in some cases, but there ’tis…
Anyway, the key point from this post is this: every time we see ‘a bunch of boxes’, look for the links between those ‘boxes’ – and help others to see that they’re there. That’s the way that architecture works.
Over to you for comments, perhaps?