Fracture Planes

Categories
Architecture
Sources
Team Topologies

Natural seams along which a system can be split into parts owned by independent teams. Good fracture planes follow real boundaries such as business domain, regulatory scope, rate of change, risk, or performance isolation.

Why it Matters

Where you split a system determines coupling, ownership, and flow. Splitting along a genuine fracture plane yields loosely coupled parts a single team can own; splitting along an arbitrary line creates constant cross-team coordination.

Signals

  • Good planes: a change stays within one part and one team; parts have distinct domains or change cadences.
  • Bad planes: every feature touches several parts, and teams must coordinate for routine changes, a sign you split across a fracture plane rather than along it.

Benefits

Loosely coupled subsystems, clear single-team ownership, and faster independent flow of change.

Risks

Splitting along technical layers or org convenience rather than domain. Over-splitting into many parts, each adding a boundary and more cognitive load.

Tensions

The most natural domain boundary may not match the current team structure (see Conway's Law), so choosing it may require reshaping teams. More, smaller parts improve isolation but add interfaces to manage.

Examples

Splitting a system by business domain so each capability is independently ownable. Splitting by rate of change so a fast-moving part is not coupled to a slow, stable one.