Skip to content
Software Architecture Guide

Architectural Force

Explanation

Section titled “Explanation”

An architectural force is a pressure that shapes a design decision. Forces often pull in different directions. The architect weighs them instead of simply obeying them.

The Big Ball of Mud pattern (see its article) names several forces that push a system toward a tangled structure:

  • Time. As a deadline nears, architectural concerns often give way to pragmatic ones.
  • Cost. Architecture is expensive, especially when the team explores a new domain.
  • Skill. Programmers differ in skill, expertise, predisposition, and temperament.
  • Visibility. Only the people who build a program see its inside. Poor structure can go unnoticed.
  • Complexity. Software often reflects the complexity of the problem area it serves.
  • Change. The world defeats attempts to predict future requirements. Shortcuts follow.

Patterns state forces in their problem descriptions. Keep It Working is one example. Maintenance needs have piled up, but a big overhaul might break the system. Two forces pull against each other, and the pattern helps you choose.

Forces differ from constraints. arc42 defines constraints as requirements that limit the architect’s design freedom. Constraints must always be handled, although they may be negotiable. Forces are weighed, not obeyed. arc42 also advises architects to know where they are free and where constraints bind them.

Decision records give forces a place to live. The MADR template (Markdown Architectural Decision Records) has a Decision Drivers section. Forces and concerns go there, so readers can see what pushed the decision.

Example

Section titled “Example”

A team must ship a booking tool before a trade fair. The deadline pushes toward quick shortcuts. The team is new to the travel domain, so careful design feels costly and risky. The team lists the deadline, the cost, and the unfamiliar domain as decision drivers in its decision record. Later readers can see why the team chose a simpler design and what it weighed.

Trade-offs

Section titled “Trade-offs”

Forces rarely agree. Giving in to one, such as a deadline, can feed another, such as muddy structure that no one notices because only the builders see inside. Writing the forces down does not remove the conflict. It makes the compromise visible and open to review.

Checks

Section titled “Checks”
  • The decision record lists the forces and concerns that drove each decision, for example in a Decision Drivers section.
  • The document separates constraints (which must be handled, though some are negotiable) from forces (which are weighed).
  • The document states where the architects are free and where they are bound by constraints.
  • Pattern or decision descriptions name the competing forces, such as maintenance needs versus risk of breaking the system.
Section titled “Related”

Sources

Section titled “Sources”