Skip to content
Software Architecture Guide

Agile Architecture

Explanation

Section titled “Explanation”

Agile teams build in small steps. Architecture work has to fit that pace. Two extremes are best avoided: designing everything up front, and not designing at all.

Why no design fails. Evolutionary design means letting the design emerge as code grows. Fowler argues it fails without design effort. The design turns into a pile of ad-hoc, short-term decisions. He names a lack of will to design as a major cause of failure. He also links decaying design to a shrinking ability to change software effectively. That is close to the later idea of technical debt (see Technical Debt). Fairbanks says skipping design is impractical when the risk of failure is high.

Why full upfront design is not the answer. Fowler supports a broad starting-point architecture, not a complete one. SAFe cites Coplien: design will partly emerge, yet a little planning avoids much waste.

Just enough, driven by risk. Fairbanks’ risk-driven model ties architecture effort to the risk of failure. You do three things:

  • Prioritize the risks.
  • Apply techniques that reduce them.
  • Check the outcome.

You design only the riskiest parts. This often takes hours or days, not months. The model works with waterfall or agile processes.

Tailor the models. A model here is an architectural viewpoint (see Architecture Viewpoint). Decide in advance which questions it must answer. If throughput is the main worry, build a throughput model.

Runway and intentional architecture. SAFe asks agile architects to keep just enough architectural runway in place for evolving business needs. The architects’ set of intentions is called the intentional architecture. The runway is not a one-time exercise. It is updated as the product changes, so architecture work stays a continuous cycle.

Example

Section titled “Example”

A team starts a new online shop. In a short session they list their biggest risks. One risk is that checkout may be too slow during sales. They build a small throughput model, which answers one question: can checkout handle the expected load? They skip detailed design for low-risk parts, such as the help pages. As the product grows, they revisit the risk list and update their architectural intentions.

Trade-offs

Section titled “Trade-offs”

Doing just enough architecture saves time and avoids waste. But it needs discipline. If the team lacks the will to design, the design can degrade into ad-hoc decisions. If the team misjudges the risks, it may skip design that mattered. Keeping the runway and the risk list current also takes continuing effort.

A risk-driven cycle of just enough architecture

Diagram source 
flowchart LR
  A[Prioritize risks] --> B[Apply techniques that reduce them]
  B --> C[Check the outcome]
  C --> D[Build and update the runway]
  D --> A

Checks

Section titled “Checks”
  • The document names the main project risks and ties architecture effort to them.
  • Models or viewpoints are chosen to answer stated questions, such as a throughput model for a throughput concern.
  • The document shows some deliberate design effort rather than only ad-hoc tactical decisions.
  • The architectural runway or intentions are kept current as the product changes.
  • The design describes a broad starting-point architecture, not a complete upfront design.
Section titled “Related”

Sources

Section titled “Sources”