Skip to content
Architect's Handbook Wiki

Attribute-driven design (ADD)

Process · Chapter 5

What ADD is

Section titled “What ADD is”

A systematic, iterative, step-by-step method for architectural design. Its defining trait: it keeps quality attributes front and center, so you weigh them — and the trade-offs between them — early in the process. Widely used and proven across many applications.

Scope limit: ADD covers design only — not gathering drivers, documenting the architecture, or evaluating it once designed. Combine it with other methods to fill those gaps.

The eight steps

Section titled “The eight steps”
  1. Review inputs — Get clear on the overall problem by reviewing the architectural drivers (design objectives, primary functional requirements, quality attribute scenarios, constraints, concerns). For a brownfield system or any non-first iteration, the existing architecture is also an input.
  2. Set the iteration goal and pick relevant inputs — Steps 2–8 repeat per iteration (agile-style, since solving all drivers at once is too hard). Decide the design issue this iteration will solve, and identify the drivers tied to that goal.
  3. Choose element(s) to refine — Pick what to decompose. First iteration of a greenfield system: start at the top by decomposing the whole system. Otherwise: select from already-decomposed elements.
  4. Choose design concept(s) — Select the patterns, reference architectures, tactics, and/or externally developed software that meet the goal and satisfy the inputs.
  5. Instantiate elements, allocate responsibilities, define interfaces — Analyze the chosen concepts to detail the decomposed elements’ responsibilities and public interfaces. Each parent element yields child elements; distribute the parent’s responsibilities (architecturally significant or not) among them.
  6. Sketch views and record decisions — Sketch the designed solution and document every decision made this iteration, including the design rationale. These are informal sketches, not the formal views (which come later — see Creating architecture descriptions (ADs)).
  7. Analyze the current design against the goal — Architect and team check the decisions are correct and satisfy the iteration goal and drivers; this determines whether more iterations are needed.
  8. Iterate if necessary — If more work is needed, return to Step 2. Sometimes constraints (e.g. project management deciding there’s no time) end iterations. When none remain, the design is complete.
Section titled “Related concepts”

Citations

Section titled “Citations”
  • Software Architect’s Handbook (Packt, 2018), Ch.5 “Attribute-driven design (ADD)”, pp. 338-347.