When the Build Moves Away From the Approved Architecture

An approved design sends customer updates through an internal service. During implementation, an engineer adds a direct connection to an external processing service to simplify one step. The tests pass, the feature works, and the new connection is easy to miss in a large change.

The implementation now has a data flow that the architecture review did not consider. That does not tell the team whether the change is unacceptable. It tells the team that the basis of approval and the implemented design have diverged, and that the difference needs a decision.

This illustrative example shows how to handle that decision. Architecture drift is useful to detect because it identifies a question the team must resolve while the relevant context is still available.

Establish the reference before comparing the build

The approved architecture should identify the interaction boundary and why it exists. Perhaps the internal service controls which fields may leave the application. Perhaps it provides the review point for a downstream operation. A diagram with an arrow is less useful than a diagram connected to that rationale.

Record the applicable version and review outcome. A comparison against an abandoned design creates noise. A comparison against a vaguely described intention creates arguments about what was ever agreed.

In the example, the decision states that customer updates reach downstream processing through the internal service because that service owns filtering and operational review. The direct connection therefore bypasses a reasoned boundary, not merely a preferred drawing convention.

Describe the deviation in terms a reviewer can act on

A useful finding identifies the observed change, the affected architecture element, the relevant constraint or decision, and the evidence for the comparison. “Architecture mismatch” leaves too much investigation to the recipient.

The finding in this case could say: the new handler calls the external processor directly; the approved flow routes those requests through the internal service; the associated decision assigns filtering to that service. The reviewer can then inspect the implementation and the original reasoning together.

Be precise about coverage. A check can only compare the implementation and constraints available to it. A clean result should be read within that scope, rather than as evidence that every aspect of the system matches every intended requirement.

Ask whether the implementation or the decision should change

There are several legitimate outcomes. The direct connection may be an error and should be removed. It may reveal that the approved design is unnecessarily restrictive. Or the available evidence may be insufficient to decide.

The engineer should explain the reason for the change. The relevant owner should assess the impact on the original constraint. If the internal service was bypassed because it cannot support the required workflow, reverting the code without addressing that limitation simply postpones the issue.

A revision to the architecture needs its own rationale and review. A team should be able to follow why the earlier choice was made and why the new evidence justified a different one. Updating a diagram to match the code, without that decision, loses the point of the review.

Carry the outcome into delivery work

Suppose the team decides to retain the original boundary. The implementation task is to route the new behavior through the internal service, and the validation work should exercise the filtering and failure cases that motivated it.

If the team instead approves a direct connection, the handoff must identify who owns the responsibilities previously held by the internal service. That may create new requirements, tests, and operational work. The approval should state which conditions remain before release.

If an important fact is still unknown, give the investigation an owner and identify the work it blocks. An unresolved deviation should not quietly become accepted architecture because the release date arrives.

Check that the resolution actually closes the gap

After the change is made, compare the relevant implementation again. Confirm that the resolution addresses the original issue and that the architecture, review record, and delivery tasks agree. A closed ticket alone does not show that the boundary has been restored or deliberately revised.

Archangel's drift detection compares the build against approved architecture and flags deviations with the relevant standard or decision. Decision Trace preserves the reasoning behind the reference being checked. Together, those capabilities help a team investigate the gap and make the next decision with its context intact. The technology overview describes their role in the workflow.

The practical goal is a short path from a detected difference to an accountable decision. Ask of each finding: what changed, why does it matter, who can decide, and what evidence will show the resolution is complete? Those questions let drift review support delivery instead of becoming an accumulating list of unexplained warnings.