What an audit should leave you

An architecture audit too often ends with a thick document nobody reads twice. The system itself has not changed. Here is what I hand over at the end of an audit, and why.

A map of what exists, just precise enough

A diagram of the components and their flows, with for each one: who runs it, where its data lives, what breaks when it goes down. Not exhaustive: enough to reason about together.

Measured findings

"The application is slow" is not a finding. "The search screen runs 47 SQL queries per render, 44 of them identical" is. Each finding comes with its measurement and how to reproduce it, so we can check it has gone.

An order of correction

I rank each point on two axes: its effect on the business (incidents, cost, delivery time) and the effort to fix it. What costs little and pays a lot goes first, even when it is not the most interesting technically.

Decisions, written down

For each structural change, a short decision record: the context, the options considered, the one chosen and what it implies. In six months someone will ask "why did we do this?". The answer will be there.

A target, and the first step towards it

The target says where to go; the first step says what to do on Monday. Without that first step, the target stays a drawing.

What I do not hand over

A ranking of developers, a list of complaints, or a full rewrite as the only way out. An audit exists to decide, not to judge.