An architecture review should not reward the most detailed diagram. It should expose risks before they become expensive constraints. A useful review connects business-critical workflows to correctness rules, measurable quality attributes, failure behavior, ownership, and evidence.
Four questions keep the conversation focused:
- What must remain true?
- How well must the system behave, under what workload?
- How does it fail and recover?
- Who owns the boundaries and the evidence?
These questions work for a new design, a modernization proposal, or an existing system whose risks need to be understood.
1. What must remain true?
Start with invariants: statements that must hold across normal operation, retries, partial failure, and recovery. In a hypothetical school ERP fee workflow, examples might be:
- a payment reference is not applied more than once;
- an adjustment retains the reason and authorizing actor;
- a displayed balance can be traced to accepted transactions;
- access to a student record follows the current authorization policy.
These statements are more useful than “use strong consistency” because they describe protected outcomes. The implementation may use a transaction, uniqueness constraint, idempotency record, version check, append-only ledger, or reconciliation process. The invariant lets reviewers assess whether the mechanism is sufficient.
Trace each critical workflow from entry point to durable effect. Identify where data is validated, who can mutate it, where transaction boundaries begin and end, and what happens if a step is repeated. A component diagram without this flow often hides the highest-risk behavior.
Also ask which source is authoritative. If student identity appears in admissions, academics, billing, and external integrations, which system owns which attributes? How are corrections propagated? “Single source of truth” is not enough unless the fields, ownership, and conflict behavior are defined.
2. How well must it behave, under what workload?
“Fast,” “scalable,” “secure,” and “highly available” are aspirations, not reviewable requirements. Turn quality attributes—often called non-functional requirements—into measurable scenarios.
A useful scenario includes:
- stimulus: what happens, such as a user submitting a payment;
- environment: normal load, enrollment peak, dependency degradation, or recovery;
- response: what the system should do;
- measure: latency percentile, throughput, error proportion, recovery point, recovery time, or another observable threshold.
The threshold must come from user needs, business constraints, regulation, dependency contracts, or measured baselines. Do not invent a target because it sounds standard. If the organization does not yet know the target, document that as a discovery item and state how it will be determined.
Workload context is essential. Specify request mix, concurrency, payload size, data volume, growth assumptions, and burst duration. A requirement to handle a number of requests per second says little without identifying the operations and their resource profile. Reads served from cache differ from writes that contend on the same records.
Use percentiles for latency because an average can conceal the experience of slower requests. A target should name the endpoint or workflow, percentile, observation window, and conditions. Capacity review should also inspect errors and saturation; a low latency measured while rejecting work is not success.
Availability needs scope. Which workflows must remain available, and what degraded behavior is acceptable? Reporting may tolerate delayed data while posting a payment may require a clear refusal rather than an uncertain result. Recovery objectives likewise need a defined data set and failure scenario.
Security and privacy requirements should identify assets, actors, trust boundaries, and required controls. “Use encryption” does not answer who can access the data, where keys live, how authorization changes take effect, or what is recorded for audit.
3. How does it fail and recover?
Trace failure across every remote and durable boundary. A request can time out after a dependency commits. A queue consumer can stop after writing data but before acknowledging a message. A cache can return stale data. A deployment can leave old and new application versions running against the same schema.
For each important failure mode, ask:
- Is the outcome known, failed, or uncertain?
- Is retry safe, and under which idempotency scope?
- What is the caller’s total deadline?
- Can work be duplicated, reordered, or lost?
- How is partial progress detected?
- What does an operator see?
- How is the workflow reconciled?
Retries are not a universal recovery strategy. Layered retries can amplify an outage, while retries of non-idempotent operations can duplicate side effects. Queues shift work in time but introduce backlog, ordering, poison-message, and observability concerns. Caches improve some paths while introducing invalidation and staleness decisions.
Review deployment and data migration as part of architecture. Can old and new versions coexist? Are schema changes backward compatible during rollout? Is rollback possible after data has been transformed? A rollback instruction that has never been exercised is an assumption, not evidence.
4. Who owns the boundaries and the evidence?
Architecture diagrams often contain boxes named “integration,” “platform,” or “shared service.” Those labels can hide ownership. Each boundary needs an owner for its contract, data, schema changes, operational signals, and incident response.
External dependencies deserve explicit contracts: authentication, versioning, rate behavior, timeout policy, error semantics, and support path. Internal dependencies need the same rigor even when the teams share an organization.
Then connect claims to evidence. Correctness may be supported by constraints, property tests, and reconciliation exercises. Compatibility may be supported by contract tests. Capacity claims need representative load tests. Recovery claims need restore or failover exercises. Production behavior needs indicators tied to user-visible workflows.
Evidence has limits. A load test validates a workload and environment, not infinite scalability. A successful failover validates the scenario exercised, not every outage. Record assumptions, test conditions, and the trigger for another review.
Produce a risk register, not just comments
Conclude the review with a small set of decisions and risks. For each risk, record impact, evidence, mitigation, owner, and review date or trigger. Distinguish a blocker from accepted debt. The accountable decision-maker should understand what is being accepted and why.
The school ERP project illustrates why workflow and domain boundaries matter in systems where identity, fees, academics, and operations intersect. For an independent assessment of an existing or proposed design, see the architecture review service.
A review is complete when another engineer can explain what must remain true, the workload and quality thresholds, failure and recovery behavior, and who owns the evidence. Reproducing the diagram is not enough.