⌘ The Architecture Reference

Path elevator · The Architect's Path · Intermediate

Architecting for Change and Options

The rate of change is the real driver of architecture — architects 'live in the first derivative' and create value by selling options: deferring decisions until uncertainty resolves.

Path elevator Intermediate ⏱ 5 min read Complete

⛷️ Analogy

A ski resort sells a discounted season pass months in advance. Buying it commits you. The alternative — paying full price on each visit — costs more per day but lets you defer the decision while the conditions (snow, schedule, injury) reveal themselves. Architecture is full of these trade-offs: you pay a premium to keep your choices open.

For Hohpe, the single most important driver of architecture is the rate of change. A system that never changes needs no architecture at all. So good architects “live in the first derivative” — they care about how quickly a system’s value and state change over time, not just its static structure.

The first derivative

Change arrives in many forms: new functional requirements, growing traffic and data, a shifting runtime environment, a changing business context. Crucially, a software system’s first derivative is its build-and-deployment toolchain — every change flows through CI/CD, so raising the rate of change means tuning that pipeline.

graph TD
C["Change arrives<br/>(features, traffic, context)"] --> T["Build & deployment toolchain<br/>(the first derivative)"]
T --> S["System value over time"]
D["Dependencies"] -.->|"impede"| T
F["Friction (manual deploys)"] -.->|"impede"| T
Q["Poor quality"] -.->|"impede"| T
FE["Fear"] -.->|"impede"| T
A["Automated tests"] -.->|"enable confidence → speed"| T

What impedes change? Dependencies (decoupling is the biggest contributor to sustained delivery, per Accelerate), friction (long provisioning, manual deploys), poor quality (which slows rather than speeds delivery), and fear. Fear is a spiral: poor quality plus low automation makes change risky, which makes developers afraid, which lets code rot, which raises risk further.

🔑 Confidence brings speed

Automated tests raise the rate of change. Hohpe’s 20-line test: propose deleting 20 arbitrary lines of code. A team that would push the change straight to production has enough confidence — and enough coverage. “The change that’s never made out of fear cannot be accelerated by the world’s best toolchain.”

Architecture is selling options

The deeper economic argument: a good architect does not make many irreversible decisions early, because early is the time of highest ignorance. Instead, the architect sells options — the right, but not the obligation, to make a choice later at fixed parameters.

This is a financial option, and the Black-Scholes formula mathematically proves options have value. Two variables increase that value:

  • Uncertainty (volatility). Elastic scaling has little value for a constant user base, but high value for an app that might serve 100 or 100,000 users. Volatility sits in the numerator. The implication is profound: the business must be involved in technical decisions, because IT alone cannot judge how volatile the future is.
  • Time (maturity). The longer until you must decide, the more the option is worth — which is why a project manager (short horizon) and an enterprise architect (years) rationally value the same option differently.
graph TD
V["Higher uncertainty<br/>(volatility)"] -->|"increases"| OV["Option value"]
T["More time<br/>until decision"] -->|"increases"| OV
SP["Higher strike price"] -->|"decreases"| OV
OV -->|"defer at fixed parameters"| CH["Choice kept open"]

Strike price and the cost of options

Options are never free. You pay in complexity, or by giving up another option. The strike price is what it will cost to exercise the choice later:

  • Migrating to a cloud provider lowers the strike price to scale (automation handles it) but raises the strike price to switch providers (lock-in).
  • Building a cloud-abstraction layer lowers switching cost — but is itself an expensive option.

⚠️ Don't minimize every strike price

The lowest strike price is the ideal but rarely the most economical choice. Offer a range of options at different strike prices and let the business pick. Coding to an open-source interface is arbitrage — a cheap, near-risk-free option that is also just good practice.

Myers and Trigeorgis catalog the real options architecture grants: the option to defer, to abandon (salvage modules), to expand (scale out), and to contract (elastic reduction).

💡 Agile and architecture are friends

Both deal with uncertainty, and the value of each grows with uncertainty — the opposite of big up-front design. When you cannot know the options far enough ahead, build an evolutionary architecture guided by a fitness function rather than committing to a fixed end state.

See also

When to use it — and when not

✅ Reach for it when

  • When uncertainty is high and committing early would be the time of greatest ignorance.
  • When you want to measure architecture by the system's ability to absorb change, not by decisions made.
  • When the cost of a future change (the strike price) can be lowered cheaply today.

⛔ Think twice when

  • When a decision is genuinely cheap to reverse later — buying an option you don't need just adds complexity.
  • When minimizing every strike price is uneconomical; offer a range of options instead.
  • When the option's underlying uncertainty is low, so the option has little value.
path-elevatorThe Architect Elevator

The architect's job is to ride between the penthouse (business strategy) and the engine room (where software is built), translating in both directions and keeping the floors in sync.

path-elevatorThe Architect's Many Roles

No single archetype defines a good architect — the master planner, gardener, guide, and glue are all partial truths, and seniority rests on three legs: skill, impact, and leadership.

path-strategyWhat Is Technology Strategy?

Strategy is the art of creating power — technologists win funding by speaking the language of business, using proven patterns to analyze, create, and communicate a fundable course of action.

Check your understanding

Score: 0 / 4

1. What does it mean that architects 'live in the first derivative'?

A system that never changes needs no architecture. Because architects deal with change, they focus on how fast a system's value and state change — the first derivative. A software system's first derivative is its build-and-deployment toolchain.

2. In 'architecture is selling options', what is an option?

Borrowed from finance: deferring a decision while fixing its parameters has provable value (Black-Scholes), so good architecture — which defers irreversible choices — has value.

3. What increases the value of an option?

Volatility sits in the numerator of Black-Scholes: scaling has little value for a constant user base but high value for an app that might have 100 or 100,000 users. More time to maturity also raises value.

4. Why is measuring an architect by 'decisions made' a bad KPI?

Deciding early is deciding at the time of highest ignorance. A good architect eliminates irreversibility and defers — so counting decisions punishes the right behavior.

Comments

Sign in with GitHub to join the discussion.