Between the boxes

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:

SCAN core-graphic (revd 10Nov11)

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?

9 Comments on “Between the boxes

  1. Hey Tom. I see two valid uses of boxes in sensemaking. (1) As stepping stones to deeper understanding, with the aim of moving past them once a simple and preliminary understanding is gained. (2) As contextually limited practical tools, derived and used only within a particular context, never widely or elsewhere.

    Because moving past stepping stones and keeping within an applicable context seem to be so difficult for people to do in practice, I have come to the conclusion that boxes are more trouble than help in sensemaking. They seem to hold people back more than they help them advance.

    But that’s just my way of looking at it. 🙂

    • Hi Cynthia – thanks very much for joining in.

      Agree strongly on your ‘two valid uses’. I’d also argue for a third, which in a sense is a variant on your “stepping stones to deeper understanding”: boxes as known ‘waypoints’ in an otherwise landscape (context/concept-space). The box isn’t a bounded region as such, but a cluster of seemingly-related attributes or attribute-values that people can use as “ah, now I know where I am, and which way I need to go next” – dynamic, not static.

      The Four Directions in the Medicine Wheel provide that function, for example. Another more prosaic and tangible example would be the fixed geographic positions of the reference-transmitters in the old Decca Navigator system, still used in aircraft-navigation though largely supplanted these days by GPS. (The colour- and time-coding of the lights of lighthouses provides an even older equivalent for coastal navigation.)

      If we describes ‘boxes’ in that sense – as waypoints or reference-points, rather than filing-slots for categories – it makes sensemaking a lot easier (or less error-prone, at least).

      @Cynthia: “I have come to the conclusion that boxes are more trouble than help in sensemaking. They seem to hold people back more than they help them advance.”

      I’d largely agree. The real problem is that most people seem to like boxes, even need boxes in order to do sensemaking at all – a bit like a hermit-crab’s urgent need to find an empty shell to hide in? The result is that they’ll invent ‘boxes’ even where they don’t actually exist – which gets kinda messy…

      And if boxes are going to happen anyway in that sense, whether we like it or not, it’s probably wisest to have some ready-made boxes for people to use. At least that way we’ll have some better chance of knowing what’s in people’s sensemaking-boxes during the sensemaking process… :wry-grin:

  2. Ah, but INVENTING boxes is a GOOD thing. An invented box is a VERY different thing to a GIVEN box. An invented box is a box situated in a context, related to a perspective, created for a purpose. As long as we can avoid the mistaken belief that invented boxes are universal boxes, and as long as we can avoid trying to apply invented boxes without change to new contexts, perspectives and purposes, our propensity to invent boxes is a strength, not a weakness.

    By the way, the thing about boxes reminds me of stories. Stories are also things that have huge meaning in context (and from a perspective and with a purpose) but that do not travel well. I would argue that both universal boxes and universal stories are more trouble than help in sensemaking.

    • Inventing boxes when we know why we’re inventing boxes – and even that we’re inventing boxes – is a Good Thing (to me, anyway). Inventing boxes at random, out of panic because there’s no nice safe certain boxes to hide in, is perhaps not always such a good thing…?

      “As long as we can avoid the mistaken belief that invented boxes are universal boxes…”

      Yes, exactly.

      Likewise “Yes, exactly” about “boxes remind me of stories”. 🙂

      “I would argue that both universal boxes and universal stories are more trouble than help in sensemaking.”

      If they’re presented as universal stories, ‘the truth’, then yes, I’d agree with you. To me, though, a model is really just a template for stories: “here’s something to play with, to give you somewhere to begin – make it your own”. A sort of prepackaged ‘universal story’ that isn’t, is perhaps the best way to put it?

  3. Forgot to respond to the waypoints point. I LOVE waypoints. I think they are far more useful than boxes, and they are most emphatically NOT boxes. They invite inclusion more than exclusion; comparison more than contrast; and creation more than use as given. May there be many waypoints.

    • Boxes imply certainty, stasis, an enclosure (to me, often almost claustrophobic), finality, no movement allowed or possible; the only ‘there’ that is.

      Waypoints imply movement, a journey, a joyous uncertainty, a not-yet-known-but-perhaps-soon-to-be-known ‘there’ that leads to another ‘there’, which points to another new ‘there’…

      I know which of those I’d rather have! 🙂

      • Ah, but it is not necessarily bad to be boxed as Seth Godin puts it so nice in one of his posts.

        And then a box drawn is just a (poor) reflection of the reality and a model (and all these boxes are models) is not reflecting the real truth. So if you think of your boxes more as cells then voila, no conflict.

        And our concept of time is from a physics point of view an illusion: “People like us, who believe in physics, know that the distinction between past, present, and future is only a stubbornly persistent illusion.” – Albert Einstein

        So continue the great work, there is nothing wrong with boxes, as they are only a model. (or waypoints, or cells, or whatsoever). And then again from the great Einstein: “We can’t solve problems by using the same kind of thinking we used when we created them.”

        • @Kai: “our concept of time is from a physics point of view an illusion: ‘People like us, who believe in physics, know that the distinction between past, present, and future is only a stubbornly persistent illusion.’ – Albert Einstein”

          Following on from a BBC documentary I watched last night, if we deny time (as per that Einstein quote), then in effect we must also deny entropy, as ‘the arrow of time’. Which brings up lots of implications for enterprise-architecture and the like. Hmm…! – a very interesting point to ponder… – thanks! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *