# Architectural Thinking

**In short:** Architectural thinking is a repeated cycle of designing, checking and refining. It starts from requirements, quality goals and constraints, and ends in a documented architecture whose risks and trade-offs are understood.

## 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

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

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.

```mermaid
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

- 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.

## Related

- [Quality Attribute Trade-off](https://arc.fuet.ch/concepts/quality-attributes/architectural-trade-off-thinking.md)
- [Architectural Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern.md)
- [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md)
- [Software Architecture Evaluation](https://arc.fuet.ch/concepts/evaluation/software-architecture-evaluation.md)
- [Iterative and Incremental Development](https://arc.fuet.ch/concepts/fundamentals/iterative-and-incremental-development.md)
- [Architecture View](https://arc.fuet.ch/concepts/documentation/architecture-view.md)
- [Quality Attribute](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute.md)
- [Architectural Constraint](https://arc.fuet.ch/concepts/forces-decisions/requirements-versus-constraints.md)

## Sources

- [Attribute-Driven Design Method Collection | CMU Software Engineering Institute](https://www.sei.cmu.edu/library/attribute-driven-design-method-collection/) — sei.cmu.edu, accessed 2026-11-09
- [Curriculum forCertified Professional forSoftware Architecture (CPSA)®: Foundation Level](https://public.isaqb.org/curriculum-foundation/curriculum-foundation-en.html) — public.isaqb.org, accessed 2026-11-09