Your Architecture Diagram Should End in a Decision

A diagram can fill a wall and still leave a meeting stuck.

Everyone can see the applications. The integrations look tidy. The colours have a legend. Then someone asks whether to retain the current platform, replace it or fix the process around it. The picture offers very little help.

That is where I think enterprise architecture needs to earn its place. It should help people make a choice they understand and can stand behind.

The recent discussions about coding agents make this more urgent. Teams can generate designs, documentation and code faster. Someone still has to decide which problem matters, which constraints apply and which consequences the organisation is prepared to accept.

Start with the question in the room

Before drawing the landscape, I would write the decision across the top of the whiteboard.

For example: “How should we reduce approval delays while keeping delegated authority and an auditable record?”

That question immediately changes the conversation. We need to understand where requests wait, who can approve them, what evidence is required and which systems hold authoritative information. A complete application inventory may help later. It does not have to be the opening move.

The useful picture connects the desired outcome to the options, their trade-offs, the controls and the person authorised to decide.

Bring the outcome, options, constraints and decision owner into the same conversation.

Make the recommendation inspectable

Consider three possible responses to that approval problem: improve the existing workflow, integrate the current systems or replace the platform.

Each option could be sensible. Improving the workflow may deliver earlier benefits but leave integration problems. Integration may reduce rekeying while increasing support complexity. Replacement may simplify the future landscape but require more investment and organisational change.

An architecture recommendation should make those trade-offs visible. It should also expose the assumptions: perhaps a source system has a supported interface, the business can agree on one approval policy, or the support team can operate the proposed service.

An assumption written down can be tested. An assumption buried inside a diagram tends to become somebody else's surprise.

I would keep a short decision record alongside the picture: the outcome, realistic options, recommendation, consequences, accountable owner, dependencies and review trigger. It needs enough detail for a future reader to understand why the choice made sense at the time.

A compact decision record preserves the reasoning, including the conditions that would justify a different choice.

Give delivery something it can use

AI-assisted delivery creates another requirement. Approved architecture needs to reach the people and tools doing the work.

A principle such as “use least privilege” is helpful direction. Delivery also needs concrete rules: which identities may call a service, which data may enter a prompt, which integration patterns are approved and which changes require review. Some rules can become automated checks. Others require an informed human judgement.

That translation deserves ownership. Machine-readable guidance can become stale just as easily as a diagram, and an automated check can enforce the wrong rule very efficiently.

The architect's role includes keeping the link intact between business intent, delivery constraints and evidence from operation. When the facts change, the decision record gives us somewhere to return.

At the next architecture review, put one question beside the diagram: “What decision becomes easier because we have this?” If the room struggles to answer, revise the picture around the choice people actually need to make.