Skip to content
Software Architecture Guide

Architectural Constraint

Explanation

Section titled “Explanation”

A constraint is any requirement that limits the freedom of architects in their design and implementation decisions. Each constraint removes some design options. The more constraints a system has, the fewer choices remain.

Constraints must be dealt with. Some constraints can be negotiated, but the team cannot ignore them. A negotiable constraint still needs a conscious answer.

Common kinds. arc42 (a template for documenting architecture, see “arc42 Architecture Documentation Template”) suggests three groups when a split helps:

  • technical constraints
  • organizational and political constraints
  • conventions

Non-functional requirements as constraints. One view is to treat non-functional requirements (qualities such as speed or security, see “Quality Attribute”) as constraints placed on the system. Seen this way, each quality target narrows the design choices a bit.

Document them. Written constraints tell architects where they are free and where they must comply. This avoids surprises late in the work.

Record who and why. Note who wants a constraint and the reason behind it. Without that, the team may later forget why the limit exists.

State the consequences. Constraints can bring extra cost or effort. arc42 advises clarifying these consequences, so stakeholders (people with an interest in the system) see what a constraint costs.

Where they live. arc42 has a section for architecture constraints (see “arc42 Constraints”). Decision templates such as MADR list constraints next to qualities, forces and concerns as decision drivers (see “Markdown Architectural Decision Records”).

Example

Section titled “Example”

A team plans an online shop. The company already runs on one cloud provider and requires all services to use it. That is a technical constraint. The team records it, along with who requires it and why. They also note a consequence: some specialized tools from other vendors are off the table, which may mean extra effort. Architects now know the hosting choice is fixed, and they can spend their design freedom elsewhere.

Trade-offs

Section titled “Trade-offs”

Every constraint narrows the design choices, so a heavily constrained system leaves little room for the best technical solution. Constraints can also cost money or effort. Negotiating a constraint may remove that cost, but the facts only say that some constraints can be negotiated, not which ones. Documenting constraints and their reasons takes effort too. Skipping it risks losing the rationale later.

Checks

Section titled “Checks”
  • The document lists its constraints in one place, so architects can see where they are free and where they must comply.
  • Each constraint states who wants it and why.
  • The consequences of each constraint, such as extra cost or effort, are described.
  • Constraints are grouped, for example into technical, organizational/political, and conventions.
Section titled “Related”

Sources

Section titled “Sources”