Operation
In a mature estate, change causes more incidents than component failure. That is why operation is a layer with a boundary rather than an activity that happens to the other three.
- Configuration held and maintained by us
- A rollback position before every change
- Reviews that compare capacity against measured use
What this layer does
It holds the configuration of the other three layers, executes change against them under control, monitors them continuously, and reviews them on a cadence.
Treating it as a layer rather than as a service is not a presentational choice. It is a recognition that in an estate which has been running for a while, the thing most likely to cause an outage is somebody changing something — and that risk deserves the same boundary, protection and evidence as the technical layers.
The boundary is written down before the layer is fitted: what we hold, what you retain, how change is requested, what response each side can expect, and where your own approval gates sit within the process.
The layers within
Four sub-boundaries, each producing its own record.
Request
Turning an outcome into a changeAsked for in business language through an agreed channel. Ambiguity is queried rather than guessed at, which is slower once and faster permanently.
Review
Deciding whether and when a change is safeChange classes with defined review depth. Emergency changes take a shortened path and produce an identical record.
Application
Making the change without widening the blast radiusIn a defined window, with a rollback position established beforehand rather than derived afterwards. Anything altering routing for a whole site is scheduled.
Verification
Establishing that it did what was intendedChecked after application and recorded with before and after state, so the next change begins from an accurate picture.
- A change applied without a record, leaving the next change starting from a wrong picture
- Documentation drifting until it describes an estate that no longer exists
- Knowledge held by one person who then leaves the organisation
- A fraud threshold set once and never revisited as the business changed shape
- Capacity provisioned years ago and never compared against measured use
- A rollback improvised during an incident rather than planned before it
What this layer protects against
Almost everything here is a failure of process rather than of technology, which is what makes it tractable.
How it is fitted
The same sequence whether the estate is one we built or one we inherited.
-
Measure
Every call flow, group, number, endpoint and integration mapped. On an inherited estate this is the largest phase and the most valuable.
-
Specify
The boundary agreed in writing: responsibilities, request channels, approval gates and response expectations.
-
Prove
Known faults, security gaps and configuration drift corrected before steady-state operation begins.
-
Fit
Routine change, monitoring and incident handling running continuously against the agreed boundary.
-
Hold
Scheduled reviews of capacity, quality, spend and change history, with recommendations in both directions.
What this layer produces
Change record
Requester, reviewer, window, before state, after state and verification result, for every change class.
Access record
Individual named accounts, every action attributed, reviewed periodically with unused permissions withdrawn.
Living documentation
Routing plans, numbering inventory and failover behaviour, updated as part of each change and owned by you.
Review record
Capacity against measured concurrency, quality trends and spend, with what we recommended and why.
Written down before the layer is fitted. Typically configuration, user provisioning, call flows, monitoring and vendor escalation. You retain policy: recording retention, who may request change, and approval of anything affecting cost.
Because in a mature estate change causes more incidents than failure does, and treating it as an activity rather than as a bounded layer is how those incidents happen.
Usually. It begins with mapping it, because we will not accept responsibility for a configuration nobody has documented. That exercise reliably finds services nobody realised were still running and still being billed.
No. Documentation is yours, reviews report what changed and why, and read access to reporting is available to your team.
You receive current documentation, configuration and numbering inventory. Nothing is built to make that difficult.