Pace-Layered Application Strategy
also called Pace Layering, PACE Layers
Sorting applications by how fast the business needs them to change - records slowly, differentiators quarterly, innovations weekly - and giving each layer its own governance funding and integration rules instead of one regime for the whole estate.
An organisation puts every application through one change process: a design review, a change advisory board, a quarterly release train. The general ledger is fine with it. The pricing experiment the commercial team wants this month is not, so that team buys a SaaS tool on a card, and 18 months later it holds customer data, has no owner and cannot be switched off.
Pace layering — the model Gartner published under that name — says the governance regime is a property of the application's required rate of change, not of the organisation. Three layers: systems of record (authoritative for a business entity, changing a few times a year), systems of differentiation (how this company competes, changing quarterly), systems of innovation (experiments, changing weekly and expected to be thrown away).
Why it matters
The layer is the most useful field in an application inventory, because it predicts the release cadence, the testing that is proportionate, who may change the system, and what integration is permitted.
It also explains why uniform governance fails in one direction or the other. A regime tuned for the ledger makes experiments impossible, so they happen outside the estate and arrive later as unsupported systems of record. A regime tuned for experiments applied to the ledger produces the reconciliation incident an audit finds. The arithmetic: a record system changing 4 to 6 times a year absorbs a two-week change process easily — under 25% of the year — while an innovation system releasing weekly has its whole calendar consumed by it.
Implementation patterns
- Classify by required rate of change, never by technology or vendor. A SaaS product can be a system of record and a mainframe batch job can be a differentiator. The question is what breaks if it changes on Friday.
- Set the integration rule at each layer boundary. Innovation and differentiation systems read from record systems through a published interface and never write to a record system's tables. That rule is what makes throwing an experiment away free.
- Fund the layers differently. Records get maintenance funding and a lifecycle plan; differentiators get product funding; innovations get time-boxed allocations with a kill date, which stops an experiment becoming a dependency.
- Re-classify on a trigger, not a calendar. When an innovation system acquires its first downstream consumer, or holds the only copy of something, it is a record system and needs that governance the same week.
Industry example
The pattern is most visible around packaged enterprise software in production. An ERP vendor in SAP's position ships a core whose upgrade cadence is set by the vendor's release train, and customers surround it with satellites they change far faster. The layering is a fact rather than a choice there: the core is a system of record because a customer's decade-old integrations must keep working across a major release, so anything needing monthly change lives outside it.
The recurring failure in those estates is customisation inside the record layer to deliver a differentiating behaviour. It works, and it converts every later vendor upgrade into a project, because the differentiator now carries the record layer's change cost.
Failure scenarios
- The promoted experiment. A system of innovation quietly becomes the only place a business fact lives; nothing re-governs it, so an application with no owner sits on a revenue path.
- Label warfare. Every team declares its system a differentiator because that layer has the best funding, and the model degrades into a naming argument unless classification has an evidence test.
- Differentiation written into the record layer, which is where multi-year upgrade programmes come from.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| One governance regime | Simple to explain and audit | Either experiments leave the estate or the ledger moves too fast |
| Three layers | Change cost proportionate to each system's job | A classification to maintain and defend against gaming |
When not to use it
In a single-product company with a dozen systems the layering is obvious to everyone. The model earns its keep past roughly 40 to 50 applications, or wherever one change process is visibly wrong for two parts of the estate. It is also the wrong instrument for deciding what to retire: a layer says how to govern a system, not whether it has value.
Interview question
Q: An experiment from two years ago now holds the only record of customer consent preferences, has no owner, and runs on a framework whose original team has left. What do you do, and what should have caught it earlier?
What a strong answer covers: recognising that the system's layer changed and its governance did not; the immediate moves (assign an owner, establish what is authoritative, move the data behind a published interface, stop new consumers); and the preventive trigger — first downstream consumer or first authoritative datum — rather than an annual review that would have missed it twice.
Quick check
Quiz: What decides which pace layer an application belongs to? The rate of change the business needs from it, not its technology. The test is what breaks if it changes on Friday.
Flashcard: Which layer boundary rule makes throwing an experiment away free? — Innovation and differentiation systems read records through published interfaces and never write to their tables, so deleting the experiment costs nothing downstream.