A familiar architecture review goes like this. The team presents the current architecture. Then they present the proposed architecture. The board looks from one slide to the other, trying to see what is different. Someone notices a new box. Nobody notices that an arrow has moved. Forty minutes are spent on the parts that did not change, because those are the parts everybody understands.
The problem is not the people. It is the format. Two complete pictures are a poor way to communicate a change, for the same reason that two complete copies of a contract are a poor way to communicate an amendment. Software engineering solved this decades ago with the diff. Architecture review mostly has not.
Marula Commerce is fictional, and its systems and figures are illustrative. Marula is adding a second courier for faster Gauteng deliveries. Rather than connecting the shop platform to a second courier API directly, the team proposes a small delivery service that sits between the shop and both couriers.
Before, delta, after
The delta is the middle panel, and it is the one the review should read. For Marula, it has four lines:
- Added: a delivery service, owned by the logistics technology team.
- Added: an integration with Courier B.
- Changed: the shop platform now calls the delivery service instead of Courier A.
- Removed: the direct call from the shop platform to Courier A.
That is the whole change. The catalogue, payments, warehouse and everything else are untouched and do not need to be discussed. A review that starts from those four lines can finish in fifteen minutes and ask better questions than one that starts from two full diagrams.
Each kind of change has its own question
A delta also tells the reviewer which question to ask, because different kinds of change carry different risks.
An added component raises ownership and running cost. Who builds it, who operates it, who is woken up when it fails, and what does it cost per month? For Marula: the logistics technology team owns it, and it runs on the existing container platform.
A removed component or relationship raises dependency. What relied on it, and where does that function live now? For Marula: the shop platform's direct courier call also wrote a tracking number back to the order. The delivery service must now do that, or tracking breaks. This was found because the delta listed the removal explicitly.
A new relationship raises data and failure. What crosses it, how sensitive is it, and what happens when it is unavailable? Customer delivery addresses now cross to Courier B, which typically makes Courier B an operator processing personal information on Marula's behalf under POPIA, so the contract with Courier B needs to cover that processing.
A moved boundary raises controls. If a component moves from inside the trusted network to outside it, or from one team's ownership to another's, which security rules, access rights and support arrangements change with it?
These four questions do not depend on the technology. They work for a cloud migration, an ERP replacement or the introduction of an AI agent.
Producing a delta
There are three ways to produce one, in increasing order of rigour.
By hand, as a list. The simplest version is a short table: added, removed, changed, with one line each. It can sit on the first slide of any architecture review. It costs ten minutes and changes the conversation.
From a source model. If the architecture is held as a structured source file rather than only as images (see Part 6), two versions of the file can be compared mechanically. Tools that do this produce a before, delta and after view directly. Archify's compare command, for example, produces this three-panel view from two validated architecture sources. Like any such tool, it reports what changed in the model and does not infer impact or risk; that remains the reviewer's job.
From the implementation. Where the source model is partly derived from code and infrastructure, the delta can be generated as part of a pull request: this change adds a new outbound dependency, this one removes a queue. That is the most powerful version and the one most dependent on good tooling and conventions. Part 8 discusses what such automation can and cannot do.
What a delta does not show
A delta shows what changed in the model. It does not show:
- why the change was made (that belongs in a decision record);
- whether the change is a good idea (that is the review);
- changes that were never recorded in the model, such as a new direct database read added in code without anyone updating the architecture.
The last point is the important one. A delta is only as complete as the model it is computed from. That is why the evidence levels from Part 6 matter: a delta between two models that are mostly "assumed" will look precise and mean little.
Why deltas matter more as change speeds up
Organisations using AI coding agents are already seeing more change, in smaller increments, from more people. A team that used to propose one architectural change a quarter may now produce several a month, many of them introduced by an agent working through a backlog. Two-picture reviews do not scale to that rate. Either the board meets far more often, or changes slip through without review.
A delta-first approach scales better, because most deltas are small and many are routine. A new outbound dependency to an approved internal service may need only a recorded acknowledgement. A new relationship that sends personal information to an external party needs the full board. The delta tells you which is which before anyone opens a diagram, and the rules for routing changes can be written down in advance.
This is the same idea as code review applied to architecture: review the change, at the size it actually is, with the questions it actually raises.
A practical change to your review template
- Every proposal starts with a delta table: added, removed, changed, moved.
- Each row has an owner and a link to its decision record.
- The board asks the matching question for each row.
- The full before and after diagrams are appendices, not the main presentation.
- After approval, the "after" becomes the new baseline, with a date.
Teams that adopt this usually find two things. Reviews get shorter, and more problems are found in them, because attention goes where the change is.
Next: Part 8, Living architecture documentation without pretending it is automatic. All parts are on the series page. For the transition states between current and target architecture, see As-is, bridge states and to-be.
How CloudNala can help
We help architecture boards adopt delta-first review templates and help teams express proposed changes as added, removed, changed and moved, with owners and decisions attached. Where architecture is held as source, we help set up comparison so that deltas come from the model rather than from memory.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request an Architecture Review or write to us at consult@cloudnala.co.za