Architecture is not every technical choice, and it is not a separate phase that produces a definitive diagram. It begins where a choice changes the economics of future choices. Selecting a local parsing library is usually implementation. Choosing the identifier that customers will store, the data boundary that determines ownership, or the consistency model that every workflow assumes is architecture because reversing it later requires coordination, migration, and risk.

This suggests a more useful way to allocate architectural attention. Do not ask whether a decision is “technical” or “architectural” as if there were a clean border. Ask how hard it will be to reverse, how costly it is to obtain evidence, how many parties will depend on it, and how damage would be detected. Different answers justify different decision processes.

I use Decision-Driven Development here as a practical label for that operating model: identify consequential decisions, acquire enough evidence, preserve an exit, deliver, and revisit. It is not the official name of a Carnegie Mellon Software Engineering Institute method. The SEI method applied in this article is Attribute-Driven Design (ADD), which bases architecture design on architecturally significant requirements and recursively selects tactics and patterns to satisfy them. That distinction matters because a memorable label should not become a false attribution.

Abstract architectural decision paths showing reversible loops and a costly point of no return.
Architecture becomes deliberate where a choice changes the cost and safety of the next choice.

Architectural significance is a cost curve

A decision does not become architectural because a senior person made it. It becomes architectural as its reversal cost rises. That cost is rarely just engineering time. It includes data conversion, contract compatibility, customer migration, retraining, operational risk, regulatory review, parallel running, and the opportunity cost of pausing other work.

The curve is often nonlinear. Changing an internal field name before release is trivial. Changing it after ten services persist it is a programme. Changing it after customers sign payloads containing it may require a versioned public transition. The code can look almost identical while the surrounding dependency network changes the decision class.

The SEI’s Attribute-Driven Design method collection makes a related distinction through architecturally significant requirements: functional requirements, quality attribute requirements, and constraints that shape the architecture. ADD does not attempt to design every detail upfront. It chooses an element to decompose, identifies its architectural drivers, selects design concepts, allocates responsibilities and interfaces, then repeats.

Reversal cost adds an economic lens to that recursion. For each decomposition, ask which choices will become constraints for the next one. A database technology behind a stable repository may remain replaceable. A tenant key embedded in every table, event, URL, permission rule, and invoice becomes an organisational commitment. Both are “database decisions”; only one establishes the future shape of the system.

The purpose of architectural work is not to eliminate change. It is to keep the cost of likely change visible, intentional, and affordable.

Replace adjectives with a quality-attribute scenario

Teams routinely ask for a platform that is scalable, resilient, secure, and flexible. Those words express direction but cannot discriminate between designs. A decision needs a situation and a measurable response.

The SEI Quality Attribute Workshop engages stakeholders early to discover driving quality attributes and refine them into prioritised scenarios. A scenario gives an adjective operational meaning by identifying a source, stimulus, affected artefact, environment, response, and response measure.

Consider a service that sends regulated customer notifications through an external delivery provider. “The notification service must be resilient” is too broad. A designable scenario is:

  • Source: the primary delivery provider.
  • Stimulus: it times out for three consecutive health intervals.
  • Artefact: the notification dispatch path and delivery ledger.
  • Environment: peak traffic of 5,000 accepted messages per minute.
  • Response: stop new calls to the failed provider, route eligible messages through a secondary provider, retain an auditable outcome, and suppress duplicates.
  • Measure: failover starts within 90 seconds; no accepted message is lost; fewer than 0.01% of recipients receive a duplicate; the operator can trace every attempt.

These numbers are illustrative, not a universal target. Their value is that they expose decisions. A 90-second response may permit health polling; a five-second response may require a different detection and routing mechanism. A strict duplicate limit forces a durable idempotency strategy. An audit requirement constrains what can be discarded during recovery. The scenario turns “use two providers” from an architectural fashion into one candidate response to explicit qualities.

It also exposes what not to decide. The secondary provider’s SDK can remain a replaceable adapter. The identity and semantics of an accepted message are much harder to revise after audit records, retries, customer support, and downstream analytics depend on them.

Use two costs to choose the process

Reversal cost is only one dimension. Evidence also has a cost. Some consequential choices are easy to test before commitment; others require production traffic, a procurement cycle, a failure exercise, or months of behaviour. Treating every cell alike creates either bureaucracy or unmanaged risk.

Decision treatmentUse reversal cost and evidence cost to decide how much process and experimentation a choice deserves.
Reversal / evidence costLowHigh
LowDecide locallyInstrument the result, ship a small change, and retain a straightforward rollback.Explore cheaplyRun a time-boxed spike or controlled cohort while the old path remains available.
HighPrepare the transitionRecord the decision, validate compatibility, and rehearse migration and reversal before adoption.Delay lock-inPrototype competing concepts, involve affected stakeholders, and buy information before creating dependencies.

This is not a governance scorecard. It is a conversation about treatment. “High” depends on context: a schema reset may be cheap for a prototype and unacceptable for a regulated ledger. Evidence cost also changes as the organisation improves its test data, observability, traffic controls, and ability to run experiments.

The practical aim is to move decisions left or down. Interfaces, compatibility layers, feature flags, dual reads, export formats, and rehearsed restoration can reduce reversal cost. Simulations, prototypes, load tests, threat modelling, and small production cohorts can reduce evidence cost. These mechanisms do not make a decision correct. They make learning less expensive.

Run design as a decision loop

The ADD 2.0 technical report describes a recursive decomposition guided by quality attributes, architectural tactics, and patterns. Later ADD 3.0 material places additional emphasis on design concepts and iterative use in more agile settings. A delivery team can operationalise those ideas as a loop rather than a preliminary ceremony.

The decision loopEvery pass should reduce uncertainty, test a quality claim, or preserve a valuable option.
  1. FrameName the business outcome, constraints, and measurable quality-attribute scenario.
  2. ChooseCompare tactics and patterns, including their trade-offs and cost of reversal.
  3. DeliverImplement the smallest coherent slice that can produce trustworthy evidence.
  4. ObserveMeasure behaviour, operations, cost, and effects on other stakeholders.
  5. RevisitKeep, adapt, supersede, or reverse the decision; then select the next driver.

The loop prevents two common failures. The first is speculative architecture: making several irreversible choices before their drivers are understood. The second is architecture by accident: shipping local optimisations until their combined coupling becomes expensive to unwind.

Each pass should leave a small decision record. Capture the scenario, options considered, selected tactic, consequences, evidence to watch, reversal mechanism, owner, and revisit trigger. A record without a trigger becomes history; a trigger without evidence becomes opinion.

Example: preserve the message, replace the provider

Return to the notification scenario. The high-cost decision is the semantic contract around a message: its stable identity, acceptance boundary, audit history, and duplicate policy. The lower-cost decision is which provider delivers it today. The code should reflect that asymmetry.

typescript
type AcceptedMessage = Readonly<{
  id: string;
  recipient: string;
  template: string;
  acceptedAt: Date;
}>;

type DeliveryResult =
  | { status: "delivered"; providerReference: string }
  | { status: "retryable"; reason: string }
  | { status: "rejected"; reason: string };

interface DeliveryPort {
  send(message: AcceptedMessage, idempotencyKey: string): Promise<DeliveryResult>;
}

export class DispatchNotification {
  constructor(
    private readonly primary: DeliveryPort,
    private readonly secondary: DeliveryPort,
    private readonly ledger: DeliveryLedger,
  ) {}

  async execute(message: AcceptedMessage): Promise<DeliveryResult> {
    const previous = await this.ledger.findCompleted(message.id);
    if (previous) return previous;

    const first = await this.primary.send(message, message.id);
    const result = first.status === "retryable"
      ? await this.secondary.send(message, message.id)
      : first;

    await this.ledger.record(message.id, result);
    return result;
  }
}

This is intentionally incomplete production code: concurrent dispatch, transaction boundaries, provider-specific guarantees, privacy, rate limits, and ledger failure all need design. Its purpose is to make the decision boundary visible. Provider adapters can change without changing the accepted-message contract. The idempotency key is stable across attempts. The ledger records an outcome independently of provider terminology.

The SEI practical ADD example similarly demonstrates choosing patterns for availability and fault tolerance from driving requirements. The lesson is not to copy its client-server structure. It is to make the path from scenario to tactic to allocated responsibility reviewable.

Evaluate combinations, not isolated choices

Architecture risk often lives between decisions. A secondary provider does not create resilience if both adapters share one failing DNS path. An event log does not create recoverability if retention is shorter than incident detection. Service boundaries do not create modifiability if all teams must coordinate a shared schema release.

The SEI’s Architecture Tradeoff Analysis Method evaluates an architecture against quality goals and identifies risks, non-risks, sensitivity points, and trade-off points. It then synthesises related risks into themes that threaten business drivers. This is more useful than maintaining a flat list where ten symptoms of the same ownership problem appear unrelated.

For the notification example, a stakeholder review might produce the following synthesis:

The numbers count hypothetical linked findings; they do not measure severity. The chart’s purpose is to reveal concentration. Five risks tied to shared ownership may justify one structural intervention, while five unrelated low-impact findings may not.

ATAM also resists single-attribute optimisation. Batching may improve provider cost but worsen time-to-delivery. A durable ledger may improve auditability while increasing privacy and retention obligations. Automatic failover may improve availability but amplify a malformed campaign. Architectural decisions are valuable precisely because they make these interactions explicit before incidents make them visible.

Put economics beside technical quality

Sometimes two alternatives satisfy the scenario and differ mainly in cost, schedule, uncertainty, or option value. The SEI Cost Benefit Analysis Method extends architecture analysis by associating architectural strategies with economic considerations. It does not calculate the answer for stakeholders; it structures the inquiry.

For a difficult-to-reverse choice, estimate more than implementation cost:

  • What is the migration and coexistence cost if the assumption fails?
  • Which future changes become cheaper, and which become more expensive?
  • How long before dependencies make reversal materially harder?
  • What evidence could change the decision, and what would that evidence cost?
  • Is a temporary adapter purchasing useful learning or merely hiding permanent coupling?

This is also a disciplined way to discuss technical debt. The SEI’s architectural technical debt collection describes short-term expedients that make later work more expensive. Debt is not synonymous with untidy code. It is the accumulated economic consequence of a decision. A deliberate compromise has an owner, expected benefit, observable interest, and repayment or acceptance condition. An invisible compromise simply constrains the future.

Scale governance with consequence

A decision-driven practice should make most work faster, not route every choice through an architecture board. Let teams make low-reversal decisions within clear boundaries. Escalate when a choice creates an external contract, changes durable data semantics, crosses an ownership or trust boundary, threatens a driving quality scenario, or requires coordinated migration.

A lightweight operating rhythm is enough:

  1. Keep a visible queue of unresolved architectural decisions, ordered by when they become expensive to defer.
  2. Run short scenario sessions with the people who own the outcome, build the system, operate it, secure it, and support its users.
  3. Record consequential decisions near the code and link them to tests, dashboards, migrations, and runbooks that supply evidence.
  4. Review decision triggers during delivery and incidents, not only at scheduled architecture meetings.
  5. Retire temporary mechanisms when their removal condition is met; otherwise they quietly become permanent architecture.

Architecture begins where reversal becomes expensive, but good architecture does not worship permanence. It identifies the few choices that can close important options, invests evidence in proportion to their consequence, and engineers reversibility around everything else.

The outcome is not a perfect target state. It is a system of decisions: quality goals made concrete, tactics selected deliberately, risks considered in combination, economics made visible, and assumptions repeatedly tested against reality. The architecture improves because the organisation becomes better at deciding what must endure, what should remain replaceable, and when new evidence is strong enough to change its mind.