An architecture review is often misunderstood as a documentation exercise. Someone arrives, reads the architecture documents, comments on whether they look reasonable, and leaves a report behind. This is not an architecture review. This is reading.
A genuine architecture review examines what the organisation actually has — which is almost never what the architecture documents say it has — and tests it against what the organisation actually needs.
It is more time-consuming than reading. It is also significantly more useful.
Free · 4 minutes
If your most senior engineer left tomorrow, would anyone still understand the system?
Fourteen questions on documentation, dependencies, and the gap between how the architecture works and how many people know it. Banded finding on screen, full sheet by email.
Phase one: who, what, where
The work starts with people, not systems.
The first conversations are with the users — the people who operate the systems day to day. The warehouse manager who knows that the stock figure is wrong on Wednesdays. The finance lead who knows that two reports never agree. The marketing manager whose campaigns rely on data that has to be exported and cleaned manually. The IT operations team who know which systems they hold their breath about during updates.
These conversations produce a map of what is actually in play. It is rarely the map the organisation believes it has. Systems exist that are not on the official diagram. Integrations have been built by someone who has since left, undocumented, but still load-bearing. SaaS subscriptions are paid by departmental budgets without IT visibility. Spreadsheets have grown into systems with operational dependencies.
The diagram that emerges from phase one is the architecture of the organisation as it currently runs — including the workarounds, the shadow IT, and the manual processes that quietly compensate for everything that does not quite work.
This is the baseline. Reviewing the documented architecture without first establishing the actual one is reviewing a fiction.
Phase two: the inventory questions
For each system identified in phase one, a structured set of questions is applied.
What is it? A surprising number of systems are difficult to name precisely. Versions are unclear. Editions are forgotten. The system was customised so heavily that it is no longer the stock product the vendor describes. Establishing what is actually there is the first step toward evaluating it.
What does it do? The intended function and the actual function are not always the same. Systems get repurposed. A platform purchased for one job ends up doing three. Understanding what it does today matters more than what it was bought for.
How old is it? Age is a proxy for risk in a way that vendors do not advertise. A system that has not been substantially updated in five years is operating on assumptions that may no longer hold. Underlying dependencies — operating systems, database engines, integration protocols — change underneath ageing systems and produce silent compatibility issues.
Is it up to date? Patch levels, security updates, vendor support status. A system that is two major versions behind is on borrowed time. A system whose vendor has discontinued support is exposed in ways the organisation usually has not quantified.
Does it do what it needs to? Fitness for current purpose. The system was adequate when it was selected. The business has changed. Whether the system has changed with it is a separate question.
Can the staff manage it? Operational capability matters as much as the system itself. A sophisticated platform that nobody on the team can confidently configure is a risk, regardless of how appropriate the platform is in principle.
Does it fit the future direction? The hardest question, because it requires knowing the future direction. If the organisation has a roadmap, the system can be evaluated against it. If not, the absence of a roadmap is itself a finding.
Phase three: the specific lenses
With the inventory complete, specific concerns are applied as lenses across the stack.
Security. Not just whether the systems are individually defensible, but whether the architecture as a whole holds under pressure. Where are the trust boundaries? Where does authentication weaken? Which systems hold sensitive data, and what controls govern access to them? The questions here are familiar from any security audit, but applied to the actual map rather than the documented one.
Accessibility. Increasingly a legal requirement, often an unaddressed one. Customer-facing systems may not meet WCAG standards. Internal systems may exclude staff with disabilities. The review identifies where accessibility is met, where it is not, and where the gap exposes the organisation to legal, ethical, or reputational risk.
Flexibility. The capacity to change. How easily can a new requirement be accommodated? How easily can a system be replaced if the vendor changes direction? Flexibility is not visible until it is needed. The review identifies where it is present and where it is not.
Performance. Speed of response, throughput, capacity headroom. Performance issues are often known to the operations team and absent from the architecture documents. The review surfaces what is actually being experienced, where bottlenecks exist, and where capacity is being consumed faster than planned.
Data residency. Where data is stored, where it is processed, where it transits, and whether all of that is consistent with the regulatory obligations of the entity that owns it. This question is rarely asked at the architecture level. It is increasingly asked by regulators.
Other lenses may apply depending on the organisation — disaster recovery posture, vendor concentration risk, compliance with specific frameworks. Each lens is a different way of examining the same architecture. Each tends to surface findings the others miss.
Phase four: the deliverables
The output of an architecture review is not a single document.
The report. A written record of what was found, organised by system and by lens. Detailed enough to be useful, structured enough to be navigable, honest enough to be acted upon. Issues are described concretely, not in the language of generic risk frameworks. The report is the artefact the organisation keeps.
The recommendations. Specific actions, prioritised. Not a list of everything that could be improved — a list of what should be addressed, in what order, with reasoning. The discipline is in the prioritisation. Recommendations without priorities are an unbounded backlog.
The 1-1 call. Sometimes the report needs to be discussed. Findings that are politically sensitive, technically subtle, or that recommend significant change benefit from a conversation. Not every review requires this. The ones that do, require it more than the report.
The delivery plan. Separate from the review itself, this is the work of planning what happens next. Which recommendations turn into projects, how those projects are sequenced, what budget and resourcing they require. A delivery plan is its own engagement. The architecture review identifies what needs doing. The delivery plan turns it into a roadmap.
The distinction between the review and the delivery plan matters. A review that concludes with a list of recommendations and stops there leaves the organisation with the question of what to do next. A delivery plan answers that question with the same rigour applied to the review.
When an architecture review is worth commissioning
The most useful times to commission a review are at decision points: before a major platform migration, before significant investment, before an acquisition or divestment, before a transformation programme is scoped, after an incident that has revealed something the organisation did not know about itself.
It is also worth commissioning when the organisation cannot confidently answer a basic question about its own architecture. If senior people are unclear about what data lives where, which systems are critical, what the actual integration map is, or whether the current architecture supports the next two years of strategy — the review will produce more value than the budget it consumes.
The least useful time to commission a review is during an active project, where the findings will be politically inconvenient and the recommendations will compete with sunk cost. The most expensive review is the one commissioned to validate a decision that has already been made.
A few rules
Start with people, not documents. The architecture documents describe an architecture. The people describe the architecture. Always interview before reading.
The inventory matters more than the diagram. A precise account of what is actually in play, evaluated against what it actually does, will reveal more than any architecture diagram. The diagram supports the inventory, not the other way round.
Apply specific lenses across the whole stack. Security, accessibility, flexibility, performance, residency — each lens applied across all systems will surface findings that system-by-system review misses.
Separate the review from the plan. The review identifies. The delivery plan resolves. Conflating them produces a report that is neither one nor the other.
Commission at decision points. Before a migration, an acquisition, a transformation, a major investment. The review is worth most when its findings will inform a decision that has not yet been made.
Richard King is CTO at Sixteen Pillars — technical leadership, architecture, and governance for organisations that need it without the overhead of a full-time hire.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.