Architecture Decision-Making
Use tradeoff thinking, quality attributes, decision records, timing, reversibility, and boundaries to structure design reviews.
- Depth
- Practical
- Steps
- 7 existing graph entries
- 1
Everything Is a Tradeoff
There are no universally correct choices in engineering, only tradeoffs that depend on context. Whatever structure, technology, or guarantee you gain costs something elsewhere, so the work is not to find the single best option but to make the tradeoff explicit and choose delib...
Begin with tradeoffs so the rest of the path is framed as decision work, not rule application.
Related within this path
- References: Architecture Characteristics
- 2
Architecture Characteristics
The system qualities an architecture must support beyond its domain functionality, the " ilities": performance, scalability, availability, security, deployability, testability, and so on. They are the success criteria of an architecture, separate from what the system does. An...
Name the qualities the architecture is expected to optimize or protect.
Related within this path
- References: Everything Is a Tradeoff
- Related To: Fitness Functions
- 3
Fitness Functions
An objective, usually automated, test that measures whether an architecture characteristic is being maintained as the system changes: performance budgets, dependency rules, security checks, coupling limits. Borrowed from evolutionary computing, a fitness function scores how cl...
Connect desired qualities to checks that can keep decisions honest over time.
Related within this path
- Related To: Architecture Characteristics
- 4
Architecture Decision Records
A short, durable document for each significant architecture decision that records its context, the decision made, the alternatives considered, and the consequences. ADRs are usually kept in version control alongside the code and are immutable: a superseded decision gets a new...
Capture the reasoning before context disappears.
- 5
Last Responsible Moment
Defer a decision until the moment past which delaying would cost more than deciding, no earlier and no later. The point is not to procrastinate but to make irreversible or expensive commitments only when you have the most information and the cost of waiting starts to bite. Dec...
Consider when delaying a decision preserves useful information.
Related within this path
- Related To: Reversibility
- 6
Reversibility
There are no final decisions. Because requirements, environments, and understanding all change, good design keeps important decisions reversible, so a choice that turns out wrong can be undone without rewriting everything. Avoid one way doors where a cheaper two way door exist...
Use reversibility to decide which choices need more ceremony.
Related within this path
- Related To: Last Responsible Moment
- 7
Modular Boundaries
Drawing the lines between parts of a system, in code and in the organization, so that each part hides its internals behind a simple interface and can be understood and changed on its own. The same principle governs a module's boundary and a team's boundary. Deep Modules — make...
Finish by applying decision pressure to the boundaries teams will live with.