Case study / Managed Services
One control baseline, ready before the freeze.
Landing-zone controls, observability, cost ownership and recovery practice were designed as one operating position rather than as four separate technical projects — so that teams released into a governed environment with service health and spend visible in the same conversation.
- One
- control baseline across every landing zone
- 6 weeks
- of readiness margin before the change freeze
- 94%
- of cloud spend attributed to an owning service
Situation
The context
Three delivery teams had each built their own cloud footprint against their own interpretation of the standards. Controls differed by account, observability was per-team, spend arrived as one monthly total nobody could attribute, and the trading peak was five months away with a change freeze six weeks before it.
Every team had done reasonable work. There was no position the organisation could state about any of it.
The first task was not consolidation. It was to establish a single control baseline that the existing footprints could be measured against, so that the gap was a list rather than an impression.
Intervention
The intervention
One baseline was defined and expressed as automated guardrails, observability and cost attribution were built against the same service definitions, and recovery was rehearsed rather than documented — with all four accepted together, because a baseline accepted in parts is not a baseline.
Landing zone
One baseline, expressed as automated guardrails
Observability
Service health defined once, across every footprint
Cost ownership
Spend attributed to the service that incurs it
Recovery
Rehearsed, not documented and assumed
Delivery path
The freeze date set the plan, not the other way round.
Working backwards from the freeze produced a different sequence to the one a greenfield design would have suggested: the things that could not be changed later went first, and the improvements that could wait were explicitly deferred to the new year.
Weeks 01–04
Baseline
Defined one control baseline and measured the three existing footprints against it, producing a gap list with an owner and a freeze-relevance rating per item.
Decision gateBaseline and gap list acceptedWeeks 05–11
Guardrails
Expressed the baseline as automated policy, applied it to new footprints immediately and to existing ones on an agreed remediation schedule.
Decision gateGuardrails live, exceptions documented and ownedWeeks 08–14
Visibility
Built observability and cost attribution against the same service definitions, so health and spend could be read together rather than reconciled between two teams.
Decision gateService health and spend reportable togetherWeeks 15–19
Rehearse
Ran recovery and scaling rehearsals under peak-shaped load, corrected what the rehearsals found, and closed the position before the freeze began.
Decision gatePeak readiness accepted ahead of the freeze
Operating shift
Four projects would have delivered four positions.
The engagement’s design decision was to accept the four workstreams as one thing. These are the practical shifts the case study is designed to make visible.
FromStandards per team
→ToOne enforced baseline
Guardrails made the standard the default path rather than a document teams were expected to have read.
FromMonitoring per footprint
→ToService health defined once
The same service definition drove alerting, reporting and the cost view, so the three could not disagree.
FromA monthly total
→ToSpend with an owner
Cost moved into the service conversation, which is the only place a decision about it can actually be made.
FromRecovery documented
→ToRecovery rehearsed
The rehearsals found what documents cannot, and they found it while there was still time to act on it.
Evidence record
A result with its provenance attached.
The published story keeps the result, the supporting artefact and its limit together.
- One
- control baseline across every landing zone
- 6 weeks
- of readiness margin before the change freeze
- 94%
- of cloud spend attributed to an owning service
Evidence attached
- Control baseline definition and per-footprint gap list
- Policy-as-code guardrail set with documented exceptions
- Service definitions shared by observability and cost attribution
- Recovery and scaling rehearsal records
Capabilities involved
- Cloud platform engineering
- Governed landing zones
- Policy-as-code and automation
- Observability engineering
- Cost and capacity management
- Recovery and continuity practice
- Nature of the work
- Automation only — policy-as-code guardrails and scheduled scaling. No AI model was used in control enforcement or in cos
- Baseline
- Three divergent control positions across existing footprints, no service-level attribution of cloud spend, and recovery procedures that had been written but not exercised.
- Data sources
- The client’s cloud provider billing and configuration data, its service-management platform’s service definitions, and the rehearsal records produced during the engagement.
- Human-control point
- The baseline and every documented exception to it were approved by the client’s cloud governance forum. Freeze readiness was signed off by the client’s trading technology lead.
- Technology used
- The client’s existing cloud tenancies and tooling. Guardrails and observability configuration were built during the engagement and are the client’s.
- Measured result
- One control baseline applied across every landing zone; 94% of cloud spend attributed to an owning service; peak readiness accepted six weeks before the change freeze.
- Evaluation period
- The nineteen-week delivery, plus the trading peak that followed it.
How to read these figures
Bring your context
Cloud spend arriving as one number nobody owns?
Tell us how many control positions you currently have, and when your freeze starts. We will start with your environment and be precise about which experience transfers.
- Response
- One working day, Monday to Friday