Somebody puts an architecture diagram on the screen. Boxes, lines, a few colours, the platform in the middle. Everyone looks at it, nods, and the meeting moves on to the decision it was called for.

I have sat in that meeting many times, and there is one question I have almost never heard anyone ask. When was this last true?

It is not a rude question. The diagram was true once. Somebody drew it carefully at the moment a decision was being made, and on that day it described the estate exactly. Then the estate went back to work. Services were added, a queue was replaced, a team took a shortcut in the fourth quarter and fully intended to come back to it. The code changed every single day. The drawing changed whenever someone had a reason to open it, which is roughly never.

So the diagram is not wrong the way a mistake is wrong. It is old. And nobody in the room can tell you how old, because the drift accumulated quietly and belonged to no one. The architect who owned the model moved on. The teams who moved the code were measured on delivery, not on keeping a picture current somewhere else. There is no villain in this story. There is just a gap that nobody’s job description covers.

The gap starts to matter when you spend money against it. Transformation programmes are planned on the model: this system is being retired, that one is the strategic platform, these two integrate through the bus. If the model is three years stale, the plan inherits every one of those three years. You find out at the point of execution, which is the most expensive place to find out anything.

The instinct is to fix the drawing. Get everyone in a room, redraw it properly this time, put it under change control and hold the line. I have watched that work for about six months. It fails for the same reason it failed the first time, which is that keeping a manual artefact in step with a moving system is a permanent job competing with delivery, and delivery wins.

The better answer is to stop treating the picture as the record. Measure the code, repeatedly, and check the model against what the measurement actually finds. The question then changes shape. Instead of “is the diagram right”, which nobody can answer, you get “here is where the model and the code disagree, and here is whether that gap is widening or closing”. That is answerable on a Tuesday, by anyone, without a workshop.

None of this requires a better diagram. It requires a second source of truth that does not depend on someone remembering to update it.

So the next time the architecture goes up on the screen, ask when it was last true. If the answer is a shrug, you have just learned the most useful thing in the meeting.