How do you think?

How do I think? How do I think, really? How do you think, exactly? How does anyone think – and describe their thinking? Especially about ‘big-picture’, often-abstract themes such as enterprise-architecture?

Yeah, I’ve been struggling with this one a long time – a very long time…

As an enterprise-architect, it’s generally assumed that I’d be a ‘visual-thinker’ – thinking in pictures, in diagrams.

Which I do, sort-of…

But it’s not quite as simple as that. Yes, I do have a few diagram-types I revert to as a matter of course – SCAN, for example, or Five Elements, or Enterprise Canvas (as above). And yes, I can knock up any of the regular boxes-and-lines type of diagrams with the best of them.

The catch is that for the kind of thinking I do much (most?) of the time, those are just, well, kinda too thin… sort of pale shadows of what’s actually needed, in the same way that a wireframe mockup conveys a thin idea of what the end-point might look like, but misses out so much that it’s hard to see the richness of what’s actually intended.

Here’s the real problem, I guess: everything connects with everything else – everything depends on everything else – all of which is changing, dynamically, all the time, at different, recursive, fractal, re-entrant timescales. I can picture that, sort-of, in my mind; walk through at least some of it, in mind; connect with all of the different times, in mind; but how on earth do I portray all of that, in a way that makes sense to anyone else?

Abstracts can help, sure. But the catch then is that it’s too easy to get lost in the abstracts and lose track of the connection to the concrete world that the abstracts are supposed to represent… Not so helpful…

This might itself sound like an abstract problem, an abstract whinge. After all, everyone else makes do with boxes-and-lines, don’t they? Well, yes, they do – as long as they’re dealing only with something that can be portrayed in a couple of dimensions, maybe three at most. When we’re dealing with anything more multi-dimensional than that, what happens in practice is that we do one two-dimensional diagram depicting one view into the concept-space, and then another depicting another view, and another, and another, and kinda hope and pray that others will be able to visualise and make sense of the near-invisible connections between those seemingly-discrete diagrams. Which, all too often, they can’t. And don’t. Which kinda defeats the object of the exercise.

To give a practical example, we’d tried to explain to a customer-service group the dangers to their business-model implied by a ‘pass the grenade‘ type of kurtosis-risk in their current service-design. This is the kind of risk where it might at first seem much more profitable to ignore the risk – in this case, the risk created by deliberately frustrating complainants in the hope that they’ll give up – but where all the apparent gains from ignoring the risk are more than wiped out when the risk does eventuate and the metaphoric grenade explodes in everyone’s faces.

To describe this, we’d started with a process-flow model, using their preferred notation – which, as standard, didn’t have any symbols to depict risk, so we had one awkward kludge there before we’d barely started.

Then we had to show the linkage to purported profitability in terms of cost-savings from avoided claims – for which there wasn’t a standard notation, so we had to make one up.

For the next part, we had to show impact on trust-relationships, both separate and distinct from information-about-trust, and separate and distinct from money – for which, again, there wasn’t a standard notation, and describing impacts in terms of anything other than money was pretty much an alien concept anyway.

We had to explain and show the nature of a kurtosis-risk – a seemingly-‘unpredictable’ seemingly-low-probability risk with very high impact, whose real probability increases steeply with iterations and participant-count – for which, yet again, there’s almost no notation (ORM is about the only one I know that allows for this kind of modality at all), and, yet again, seemingly an almost completely alien concept to anyone other than an experienced risk-manager.

And finally, somehow, we had to show how all of these diagrams linked together, to show how different service-designs and business-models heightened or reduced this risk and its probability of it exploding in everyone’s faces, how to model the uncertainties and timescales, and how it could be mitigated.

Sure, we could do diagrams. But no apparent way to do much of this in diagrams: all we had left were words.

Half of which, it was painfully evident, made little to no sense to about half the people in that session, no matter how hard we tried. Awkward.

So whilst I might be considered a ‘visual thinker’, most of the time I end up trying to describe things in words. If I can describe them at all. Yeah, awkward all right…

Worse than awkward, actually, because much of the time – an increasing amount of the time, at the moment – I end up being unable to describe what I’m thinking at all. Not just no visual-notation, but no words either. I’m trying to identify and describe nuances and interdependencies and dynamics that, by the time I’ve found suitable words or images, everything’s already moved on, and those words and images aren’t suitable any more. Tricky…

Which is where we get back to toolsets.

Let’s be slightly unkind for a moment. Yes, the existing EA toolsets are great for drawing out standard diagrams – even executable ones – and for documenting what exists and what might exist. In other words, models and diagrams as decision-records. They’re great at doing diagrams in distinct, predefined notations; some toolsets are even capable of building links between diagrams, where the entities are nominally the same. All very neat and tidy. But for the processes of thinking about architectures – the iterative, messy, tangled, tortuous and often torturous processes of sensemaking and decision-making, without which architectures don’t happen – well, those toolsets are often worse than useless…

If architectures were static, and nothing ever changed, the decision-records alone would be enough. But if we’re going to revisit an architecture at any time in the future – even for routine requirements such as to reduce technical-debt – then we’re going to need records not just of the decisions, but much if not most the ‘deciding‘ too. And the toolsets don’t handle that part well at all.

If we look at the toolset-ecosystem, what we have is a scrambled mess of tools, many of them, yes, very good in their own way, but each of which addresses only one small segment of the overall need, and barely connects with anything else. Formal diagrams? No problem. Mindmapping? Of course. Freeform sketches? Sure. Video-capture, or image-capture? Sure, can do – no worries, mate. Connect them all up to show how everything links up into an interdependent whole, and how it changes over time? Oops: forget it… no chance, bud…

Great… 🙁

Which is why I have several shelf-fulls of scrawled-in notebooks, often largely indecipherable, relating to projects dating back sometimes a couple of decades or more, all of which might be relevant to what I’m doing now. I have computers and portable hard-drives stuffed full of files, some of them in outdated file-formats that I can’t even read any more. (A point made even more poignant today, given that it’s the day when Microsoft abandons support for the operating-system that still runs several of my older computers…) All that the toolsets do is make it even worse, given that their so-proprietary fragmentation of the concept-space does little more than contribute to the ongoing nightmare of ‘dotting the joins‘. The only thing that holds it together at all is my equally-fragmentary memory – which, as cognitive-science warns all of us, gets less and less reliable as the months and years go by.

So: what we need is something that supports the ways that we think, so that we can record not just the decisions, but the way we arrived at those decisions – all of those trade-offs, the ideas that seemed to be dead-ends but might work with different technologies or at other times and places, the ‘gold-plated’ requirements that could be safely dropped when that person moves on. All that stuff – that messy stuff. But also solidly linked into the stuff that isn’t messy, the stuff that’s used for decisions at build-time and run-time, when we don’t have time to stop and think.

But to do all of that – to get to toolsets that actually work the way that we think, and that, in a fully unified way, support all of the different ways we think – we first need to get clear about how it is that we actually think. And hence what support we’d need for that thinking, in enterprise-architecture and elsewhere.

Which is where this needs to be about much more than just the way I think: if we’re going to get communication to work, across all of the space, it needs to be about how everyone thinks.

Including you.

So, over to you: how do you think? How do you think? And how do you think?

Comments, anyone?