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…
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.
So, over to you: how do you think? How do you think? And how do you think?
Tom, I hear u mate. I have had the same woes for many years. We are trying our luck at just that using social engineering, ideation and crowdstorming. Starting simple and then growing from there. Sign up and I’ll add u to the beta release soon.
This post is excellent and important.
I have felt for a long time now that many involved in architecture (and particularly modelling) have used frameworks (in the widest sense of an organized way of managing knowledge -not just architecture frameworks) and diagrams as an excuse to avoid thinking, are mostly unaware of their own thought process and the implicit assumptions therein, and that poor thinkers will produce poor outcomes no matter what the framework, whereas strong thinkers produce quality irrespective of the framework.
All this “hidden” activity during the process contributes significantly to the communication challenge you highlighted, and that no formal framework will alleviate (after all we all interpret anything written in terms of our own world views ,assumptions and prejudices).
Furthermore, I think this challenge is one of the roots of the claim that a number of respected observers of the architecture and system engineering domains make that great architecture is usually the product of one or a (very) small number of coherent minds; itself a challenge in the world of wicked problems and awareness of the steadily growing domain of the enterprise (see your work 😉 ).
I guess one of the conclusions from this train of thought (which I admit is a bit of a stream of consciousness at the moment) is that we should focus on developing self awareness of the thought / analysis / problem solving process we undertake, rather than investing faith or holy wars in frameworks and formality …
Sorry for the long post but it is a bit of a hobby horse … you know how architects can get 😉
Tom, I like the thoughts. I too struggle with communicating results. Usually it’s because I charge through figuring out problems without writing it up as I go. Then picking up the thread and going back to explain everything is difficult, it’s all synthesized in my head, but not on paper. I’ve come up with lots of processes and frameworks to help myself push out deliverables with less angst.
To comment on the communication frustration you were experiencing: In the business I’m in we separate the process of understanding the problem (research synthesis and data analytics generally) from the process of communicating the results. Clients would go MEGO (“my eyes glaze over”) if I tried to tell them the details of how I came to a conclusion for them.
However, when I tell them about the conclusion and weave examples with carefully selected qualitative and quantitative backup to craft a story, they are much more likely to buy in (and be able to get their customers to buy-in).
The mind is a light that is fussy about what it illuminates.
Encounters in my own thinking about thinking…
Lakoff and Johnson’s intriguing book “Women, Fire and Dangerous Things, What Categories Reveal about the Mind”. < In which I learned to a) take more seriously the effect metaphors and other figurative tropes have on my thinking b) stop thinking that ontology is synonymous with classification.
This RSA video on networks and trees https://www.youtube.com/watch?v=nJmGrNdJ5Gw < A simple but profound idea that has informed my professional thinking productively for quite a few years now.
Everything Invisible Gorilla mashed up with the pervasiveness of Confirmation Bias, and all the other imperfections in the system…
http://www.theinvisiblegorilla.com/ < We are not designed to think objectively, coherently or truthfully. So to do so we need some compensating extra-mental mechanism. Enter scientific method, experimentation, peer review…..
The Candle Problem http://en.wikipedia.org/wiki/Candle_problem. Or the "thinking as" problem. Over my seven year sojourn in academic philosophy I encountered many earnest young philosophers who were just not cut out for it. And they were not cut out for it in the same way… when they had to think outside their own ontological assumptions it upset them. You can't think well about the universe if for example, thinking about the universe "as" a simulation upsets you. You can't solve the candle problem if you can't stop thinking of the matchbox "as" a container.
Yep I went the traditional route – from Plato to Lucretius to Heidegger to Wittgenstein to Popper to Carnap and ever onward – or maybe – ever inward.
But it is in the work of the experimental technicians and scientific tinkers of thought that I have always found the genuinely liberating insights.
EA hasn't discovered it's latitude and longitude yet. It is navigating with hacks and work-arounds.
EA hasn't discovered the circulatory system, cell biology, or the microscope yet. It is still doing symptomatology and clinical trial and error.
EA hasn't found its calculus yet. It is trying to work out the volume of a light bulb using nothing more sophisticated than algebra.
Fortunately many problems are amenable to the Edison method…
I’m looking also (for more than a decade now) for a tool that helps me “think – and describe my thinking, especially about ‘big-picture’, often-abstract themes”
The majority of thinking takes place in my head. I use sketches but I don’t keep them, I throw them away and I keep the essence in my head. I need a tool that helps me to filter the essence from the huge continuous flow of information and that helps me to store it in my brain’s long-term memory. Because I couldn’t find such a tool I’m making one for my personal use. It just dealing with words, connections (lines), attention (focus) and “fire together/wire together” (patterns).
The main goal is that the tool will improve my “ability to recall a whole memory from a partial cue” which “is an important property of episodic memory, and is referred to as completion.”