Ask a utility how long a substation asset should last, and the answer will be measured in decades. Ask the same organisation how long the software managing it should last, and you often get a blank look. Nobody has been asked to think about it that way.
The procurement framework treats the software as a project with a go-live date. The planning horizon quietly becomes the end of the current supplier’s contract. That is the wrong frame. Once you correct it, almost every technical decision changes.
The right question is whether someone can maintain it in 2046
When we recommend technology for this sector, we do not start with performance, developer productivity, or how pleasant something is to work with. The better question is simpler and more useful: in 2046, will a competent engineer who has never met us be able to pick this up, understand it, and change it safely.
That question rules out a surprising amount of technology.
- Anything whose community is one company.
- Anything currently fashionable but only three years old.
- Anything requiring a specialist you can only find in two cities.
- Anything with a licence that could change under new ownership.
- Anything where the interesting logic lives in a vendor’s proprietary configuration rather than in code you hold.
It also rules in choices that feel unexciting. Boring, widely deployed, well documented technology with a long support history and a large hiring pool can be the ambitious choice. The ambition is being applied to the right variable.
Conservative technology has a cost, but change costs more
There is a real cost to this, and it should be stated honestly. Choosing conservative technology means giving up genuine productivity gains available in newer tools. A team using something modern may well deliver the first version faster.
The trade is that the first version is a small fraction of the total cost. Over twenty years, the dominant cost is change. The changes come from regulatory changes, market reform, new metering, new tariffs, an acquisition, or a system that has to be integrated because somebody bought a company.
Each of those events becomes a change to software that somebody has to make. The cost of making it depends entirely on whether they can understand what is there and hire people who know the tools.
A stack that saved six weeks in 2026 and costs an extra fortnight on every change for two decades is a bad trade. It is also a trade almost nobody prices at the time.
Documentation has to prove someone else can run the system
On these engagements, we contract documentation as a deliverable with acceptance criteria. The criterion is behavioural: a competent engineer who has never spoken to us can deploy, operate and modify the system using only what is written.
We test that, and the test is uncomfortable. We hand the documentation to somebody who was not on the project. Then we ask them to perform a deployment and a common change.
Whatever they get stuck on is a defect in the documentation, and it goes in the backlog like any other defect. That exercise surfaces a remarkable amount of tacit knowledge, meaning knowledge people have in their heads but never wrote down. Very little of it was recognised as tacit until the test exposed it.
Every regulatory number needs a path back to the meter
Regulatory submissions in this sector are assertions about the physical world. A regulator is entitled to ask how a particular figure was arrived at. That means every number in a submission has to be traceable back through aggregation, validation and estimation to the raw reading it came from, along with the identity of the meter and the time it was taken.
Systems that compute submissions from a warehouse without preserving that chain can produce the number, but they cannot defend it. When a query arrives eighteen months later, the answer involves a person reconstructing a calculation from memory and hoping.
We build the chain explicitly. Every derived value carries references to its inputs and the version of the rule applied. That makes the lineage, the path from a final number back to the readings behind it, a query rather than an investigation.
The rule version matters more than people expect. Estimation methodologies change. If you cannot say which version was in force when a figure was produced, you cannot reproduce it. Reproducibility is the entire basis of the audit.
Security starts with the physical consequence
Threat modelling here starts from what a failure would mean physically, then works backwards to the controls that make that outcome unreachable. Threat modelling is the exercise of asking what could go wrong and designing controls around those risks.
The practical result is usually stronger and simpler than a generic security posture. If the consequence of compromise is a physical event, defence in depth around a system that could in principle cause it leaves the path present. The acceptable answer is an architecture where the path does not exist.
That means separated networks, one way boundaries for telemetry, and control actions that are structurally unable to originate from anything reachable from a business network.
This is the same argument that governs our phasing on plant floors, and it is more acute here because the blast radius is measured in customers rather than in production lines.
Long-lived data needs formats that outlive the supplier
A system that runs for two decades accumulates data that must remain readable for the whole period and often longer for regulatory retention. That is a constraint on storage format as well as storage volume.
Proprietary binary formats are a liability here. So are databases whose export path is only fully functional under a current support contract. We favour formats that are open, documented and readable by ordinary tools, even where a proprietary alternative is more efficient.
Efficiency is worth very little if the data cannot be opened by whoever inherits it.
The same applies to time. Twenty years of timestamps will cross timezone rule changes, daylight saving policy amendments and at least one leap second controversy. Storing local time without an offset is a decision that will cost somebody a fortnight in 2039.
Environments must be rebuildable after people leave
The single most common failure we inherit in this sector is a system that works and cannot be rebuilt. It was configured by hand, by somebody who has retired, on servers that have been patched by successive administrators. Nobody knows which of the settings are load-bearing.
The remedy is infrastructure as code, where every environment is defined in version-controlled code and rebuilt from that definition regularly enough to prove it still works. Documenting the rebuild is insufficient. The environment has to be rebuilt.
A rebuild that has not been executed in a year is a hypothesis. In an emergency, it will turn out to be a wrong one.
The exit terms belong in the contract
We write the exit into the contract rather than leaving it to good intentions. The source belongs to the client with its history intact. The infrastructure definition comes with it. There is no minimum term on retained work, and the notice period is thirty days.
Clients occasionally treat this as a negotiating gift. It is closer to self-interest. A supplier who can only be replaced at great cost has an incentive structure we would rather not have. A client who stays because leaving is expensive is not a reference.
Good handover shows up as fewer support calls
The metric we care about after go-live is support calls per week, trending to zero. We still want to hear from clients. But a support call is evidence that something was not documented well enough or was not obvious enough in the first place.
On the last handover of this kind, calls went from eleven in the first week to none by week thirteen. The client’s own team ran the system for the following two years without us.
That is the outcome the sector should be buying. It is achievable, but only if it is specified at the start rather than hoped for at the end.
Dependencies also become long-term liabilities
Choosing a conservative language and database is the easy half. The harder half is the several hundred libraries that arrive with any modern application. Each one is maintained by somebody with no obligation to you. Some are maintained by a single volunteer. Each one can be abandoned, relicensed or compromised.
Over a two year project, that risk is theoretical. Over twenty years, it is a certainty. Some meaningful fraction of what you depend on today will be unmaintained by 2036.
The mitigation is to be deliberate about the weight of dependencies. Avoiding dependencies is impractical, but treating all dependencies as equal is also wrong. A library that saves a hundred lines is rarely worth an external dependency. A library that implements a cryptographic primitive or a protocol absolutely is, and should be chosen for its governance rather than its ergonomics.
We keep an explicit inventory with a note against each entry. The note says what it does, what we would do if it disappeared, and whether the answer is trivial or a project. Reviewing that list annually is an hour of work. It is how you avoid discovering, during an incident, that a load-bearing component has had no commits since 2031.
Future integrations are guaranteed, even if the details are unknown
A twenty year horizon guarantees integrations nobody can currently specify. Market reform will introduce a new settlement process. A regulator will require a new submission. The organisation will acquire another with an incompatible estate. Metering will change generation.
None of these are predictable in detail, and all of them are predictable in kind.
That argues for clean boundaries and honest interfaces, rather than extensibility in the abstract sense. Abstract extensibility usually produces an over-engineered plugin architecture nobody uses.
The better shape is a system whose data can be got at without going through its user interface. Its business rules are expressed in one identifiable place rather than smeared across a codebase. Its integrations are adapters at the edge rather than assumptions baked into the core.
The test we apply is simple. If a new consumer needed the same data tomorrow, would they call an interface we already have, or would somebody have to go into the database and reverse engineer the schema? The second answer means every future integration is a bespoke project, and over two decades that is where the budget goes.
Procurement should ask for proof, not promises
These are the questions procurement should actually ask.
- How many people in this country can maintain this stack, and how did you arrive at that number?
- Show us a rebuild of the whole environment from source, performed today.
- Take one figure from last month’s regulatory submission and trace it to the meter readings behind it.
- What is the export format for our historical data, and can we open it without your software?
- Which parts of the system could, by any path, cause a physical action, and how is that path controlled?
- If we terminated in ninety days, what exactly would we have?
Short-horizon choices cost more when the system has to live for decades
We have inherited two systems in this sector built against a short horizon. Both worked. Both were written in stacks that had moved on, with configuration that existed only on the running servers, and documentation that described an earlier version.
In both cases, the replacement cost more than the original build. The largest line item was not writing new software. It was establishing what the old system actually did, because the specification had never existed anywhere except in the code and the code was the thing nobody could read any more.
Twenty years is the normal, not unusual, horizon in this sector. Software chosen against a two year horizon and then kept for twenty is not a technology decision that aged badly. It is a technology decision that was never made against the right question.
More on how we work in this sector on our energy and utilities page, and on the handover commitments in how we work.
