Architecture churn

What it means

Architecture churn measures changes to modules, services, dependencies, interfaces, or deployment boundaries. It can reveal active modernization, unstable decisions, or repeated reversals. The useful unit is a defined architecture event, not every line edit, and the time window must be consistent.

Example

A team moves a capability between three services in four quarters and repeatedly changes ownership. The churn prompts a review of the original boundary and the operational constraints driving the moves.

Limitations

High churn can be healthy during a deliberate migration, while low churn can reflect stagnation or lack of visibility. Count meaningful structural changes and annotate planned transitions.

How to use the signal

Review each structural change with its intended outcome and migration stage before drawing conclusions from the trend.

Annotate planned migrations and reversals so structural activity is not mistaken for accidental instability.

Weave can connect architecture churn with review duration, blocked time, and delivery reliability. Keep the event taxonomy explicit so a dashboard does not confuse normal refactoring with redesign.