Pace Layering

Layers of a system change at different speeds. Let fast layers move without disturbing slow ones.

Layers change at different speeds; keep them separate so the fast ones can move without disturbing the slow ones.

To an executive

Different parts of the business change at different speeds. Letting fast-moving parts evolve without disturbing the slow, stable core lets you adapt quickly without putting essentials at risk.

To an engineer

Separate slow-changing core records from faster business rules and user interfaces. Put stable boundaries between layers so fast ones can change without forcing change below.

The idea

In How Buildings Learn (1994), Stewart Brand, building on an observation by the architect Frank Duffy, described a building as a set of layers that change at very different rates: site, structure, skin, services, space plan and stuff. The site lasts for ever; the furniture moves weekly. Buildings that adapt well let the fast layers change without tearing down the slow ones.

Brand later applied the same idea to civilisation, from fast to slow: fashion, commerce, infrastructure, governance, culture and nature. His 2018 essay in MIT's Journal of Design and Science sums it up: "Fast learns, slow remembers."

Enterprise systems have layers too. Core records change slowly, business rules at a moderate pace and user experience rapidly.

Why it works

Fast layers learn, slow layers stabilise. The fast layers try things and absorb shocks; the slow layers hold what has proven to work. Both jobs are needed.

Coupling across layers forces the wrong pace. When a fast layer is tied directly to a slow one, either the fast layer is slowed to the slow one's pace or the slow one is put at risk by constant change.

Different layers deserve different governance. Tight control suits a system of record; it stifles an experiment. Knowing the layer tells you which kind of control fits.

Where it applies

Enterprise application landscapes, separating systems of record from systems of differentiation and innovation.
API and integration design, where a stable contract shields a slow core from fast-moving consumers.
Governance, setting stricter standards for slow layers and lighter ones for fast layers.
Data architecture, where master data, reference data and analytics change at different speeds.

How to apply

Name the layers of your system and estimate how often each one really changes.
Find the coupling where a fast layer touches a slow one directly, such as a user interface reading core tables.
Put a stable interface between them: an API, an event stream or an anti-corruption layer, owned by the slower side.
Govern each layer at its own pace: careful change control for the slow layers, freedom to experiment for the fast ones.

Example scenario

A bank built its mobile app directly against core banking tables. Every user-interface change needed a review by the core team, because a bad query could slow the ledger. The app shipped a few times a year, and the core team spent much of its time on app requests.

The architect introduced an API layer owned by the core team, exposing accounts and payments through stable, versioned contracts. The app team could then release weekly against the API, while the core system kept its twice-yearly change windows. Each layer now moved at its own pace.

Questions to ask

What is the natural rate of change for each layer of this system?
Where are fast-changing parts coupled directly to slow-changing ones?
Where do we govern tightly, and where do we let teams experiment freely?

When not to use it

Small systems with one team, where all parts change together and extra layers add only overhead.
Early products whose core is still being discovered; freezing a "slow" layer too soon locks in guesses.

How it misleads you

Layering too rigidly can stop necessary change in the slow layers. Slow does not mean never: a core system that cannot change at all becomes a constraint on the whole organisation. It is also easy to misjudge a layer's real pace, so check how often each part actually changes rather than how often people think it should.