Architectural decision¶

In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change.

Version: v1 · 2026-09-28 · History
Domain-specific #: 8006
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomain: Software Architecture → Computer Science & Software Engineering

Core Idea¶

Architectural decision is treated here as the recurring software architecture identity summarized by this source-grounded definition: In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change. In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change. Software architecture design is a wicked problem, therefore architectural decisions are difficult to get right.

How would you explain it like I'm…

Big Hard-to-Change Choices

When people build a big computer program, some choices are like choosing the foundation of a house: they shape everything else and are really hard to change later. Those big, important choices are called architectural decisions. People should think carefully and look at different options before making them.

Big, Hard-to-Change Choices

When a team builds software, most choices are small and easy to change. But some choices are big, like picking the main way the parts will talk to each other, or picking an important tool the whole program depends on. These are architectural decisions: choices that deal with the most important needs of the software and are hard to make or expensive to change later. Because they matter so much, good teams make sure they're ready first: they know who cares about the decision, the timing is right, they've listed the options, and they know what the choice needs to achieve. Then they write the decision down using a standard form.

Architecturally Significant Design Decisions

In software engineering, an architectural decision is a design decision that addresses an architecturally significant requirement, meaning a requirement that strongly shapes the system's structure, and that is considered hard to make or costly to change. Examples include choosing architectural patterns and tactics, integration technologies, middleware, and major implementation assets such as commercial products or open-source projects. Because software architecture is a 'wicked problem' with no clean right answer, these decisions are hard to get right, and studies have found teams often lack a structured way to make them. One suggested 'definition of ready' says a decision can be made once stakeholders are identified, the time is right, alternatives are listed, requirements and criteria are defined, and a template for recording it (an ADR, or architectural decision record) is chosen. Making these decisions is a core responsibility of software architects.

In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements and are perceived as hard to make, costly to change, or both. Their scope typically covers the selection of architectural tactics and patterns, integration technologies, and middleware, along with related implementation strategies and assets, including commercial products and open-source projects. Because software architecture design is a wicked problem, such decisions are difficult to get right, and practitioner studies have found that a structured approach to decision-making is largely lacking. A proposed definition of ready for making an identified decision requires that stakeholders are identified, the timing is right, alternatives are listed, requirements and other criteria are defined, and an architectural decision record (ADR) template has been chosen. Decision making of this kind is a core responsibility of software architects, and treating decisions as first-class concepts makes them visible, reviewable, and traceable. The defining test is the link to architecturally significant requirements combined with high cost or difficulty of change; ordinary local design choices do not qualify.

Scope of Application¶

Decision identification. Both personal and collective experience, as well as recognized design methods and practices, can assist with decision identification; it has been proposed that Agile software development team should maintain a decision.
History. In practice, the importance of making the correct decisions has always been recognized, for instance in software development processes such as OpenUP; many templates and practices for decision documentation exist.
Decision documentation. Nygard's architecture decision records ) and in software engineering and architecture design methods (e.g., see table layouts suggested by IBM UMF and by Tyree and Akerman from CapitalOne ).
Decision documentation. Architectural decisions are used in software design; hence they have to be communicated to, and accepted by, the stakeholders of the system that fund, develop, and operate it.
Decision documentation. Architecturally evident coding styles and code reviews that focus on architectural concerns and decisions are two related practices.

Clarity¶

A clear use of Architectural decision names the carrier, the operative relation, and the conditions under which the source treats the identity as present. The minimal definition is In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change.

Manages Complexity¶

Architectural decision compresses multiple software architecture details into a stable diagnostic relation. The source shows both the central mechanism—rationale was mentioned in an early definition of software architecture by Perry/Woolf, but not researched much until 2004, when a workshop on architectural decisions and Architectural Knowledge Management was held in Groningen, NL.—and the practical consequence—both practitioners and researchers recognize that software architecture decision-making is a group process.

Abstract Reasoning¶

Type the carrier. Identify the software architecture entities to which the claim applies.
State the relation. Use the source-grounded identity: In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change.
Check operation and conditions. In practice, the importance of making the correct decisions has always been recognized, for instance in software development processes such as OpenUP; many templates and practices for decision documentation exist. 4.

Knowledge Transfer¶

Within the home domain. Knowledge about Architectural decision transfers literally when a new case preserves the same carrier type, relation, and recognition test. Both personal and collective experience, as well as recognized design methods and practices, can assist with decision identification; it has been proposed that Agile software development team should maintain a decision backlog complementing the product backlog of the project. In practice, the importance of making the correct decisions has always been recognized, for.

Relationships to Other Abstractions¶

Current abstraction Architectural decision Domain-specific

Parents (2) — more general patterns this builds on

Architectural decision is a kind of Decision Prime

An architectural decision is a design decision distinguished by architectural significance and change cost.
Architectural decision presupposes Design Prime

The decision is made within the design of a software or system architecture.

Neighborhood in Abstraction Space¶

Architectural decision sits in a sparse region of the domain-specific corpus (70^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Design, Process & Business Methods (18 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08