Architecture and what to trust in a "post-truth" world
A TED talk on the way to a customer visit this week. Alex Edmans, What to Trust in a Post-Truth World. Not intended for architects or technology practitioners, and not framed around enterprise systems. I kept stopping and replaying parts of it.
The core of what Edmans argues is a chain of distinctions that sounds straightforward but is not. A story is not a fact, because it may not be true. A fact is not data, because it may not be representative. And data is not evidence, because it may not be supportive - the same numbers can be consistent with rival theories. Progress towards genuine understanding requires each step in the chain to hold: only if something is true can it be a fact; only if it is representative can it be data; only if it genuinely supports a conclusion - not merely fails to contradict it - can it be treated as evidence.
Architecture conversations are full of breaks in this chain.
"We have to migrate from X to Y" enters the room as though it were evidence. In many cases it is a story - possibly useful, possibly convenient, possibly an assumption that has been repeated often enough to acquire the character of settled fact. The job of the architect is not to accept that framing and design accordingly, but to ask what is actually beneath it. Is there a strategy here? Is that strategy grounded in something representative of where the organisation needs to go? Or is the conclusion familiar rather than genuinely supported?
The same applies in the other direction. "Our users want X" is a story. It becomes data only when the sample is representative of the people who will actually use the system. It becomes evidence only when the conclusion it supports is not equally consistent with a different conclusion drawn from the same data.
None of this argues for scepticism about everything. It argues for a brief examination of where any assertion actually sits in the chain: is this true, or is it repeated? Is this representative, or is it drawn from a convenient subset? Does this support the conclusion, or is it merely compatible with it?
The practical implication I take seriously in my own work: invite challenge rather than validation. Ask people who disagree with the design to engage with it, rather than relying only on those already broadly aligned. Most of the challenge will not be directly applicable. But within it, consistently, is the fraction that points to something less solid than it appeared.
Continue exploring