What Should Trigger an Architecture Review?

A software architecture review is worth revisiting when a proposed change affects the assumptions behind an earlier decision. Check five areas: data boundaries, permissions, dependencies, failure behavior, and business scope. Then determine whether the change fits the existing approval, needs a focused review, or requires a revised architecture decision.

An integration has already been reviewed. Before implementation starts, the team proposes adding an external notification service. The customer still sees the same confirmation message. The backlog describes the change as a small delivery improvement.

But the new service may receive information that previously stayed inside the application. Someone must own its access, its failures, and the consequences of delayed delivery. The visible feature has barely changed; the assumptions behind its approval may have changed substantially.

This illustrative scenario raises a useful question: what should trigger another architecture review?

A practical starting point is to ask whether the proposed change affects the basis of an earlier decision. The number of changed files or the size of a ticket is a poor substitute for that question. A small change can cross a meaningful boundary. A larger implementation change may remain within an approach the relevant owners have already reviewed.

The following guide helps teams identify what needs attention. Apply it alongside your organization's required review and release procedures.

Start with what the earlier decision actually covered

Find the decision that permits the work. Identify the behavior it covers, the assumptions it relies on, the conditions attached to it, and who has authority to approve a change.

For the notification example, suppose the reviewed design keeps message preparation inside the application and treats notification delivery as a secondary step. An unsuccessful notification does not undo the underlying customer request. The application team owns recovery.

Those statements give the team something concrete to compare with the proposal. “The integration was approved” does not. If the original scope or conditions are unclear, resolve that uncertainty before treating the new work as covered.

An architecture decision record (ADR) can preserve that reference. AWS’s ADR guidance describes checking software changes against agreed decisions and superseding a record when the decision changes. Keep the earlier reasoning accessible when recording a replacement.

An architecture approval also does not automatically authorize a release. Security, operational, or other required reviews may still apply.

Architecture review checklist: five change triggers

1. Information crosses a different boundary

A new recipient, additional message content, or a different storage location can change the basis of the original design. Ask what information moves, where it goes, and whether the earlier decision covered that flow.

In the example, sending a delivery reference is different from sending the full customer request. Even if both produce the same notification, the team needs to understand which version it is proposing. The application and relevant data or security owners should review the affected boundary under the organization's process.

2. An actor gains different authority

A service that could previously read a status may now be able to update it. A background task may inherit access that was previously limited to a person. A new administrative action may affect more customers than the original workflow allowed.

Describe the additional action and its reach. A familiar service name does not establish that its new authority is already approved.

3. A dependency takes on a new responsibility

Adding or replacing a dependency matters when the system relies on it for something the earlier decision assigned elsewhere. In the example, the external service might handle delivery, retries, or message preparation. Each choice changes the responsibilities that need an owner.

A version update within an established maintenance policy may need no new architecture decision. Moving an essential responsibility to a new provider is a different question. Check the scope of the existing policy rather than assuming every dependency change needs the same review.

4. Failure means something different

The normal flow can stay the same while timeout, duplicate, delayed, or unsuccessful requests behave differently. These changes are easy to miss when the proposal focuses on the successful demonstration.

Suppose notification delivery becomes a prerequisite for accepting the customer's request. A notification outage can now block the main workflow. That changes a central assumption of the reviewed design, even if the interface looks identical when everything works.

Ask who detects a failure, who can recover from it, and what the user is told while the outcome is unresolved.

5. A business assumption no longer holds

A design may have been accepted for a limited rollout, a specific user group, or a defined operating window. Expansion can change the consequences of a failure or invalidate a trade-off that was reasonable earlier.

For example, a manual recovery step that the owner accepted for a limited pilot may need another look before a broader rollout. Name the changed assumption and ask whether the original rationale still applies. Martin Fowler’s overview of ADRs recommends recording context changes that should prompt a decision to be reevaluated. Avoid inventing a universal threshold; the relevant limit belongs to the decision and the organization's requirements.

Illustrative guide

From a proposed change to the right review

01 · Proposed changeDescribe what will behave differently, including failures.

↓

02 · Affected assumptionCheck data boundaries, authority, dependencies, failure behavior, and business scope.

↓

ProceedThe existing decision covers the change; follow the applicable delivery checks.

Focused reviewAsk the responsible owner to resolve a specific question.

Revisit the decisionReconsider a changed assumption and record the consequences.

Choose the smallest review that can resolve the question

A trigger identifies a question. It does not, by itself, determine whether the proposal is acceptable or require every decision to return to a full committee.

Proceed within the existing decision. The team can show that the proposal remains inside the reviewed scope and conditions, and the applicable process permits it. Link that conclusion to the existing decision and continue the normal engineering and release checks. For example, adjusting notification wording within an approved content boundary may leave the architecture unchanged.

Request a focused review. A specific boundary or responsibility needs confirmation, while the wider design remains applicable. Identify the question and the owner who can answer it. For the external notification service, this could mean reviewing the proposed message content and recovery ownership before proceeding with that integration.

Revisit the architecture decision. The proposal changes a central assumption or trade-off. Making the main workflow depend on successful notification delivery is a reason to reconsider the original availability and failure-handling choice. Compare the alternatives again and carry the outcome into requirements, tests, and delivery work.

When a material fact is missing, assign an owner to establish it. Make clear which work depends on the answer. An unanswered question should not become implicit approval because the delivery date is close.

What to include in an architecture review request

A useful request lets the reviewer understand the change without reconstructing the project. Include:

• The proposal: what will behave differently, including failure cases.
• The reference: the earlier decision and the scope or condition it established.
• The affected assumption: which boundary, responsibility, or trade-off may change.
• The evidence: the relevant interface description, proposed data flow, test result, or stakeholder confirmation; distinguish what is known from what still needs investigation.
• The owner and next action: who can decide, what work depends on the answer, and how the outcome will reach engineering.

For the notification example, the question might be: “Does the proposed external delivery service fit the existing message boundary, with recovery still owned by the application team?” If the answer is yes with conditions, make those conditions visible in the handoff. If the service changes the underlying workflow, record the revised architecture decision and its consequences.

Keep the basis of approval available

An approval is easier to use when its reasoning remains connected to the work. Reviewers can assess a proposed change more directly when they can find why the earlier choice was made, what it covered, and which conditions remain open.

Archangel's Decision Trace connects architecture decisions with supporting context, review, and downstream work. The technology overview explains that capability. The practical test for a team is straightforward: can someone proposing a change find the decision it affects and ask the right owner a specific question?

Before requesting another architecture review, ask: what changed, which assumption does it affect, who can decide, and what evidence do they need? A clear answer helps the team direct review effort to the decision that actually needs attention.