Loading content
Decision Rationale records the technical, organizational, and business reasons behind an architectural or design decision. It captures assumptions, evaluated alternatives and expected consequences, making choices traceable, aiding governance and supporting later reviews and change impact analysis across the system lifecycle.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What you need to understand to reason about a domain.
Decision Rationale documents the reasons, evaluated alternatives, and expected consequences of a decision so architecture and design choices remain understandable over time.
The practice emerged in software engineering and architecture from the need to record not only a decision's outcome but also its reasons, alternatives, and trade-offs. Early work such as Kunz and Rittel's IBIS made the argumentative structure explicit; later architecture description and decision-record practices carried that need into standards like ISO/IEC/IEEE 42010 and ADRs.
Think of Decision Rationale as a decision sheet with four parts: context and assumptions, options considered, evaluation criteria, and expected effects. The rationale records why one option was chosen and what trade-offs were accepted. A later review can then inspect not only the outcome, but the full argument chain and whether it still holds in a new context.
Context, choice, and reasoning are recorded so that later review remains possible.
Rationale supports structured evaluation, approval, and later reconsideration.
Explicit premises show what the decision depended on.
Compared options reveal what was intentionally rejected or preferred.
Benefits, costs, and risks are weighed against each other instead of in isolation.
Expected impacts help interpret later changes and side effects.
Decision rationale is useful for architecture decisions, major changes, reviews, audits, and knowledge transfer. It matters most when multiple teams, long lifecycles, or high change impact are involved. It does not replace sound decision-making; it makes the logic reviewable, and the effort is most worthwhile where reconstructing the reasoning later would be expensive.
Where this building block is located in the topic model.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.