Architecture Decision Record with Future-Option Cost¶
Decision record — instantiates Second-System Complexity Restraint
Records each architectural choice together with the priced cost of the future option it keeps open — so "build it flexible now" has to pay a visible tax.
A plain architecture decision record captures what was decided and why. This variant adds the term the second-system moment keeps hiding: the future-option cost — the extra complexity, carrying cost, and coupling a team pays now to keep a not-yet-needed capability reachable later. Its one defining idea is that generality is never free. Every "let's make it extensible so we can add X someday" must name the someday it is buying and post a price against the successor's complexity budget on the same page as the decision. The record forces a single architectural choice — not a whole release — to state where its flexibility boundary sits and what keeping the door open costs.
Example¶
An engineering team is building the successor to an electric-vehicle charging network's station-management backend. The first system spoke one charging protocol and did it reliably. Now someone proposes a protocol-abstraction layer so the backend could support future standards — plug-and-charge, bidirectional charging — none of which any deployed station uses yet. Instead of settling it by argument, the team opens an ADR. It records the decision, the rationale, and then the future-option cost: the abstraction adds a configuration surface across three services, couples the session manager to a plugin registry, and adds roughly a quarter of build time and an ongoing test matrix — all to keep reachable a capability with no current customer.
Written down and priced against the budget, the option looks worse than its intuition. The record's outcome is not "never do it" but a drawn boundary: ship one protocol now, leave a documented seam where the abstraction would attach, and file the abstraction in the deferred-ambition backlog with its price already attached. When a second protocol actually lands on the roadmap, the ADR is reopened rather than re-argued from scratch.
How it works¶
The unit is a single decision, not a plan. To the usual context/decision/consequences fields it adds three moves:
- Enumerate the options as flexibility levels — from "build exactly what today needs" up through progressively more general designs, each keeping more future doors open.
- Price each option's future-option cost in the successor's own budget units (config surface, coupling edges, build weeks, ongoing test/operate load), separated from the cost of the feature actually shipping now.
- Draw and record the flexibility boundary — the explicit line between what is built now and what is merely left a seam for — and file every door left closed as a priced backlog entry, so a deferred option is remembered with its cost, not lost.
Tuning parameters¶
- Option horizon — how far into the imagined future the record prices. A longer horizon surfaces more speculative generality but invites pricing fiction; short horizons risk foreclosing cheap, obvious seams.
- Pricing granularity — a rough T-shirt size versus an itemized cost. Finer pricing sharpens the decision but adds ceremony and false precision to numbers that are, after all, guesses.
- Reversibility discount — how much to shrink an option's cost when the decision is cheap to revisit later. A high discount rightly favors deferring; set too high, it lets teams wave away real lock-in.
- Boundary sharpness — whether the seam is a hard interface or a vague "we could extend here." Sharper seams cost a little now and save a lot later; vague ones are theater.
When it helps, and when it misleads¶
Its strength is that it puts a number on the most seductive second-system move — building for an imagined future — and thereby operationalizes the discipline that architects otherwise only preach: you aren't gonna need it.[n1] A priced option is far easier to defer than an unpriced aspiration, and the recorded boundary means the deferral is remembered rather than silently reversed six weeks later.
Its failure mode is false precision: the future-option cost is a forecast, and a tidy figure can lend unearned authority to a guess, especially about speculative capabilities no one has scoped. The classic misuse is running it as theater — writing the record after the flexible design was already chosen, to launder a preference into a business case. It can also over-correct: price every seam pessimistically and a team builds something so rigid the first real change requires a rewrite. The guarding discipline is to treat the cost as an argument whose assumptions must hold, mark speculative options as speculative, and reopen the record when the future it priced actually arrives — rather than freezing the first estimate into dogma.
How it implements the components¶
architecture_flexibility_boundary— the record's core output is the drawn line between build-now and leave-a-seam; the ADR is where that boundary is stated and defended for one decision.complexity_and_scope_budget— each option's future-option cost is expressed in budget units and posted as a line-item, feeding the successor's running complexity total.deferred_ambition_backlog— every door the boundary leaves closed becomes a backlog entry carrying its already-computed price, so a deferred option is retrievable, not forgotten.
It does not score whether a proposed feature is admitted to this release — that item-level judgment is the ambition_triage_gate, owned by Feature Admission Rubric — and it does not audit cumulative burden on a launchability_review_cadence; that belongs to Complexity Budget Review.
Related¶
- Instantiates: Second-System Complexity Restraint — supplies the priced, boundary-drawing decision the appraisal hangs each architectural choice on.
- Consumes: Complexity Budget Review — provides the running budget an option's cost is charged against.
- Sibling mechanisms: Complexity Budget Review · Constraint-Release Inventory · Feature Admission Rubric · Parity-Then-Expansion Gate · Postlaunch Ambition-Thaw Review · Rewrite Scope Firewall · Second-System Premortem · Staged Release Ladder · Successor Charter
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Records each architectural choice together with the priced cost of the future option it keeps open — so 'build it flexible now' has to pay a visible tax, making its operative form a durable account of actual events, decisions, or transitions whose value depends on history or provenance.
Independent corroboration: The frozen evidence defines Architecture Decision Record with Future-Option Cost as 'Records each architectural choice together with the priced cost of the future option it keeps open — so 'build it flexible now' has to pay a visible tax', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: The base artifact is a software Architecture Decision Record, extended here to price speculative flexibility and resist second-system overdesign.
Related originating lineages:
- Economics & Finance — Real-options and opportunity-cost reasoning provide the pricing logic.
- Engineering & Design — Lifecycle and reversibility analysis inform future seams.
- Organizational & Management Science — Complexity budgeting and portfolio discipline govern deferred ambition.
Review resolution: The base ADR and YAGNI lineage is software engineering. Real-options pricing, lifecycle and reversibility analysis, and organizational complexity budgeting materially form the future-option-cost extension, making the named mechanism an Encyclopedia synthesis.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] You Aren't Gonna Need It — the Extreme Programming maxim that you should not build capability until an actual, present need requires it, because the cost of speculative generality (build, carry, and later un-build it) usually exceeds the cost of adding it when the need is real. The future-option cost line is exactly the tax YAGNI warns is being paid silently. ↩