Architecture as Decisions

Software architecture is not the diagram. ISO/IEC/IEEE 42010 frames architecture around fundamental concepts, relationships, principles, and their environment; the practical consequence is that architecture lives in decisions, constraints, and stakeholder concerns. A senior architect is therefore a decision steward: discovering forces, making tradeoffs explicit, creating shared vocabulary, and preserving optionality where the future is uncertain.

The most common architecture failure is not picking the wrong technology. It is allowing important choices to remain implicit until they are too expensive to challenge. A team “just” adds a synchronous call, “just” shares a database table, “just” routes all traffic through one service, or “just” accepts a vendor default. Months later, performance, ownership, deployability, and compliance are shaped by those small choices. Architecture work turns these choices into visible design material that can be reviewed against stakeholder concerns.

left to right direction
rectangle "Business Goal" as Goal
rectangle "Architectural Decision" as Decision
rectangle "System Constraint" as Constraint
rectangle "Team Behavior" as Behavior
rectangle "Runtime Outcome" as Outcome
rectangle "Feedback Signal" as Feedback

Goal --> Decision : creates pressure for
Decision --> Constraint : establishes
Constraint --> Behavior : guides
Behavior --> Outcome : produces
Outcome --> Feedback : emits
Feedback --> Decision : refines future choices

Decisions Have Scope

Architectural decisions differ from implementation details because they affect multiple future choices. Choosing a database is not automatically architecture; choosing a consistency model that shapes product behavior, integration style, operational recovery, and team ownership is. Choosing a web framework may be local; choosing server-side rendering because search, accessibility, and content governance dominate the product strategy may be architectural.

The useful question is not “is this architecture?” but “what becomes harder or easier because of this choice?” If a choice changes deployability, testability, data ownership, security boundaries, cost behavior, or team topology, treat it as architecture. The decision deserves a rationale, expected consequences, and a way to revisit it.

left to right direction
rectangle "Local Choice" as Local
rectangle "Architectural Choice" as Arch
rectangle "Single Module" as Module
rectangle "Multiple Teams" as Teams
rectangle "Runtime Qualities" as Qualities
rectangle "Operating Model" as Ops

Local --> Module : mostly affects
Arch --> Teams : coordinates
Arch --> Qualities : constrains
Arch --> Ops : shapes
Teams --> Qualities : delivery behavior changes runtime behavior
Ops --> Qualities : incident and cost patterns expose design

The Decision Record

An architecture decision record is valuable because it preserves the thinking, not because it creates documentation. The minimum useful record contains: context, decision, alternatives considered, consequences, and review trigger. The review trigger is often omitted, yet it is the piece that keeps the record alive. A decision without a review trigger quietly becomes doctrine.

A good decision record should be short enough to read during a design review and precise enough to prevent repeated arguments. “Use Kafka” is weak. “Use Kafka as the durable event backbone for fulfillment events because downstream consumers need replay, independent delivery, and delayed adoption; review if end-to-end latency must drop below 200 ms or if consumer count remains below three for two quarters” is stronger because it records context, decision, consequences, and the conditions under which the decision should be challenged.

rectangle "ADR: Async Fulfillment Events" as ADR {
rectangle "Context\nOrder placement must not wait for warehouse, invoicing, and analytics." as Context
rectangle "Decision\nPublish immutable fulfillment events to a durable log." as Decision
rectangle "Alternatives\nDirect calls, shared database, nightly export." as Alternatives
rectangle "Consequences\nReplay and loose coupling; schema governance and eventual consistency." as Consequences
rectangle "Review Trigger\nRevisit if latency target or consumer count assumptions change." as Trigger
}
Context --> Decision
Alternatives --> Decision
Decision --> Consequences
Consequences --> Trigger

Tradeoffs, Not Truths

Senior architecture work replaces abstract best practices with explicit tradeoffs. “Microservices are scalable” is too vague to be useful. A distributed design may scale team autonomy and independent deploys while reducing local reasoning, increasing operational load, and making data consistency a product concern. A modular monolith may simplify debugging and transactions while requiring strong internal boundaries and disciplined ownership.

Every serious decision has a bill. The question is whether the bill is paid in a currency the organization can afford. A team with strong operations and weak domain clarity should not copy the same architecture as a team with mature product boundaries and weak release engineering. Architecture is local to the context, even when patterns have general names.

left to right direction
rectangle "Decision" as D
rectangle "Benefits" as B
rectangle "Costs" as C
rectangle "Risks" as R
rectangle "Mitigations" as M
rectangle "Fitness Checks" as F

D --> B : buys
D --> C : pays
D --> R : exposes
R --> M : reduced by
M --> F : verified by
F --> D : keeps honest

Feedback Loops

Architecture should be evaluated through feedback, not ceremony. The best feedback comes from running software: deployment frequency, lead time, incident patterns, user latency, queue depth, schema-change friction, recovery time, cost per transaction, escaped defects, and the time required for a new engineer to make a safe change. These signals reveal whether the architecture is serving the system or becoming a museum.

Reviews are still useful, but only when they connect design intent to observable behavior. A review that asks “does this match our reference diagram?” is weaker than one that asks “what quality attribute is this decision protecting, how will we know if it fails, and what option remains if our assumption is wrong?”

Practice

Take a system you know and identify five decisions that are currently implicit. For each, write one sentence for context, one sentence for the decision, one sentence for the consequence, and one sentence for the review trigger. Then mark which decisions are reversible, which are expensive but manageable, and which would require product or organizational redesign to change.

References & Further Reading

• ISO/IEC/IEEE 42010: Architecture Description (standard copyright)
• SEI: Architecture Tradeoff Analysis Method Collection (Carnegie Mellon University/SEI, standard copyright)
• Michael Nygard: Documenting Architecture Decisions (standard copyright)
• Software Architecture in Practice by Len Bass, Paul Clements, and Rick Kazman (Addison-Wesley, standard copyright)