The Method / Architecture Synthesis / Part III — The derivative

Architecture as a Derivative

Lesson 1 of 3 · Part III — The derivative

In this lesson

Chapter 1 planted a definition and deferred it: an architecture is a derivative — the next correct step from where the system stands, given the forces acting on it now. Part II ran that computation from blank pages. Part III runs it where almost all real engineering happens: on systems that exist, carry history, and keep living while the answers move underneath them. This chapter establishes the calculus; the two after it handle the walking and the inheriting.

The reframe is one substitution. next_step never required an empty starting point — step 0 said start from where the system stands, and greenfield was merely the case where it stands nowhere. Feed the procedure a real system’s current vector and its current answers, and three distinct operations fall out of one function, depending on what moved since last time.

Nothing moved: the audit

Run the derivation with unchanged answers against the current vector, and the output should be no change. That sentence sounds vacuous and is the opposite: it is a mechanical test that every position the system holds is still forced by a live answer — and it fails in a specific, useful way. Any position the answers cannot force is flagged, and the flag has a name this book has been building toward since Chapter 1: a position no answer forces is technical debt — by construction, not by opinion. You are paying an always-on cost, per the ledger, for a capability no row of the sheet demands. One pre-commitment keeps the label honest, of the same kind the blind runs made for the topology rule: if audits keep surfacing unforced positions that demonstrably earn their cost — option value exercised, not merely claimed — the finding is a missing question, not debt, and the sheet grows the way the ledger does. A label that names its own disconfirmation is entitled to be mechanical; one that cannot be wrong is just vocabulary.

This flips the industry’s debt conversation on its head. Debt is usually diagnosed by feel (the code smells, the team grumbles, a consultant frowns) and contested by the same means. The audit diagnoses it by citation: name the answer that forces this position. Silence is the finding. Chapter 1 promised the thirty-second version: three services sharing a database and deploying in lockstep, where no live answer demands the deployment split and the flag arrives almost before the question finishes. The worked version needs no new system: run it on the enterprise platform Chapter 6 derived. Feed next_step that vector and its own answer sheet, unchanged, and every position re-derives to itself — the read-path split still forced by the 200-millisecond contract, event-sourced pricing still forced by the replay mandate, the distributed store still the one container for strict-across-regions. No change on every axis is what a healthy system under audit looks like: not fashionable, cited. Here the verdict is cheap — the derivation is pages old and nothing has moved. The audit earns its keep on systems whose answers have had years to drift from their structure: run at that scale on a long-lived payroll platform (the full story is Process-First Design’s brownfield chapter), the same re-derivation came back no change on every axis, every “except” and special case cited rather than grandfathered.

A word about people, because audit findings land on them. A position flagged as unforced is not a decision flagged as wrong: the answers may have moved since it was made — yesterday’s forced position is today’s unforced one with no error anywhere in the chain — and the audit cannot distinguish a mistake from a world that changed, which is precisely why it should never be asked to assign blame. The vocabulary is load-bearing: positions are “unforced” or “no longer cited,” never “wrong”; the decision record’s revisit-when trigger is the graceful exit built in advance: the original decider named the conditions under which their decision would expire, and the audit merely reports that the conditions arrived. Run this way, the audit is adoptable in organizations where architecture reviews have historically been careers colliding; run as a blame instrument, it will be gamed into uselessness within a quarter, and will deserve it.

The audit’s other output is cultural. A system that can answer “why are you shaped this way?” row by row is a system whose architecture discussions have terminating conditions — Chapter 1’s promise, extended from design meetings to the standing estate.

One answer moved: incremental recomputation

Answers change one at a time far more often than they change wholesale — a contract lands, a regulator rules, a growth curve bends. The pressure matrix makes the consequence surgical: every position cites the rows that force it, so a changed row implicates exactly the axes it presses and no others. Re-derive those axes; everything else is untouched by construction, not by hope.

The same platform carries the worked case. One answer moves: the regulation demanding quote reconstruction under past rule versions is superseded, and no data class now carries a replay demand. The pressure matrix implicates exactly the rows that cited replay — pricing’s storage, and nothing else. Re-derive that axis: event-sourced pricing, the most expensive value the whole derivation bought, recedes to current-state with an audit log. The quote path’s separation stays — the 200-millisecond contract and the storm shape still force it, and its projections now rebuild from current state — but the versioned event schemas, the replay machinery, and the unbounded log fold away. Everything else — booking, the distributed store, the split — re-derives to itself. One lapsed answer, one moved axis, and — the half the industry finds harder — a merge as the computed output. The procedure is direction-neutral: it recommends consolidation with exactly the confidence it recommends splitting, because both are just containment arithmetic. Note how rare that sentence is in this literature. Migration guides run one way; the derivative runs both.

The audit and the increment compose into an operating rhythm: audit on a cadence (or on every planning cycle), recompute on every changed answer. Neither is a project; both are habits with artifacts.

The trail: decision records that write themselves

A derivation’s pressure matrix, kept, is the document every inheritor of every system wishes existed: which answers forced which positions, dated. The habit costs one page per axis move — position, forcing rows, mechanism, costs accepted, and the revisit trigger: this decision expires when these answers change. That last field converts decision records from archaeology into instrumentation — a standing list of which business facts are load-bearing for which structures, consulted forward rather than excavated backward.

The trail also closes a loop this book opened at the SEI gap. Elicitation feeds derivation; derivation leaves records; records make the next elicitation cheaper and the next audit mechanical. The disease the brownfield chapter will confront — a system whose reasons died with its authors — is, for systems built under this method, structurally prevented rather than heroically cured.

What the derivative is not

Two misreadings are worth closing at the source, both because they are natural and because Chapter 7’s evidence answers them.

The derivative is a prediction of what organizations will build. It is a computation of what the answers force. Chapter 7’s fourth run put the gap on public record: the derivation predicted the forced minimum, the organization had chosen fine-grained decomposition no published demand forced, and the miss was the audit detecting an unforced position through a blind fold — the same test, run without access, still found the uncited structure. Whether an unforced position is debt or an unpublished demand is a question for the owner; that the question now has a precise form is the contribution.

The derivative is continuous re-architecture. The regime insight guarantees the opposite: most answer changes press nothing — they land inside containment and the derivative returns “no change” at the cost of a table lookup. Systems under this calculus move less than fashion-driven ones, because fashion is a pressure the matrix has no row for.

One case remains, and it is the hard one: several answers moved, or the audit found a vector that was never derived in the first place, and the computed next step stands far from where the system is. Between here and there lie intermediate states, each of which must keep running a business. Getting from a vector to a vector is a path problem, and paths through living systems have physics of their own.

Rules exercised: next_step with a non-null starting vector · the audit (position ⇒ citing answer, silence ⇒ debt) · incremental recomputation via the pressure matrix · merge as a first-class output · decision records with expiry triggers · the forced/chosen boundary, applied.

Exercise — Audit One Position ~20 min

Pick one architectural position in a system you operate — a split, a store, a queue — and try to name the specific answer that forces it today. If you can cite one, note it. If you can’t, you’ve found either technical debt or a missing question on your sheet.