Skip to content
Software Architecture Guide

Architectural Thinking

Explanation

Section titled “Explanation”

Architectural thinking is how architects move from what a system must do to a design that can be built. It works in cycles, not in one pass.

Inputs. A well-known design method, Attribute-Driven Design (ADD), names three inputs: functional requirements (what the system does), quality attribute requirements (how well it must do it) and constraints (limits that are fixed). See the articles on Quality Attribute and Architectural Constraint.

Resolving conflicts. Goals often pull in different directions. Architects cannot settle this alone. They involve the relevant stakeholders, meaning the people with an interest in the system. ADD also brings quality trade-offs to light early in design.

Applying known solutions. Patterns are one way to reach certain qualities for a problem in a given context. The context matters, because a pattern that fits one situation may not fit another. See Architectural Pattern.

Documenting. Architects record decisions, for example in Architecture Decision Records (ADRs). The result of ADD is an architecture broken into parts and described with architectural views.

Evaluating. Architects check the design mainly for risks to meeting the requirements. They also name the trade-offs they made and the risks those trade-offs carry.

Iterating. ADD is recursive. It repeats its steps for successive parts of the system, so each round goes deeper. Iterations are needed, especially when decisions must be made under uncertainty.

Example

Section titled “Example”

A team designs an online booking system. Fast response and strict data privacy are both required, and they conflict. The architect meets the stakeholders and agrees on priorities. The team picks a structure, writes down the decision and its reasons, and checks the draft against the requirements. The check shows a risk in one part. The team then repeats the steps for that part in more detail.

Trade-offs

Section titled “Trade-offs”

Iterating takes effort, but it is needed when decisions rest on uncertain information. Early trade-off analysis surfaces conflicts sooner. Resolving them requires stakeholder time. Every pattern choice depends on context, so no pattern is a guaranteed fit.

A design cycle: design, document, evaluate, then repeat.

Diagram source 
flowchart LR
  A[Requirements, qualities, constraints] --> B[Design a part]
  B --> C[Document decisions and views]
  C --> D[Evaluate risks and trade-offs]
  D -->|refine or drill deeper| B
  D --> E[Viable architecture]

Checks

Section titled “Checks”
  • The document lists the functional requirements, quality requirements and constraints that the design started from.
  • Conflicting goals are recorded together with how the relevant stakeholders resolved them.
  • Key decisions are documented, for example as ADRs.
  • The architecture is described with views and broken down into parts.
  • The document names risks to meeting the requirements, and the trade-offs behind them.
Section titled “Related”

Sources

Section titled “Sources”