In 21 years of reviewing infrastructure, I have noticed a quiet, pervasive truth.
The High-Level Design is a statement of intent. The Low-Level Design is a set of instructions. But the as-built environment? That is often an act of improvisation — and the document that claims to describe it is, in most organisations, a work of fiction.
We call it design drift. It is the gap between what the board signed off on and what is actually running in your data centre. And in most organisations, that gap is wider — and more dangerous — than anyone wants to admit.
The Ivory Tower vs. The Trenches
Design drift rarely starts with malice. It starts with a document.
An LLD is written by an architect — sometimes a good one — who has not been close to a rack or a CLI in years. The document is thorough, 200 pages long, through governance, board-approved. The senior engineer handed that document on day one makes a quiet assessment: parts of it are technically unworkable, others ignore the reality of the existing environment entirely.
The engineer faces a choice: follow a flawed map and fail, or ignore the map and make it work. And raising concerns is not always straightforward — not all architects respond well when engineers point out flaws in their designs.
The governance is done. The design has been approved. Questioning it can feel like a career risk rather than a professional obligation.
Most good engineers make it work. They implement clever, bespoke workarounds that solve the immediate problem — not being rogue, but being professional in the only way available to them. But those workarounds are never captured on paper. The LLD remains frozen at the point of approval — a historical document describing an environment that never quite existed.
The Hero Paradox
We have all seen it. The engineer who stays up until 3am during a failed migration to get the packets moving. They get the shout-out in the all-hands. The CTO sends a thank you email.
What nobody discusses is what that engineer actually did to get the packets moving.
They bypassed a security zone because the firewall policy was unworkable in the actual environment. They patched both uplinks into the same line card because the correct hardware had not arrived and the cutover could not slip. They disabled a redundancy mechanism — temporarily, then permanently, because Phase 2 never happened.
Because we reward the firefighter, we accidentally incentivise the behaviour that destroys our documentation. The engineer says they will document it in Phase 2. Leadership, relieved the crisis is over, believes them.
Phase 2 is a graveyard. Once the change control closes and the budget is spent, the team moves on. The temporary fix becomes permanent infrastructure. The undocumented workaround becomes the production design.
What This Costs
The as-built lie is not a documentation problem. It is an operational and financial risk sitting invisibly on your balance sheet.
When a major outage occurs against fiction documentation, the first two hours of incident response are not spent fixing the problem. They are spent on digital archaeology — engineers trying to determine what is actually there, because the document describes something different. Two hours of your most experienced people doing detective work, with the business down, at whatever your cost per hour of downtime happens to be.
Your HLD says you have path diversity. Your DR plan assumes it. In reality, an engineer patched both uplinks into the same line card at 3am because the correct hardware had not arrived. You are one hardware failure from a total outage. Nobody knows. The documentation says otherwise.
And every future programme designed against that fiction inherits its assumptions. The drift compounds with every programme that builds on it.
What Fixes It
A design assurance review in the as-built context is not about reading a PDF. It is about verification — closing the gap between what the document claims and what is actually configured. That means reviewing the LLD against the running configuration, not the approved HLD. It means talking to the engineers who built it. It means asking specifically what changed during the build and why.
Stop rewarding the firefighter if they are not also updating the fire map.
If the as-built environment does not reflect what is actually running, you are not looking at documentation. You are looking at fiction. And you are making business-critical decisions based on it.
- The as-built document was never updated after the cutover. The approved LLD remains the most recent version. Everything that happened during implementation — the workarounds, the hardware substitutions, the design deviations — exists only in the memory of the engineers who were there.
- Redundancy that exists on paper does not exist in the network. Path diversity, failover mechanisms and resilience designs signed off at board level were quietly bypassed during implementation and never reinstated.
- Security controls were relaxed during implementation and never restored. Temporary exceptions opened to resolve cutover issues became permanent configurations. The security posture the board believes exists is not the security posture that is running.
- Future programmes are being designed against the fiction. The next refresh, the next migration, the next audit is being planned against a documented environment that does not exist. The drift compounds with every programme that builds on it.