Architectural Drift: How Point Solutions Quietly Undermine the Original Design
Every tactical fix and vendor add-on leaves a mark. Over a 15-year estate life, those marks can erode the architecture a utility thought it had.
No AMI architecture stays the shape it was designed in. Across fifteen years, dozens of tactical fixes, vendor add-ons and point-to-point integrations accumulate — each one individually reasonable, each one solving a real problem quickly. The sum of those decisions is a different architecture from the one anybody actually approved.
Drift rarely announces itself. It shows up as a growing list of exceptions, a data flow nobody can fully diagram anymore, and a support team that keeps discovering systems doing each other's jobs slightly differently. By the time it's visible enough to name, it's usually expensive enough to matter.
This briefing sets out how drift accumulates, and what it takes to keep the architecture the one the utility actually designed.
Year zero vs year ten
The same core chain — network, HES, integration, MDMS, enterprise systems — looks very different after a decade of tactical additions.
Figure 1. None of these additions were unreasonable on their own. Together, they've replaced a designed architecture with an accumulated one.
Six signs of drift worth naming
Point-to-point integrations replacing the central layer
Each new connection bypasses the integration architecture because it's faster than doing it properly.
Duplicate functionality across systems
The same capability exists in two or three places, each slightly different.
Undocumented data flows
Nobody has a current map of what talks to what — only the map from when the architecture was first designed.
Shadow systems maintained by individual teams
A spreadsheet or small tool fills a gap the core architecture should have covered.
Governance exceptions becoming the norm
"Just this once" integrations accumulate until the exception is more common than the rule.
No owner accountable for the whole
Individual system owners optimise locally; nobody is responsible for the shape of the whole estate.
Keeping the architecture the one you designed
Maintain a living architecture diagram
Reviewed on a fixed cycle, not just at initial design.
Route every new integration through governance
Including the ones that feel too small to matter.
Audit for duplicate functionality periodically
And consolidate deliberately.
Name an accountable architecture owner
Whose job is the shape of the whole estate, not one system within it.
Budget time to retire point solutions
Not just to add new ones.
Architectural drift is never one bad decision — it's hundreds of reasonable ones, made without anyone responsible for the pattern they add up to. The fix isn't refusing tactical solutions; it's making sure someone is still watching the shape of the whole thing while they happen.
How a read moves across the estate
HOVER OR TAP A STAGE TO EXPAND TECHNICAL SPECS
Chris Gales
Chris Gales leads CEHG. He converts complex technical and commercial choices into clear decisions and dependable outcomes for utilities running connected device estates at scale.
He writes these field notes from the practice — on bearer migration, smart metering architecture, procurement and operations — to help estates start counting down early.