A system diagram can help people understand a structure. It rarely explains why that structure was chosen, which alternatives were considered or what would make the organisation revisit it. For a consequential choice, retain that reasoning alongside the diagram.
Start with the decision
In a fictional legacy-platform review, the question might be whether to stabilise the current system, modernise it in stages or replace it. State the operating constraint and who needs to make the decision. “Adopt a modern architecture” is not a sufficient business question.
Identify the evidence available: incidents, stakeholder explanations, supported interfaces, delivery capacity and known obligations. Separate facts from assumptions. If an important dependency could not be examined, record that limit rather than drawing it as though it were settled.
Compare credible options
Use criteria tied to the operation: continuity, implementation risk, available skills, ownership, support and the cost of delaying the decision. Explain why an option is workable or unsuitable under those criteria. A fashionable tool is not automatically a better fit for the organisation.
For the fictional review, staged modernisation might reduce the scope of each release but retain some legacy responsibilities. Replacement might provide a cleaner target while increasing migration and transition work. These are possibilities to investigate, not a general recommendation for either route.
Record consequences and conditions
The record should say what was decided, what risk was accepted, who owns the next action and what new evidence would change the choice. If the plan relies on access to a vendor interface or an available delivery team, make that dependency visible.
A short, maintained record is more useful than a long document nobody can find. Markdown Architectural Decision Records provides templates for recording decisions. Use a format that your stakeholders can understand and keep the record alongside the working material.
Make the review useful without a delivery commitment
An independent assessment should leave the business able to act with its internal team, JVS or another partner. Separate the assessment’s recommendation from the commercial interest in implementing it. Agree the evidence, exclusions, timetable and fee before the paid review begins.
The illustrative assessment sample shows a system boundary, risk register and provisional decision for a fictional integration. The founder’s monitoring account is separate professional experience, with explicitly reported timing figures.
Request an introductory conversation about Architecture Review →