The Architect Is a Compression Algorithm
A single business problem is never small. Underneath “let customers pay by instalments” sits legislation, financing costs, fraud patterns, customer behaviour, operational limits, a dozen vendor contracts, security constraints, marketing commitments, and a decade of existing systems that all have opinions. Thousands of individual facts, most of them true, many of them in tension.
Engineering cannot act on thousands of facts. It needs a direction — one coherent technical shape it can build against. Producing that shape is the architect’s real work, and it is almost exactly an act of data compression: take an enormous, messy reality and reduce it to a signal small enough to act on, without losing the part that mattered.
The words matter there. Compression, not deletion. A bad architect compresses badly in one of two ways. The first keeps everything — every stakeholder’s concern preserved, every option left open, every caveat documented — and calls the resulting fog “thoroughness.” Nothing has actually been decided; the complexity was forwarded, not resolved. The second throws away too much, produces a clean and confident direction, and discovers later that the discarded detail was the whole point — the compliance clause, the peak-hour load, the assumption the CEO never said aloud because it was obvious to everyone except the people building it.
The craft is in knowing what is safe to drop. Every fact you compress away is a bet that it will not change the answer. Most won’t. A few will decide everything. Telling those apart — before you have the luxury of hindsight — is judgement, and it is the part of the job no framework can hand you.
There is a symmetry worth noticing. Engineers then take that compressed direction and decompress it back into full, working software — re-expanding the signal into thousands of concrete decisions of their own. If the compression lost the wrong thing, no amount of engineering skill downstream can restore it. The information was gone before the first line of code.
So the deliverable was never the diagram, and never the document. It was the compression itself: the reduction of an unmanageable reality into a direction a team can actually build — with the essential part still intact. How to do that well, and how to know what you are allowed to lose, is the through-line of the manifesto and the books.