Operational systems cannot tolerate an outage
Control and safety systems run continuously and the consequence of failure is physical, so the change practices used on business systems do not transfer.
Technology consulting for energy and utilities
Utilities operate systems where a failure has physical consequences and an outage window does not exist. That combination — safety relevance, continuous operation and regulated reporting — sets the engineering constraints more firmly than in any sector except perhaps healthcare.
Industry overview
A utility's estate spans operational systems that control physical infrastructure and business systems that bill, plan and report on it. The operational side runs on long lifecycles with safety and availability as the governing properties; the business side changes far more often.
Between them sits an increasing volume of asset and meter telemetry. That data would materially improve maintenance, loss detection and network planning, but extracting it introduces a path into an environment where a mistake has consequences beyond a service outage.
Regulated reporting is the third constraint. Utilities report against obligations where figures must be defensible and reproducible years later, which makes lineage a functional requirement rather than a data-management nicety. Our work is usually at these three intersections.
Business challenges
What utilities bring to us most often.
Asset telemetry is collected but not used
Meter and sensor data is captured at volume and used for little beyond billing, because the pipeline and context needed to make it analytically useful were never built.
Regulated figures must be reproducible
Reported numbers may be examined years later, and where they were assembled from extracts, reproducing them requires reconstructing a process nobody documented.
Field work is disconnected from the estate
Crews operate in locations without reliable connectivity, so work orders, asset updates and safety records are captured late or on paper.
Asset records disagree with reality
What the asset register says is installed, and what is actually in the ground, diverge over decades of works — and every plan built on the register inherits that error.
Legacy control software outlives its support
Physical assets are depreciated over decades while their control software reaches end of support in years, leaving critical infrastructure running unsupported code.
Digital transformation challenges
Utility transformation is constrained by the fact that the network cannot be paused and by the fact that regulated commitments are made years in advance. A programme that assumes flexibility in either is planning against conditions that do not exist.
The pattern that works is separating the business estate, where change can be frequent, from the operational estate, where it cannot. Most of the value in a utility transformation is available on the business side and at the boundary, without touching control systems at all.
- Business and operational estates transformed on different clocks, deliberately
- Value pursued at the boundary first, where control systems are not touched
- Regulated commitments treated as fixed dates that shape the plan
- Field-facing change piloted with crews, who will otherwise revert to paper
Regulatory considerations
Utilities report against obligations covering service performance, losses, outages, safety and increasingly environmental impact. The common requirement across all of them is that a figure must be reproducible and defensible, potentially long after the people who produced it have moved on.
That makes lineage a functional requirement. Where reporting is assembled from extracts with manual adjustment, the derivation lives in working files, and reproducing a figure years later becomes an archaeology exercise.
We advise on technical design and evidence architecture. We do not provide regulatory opinions, and we do not represent NG&NR as holding certifications it has not been awarded.
- Reported figures derived from a governed source, with lineage retained
- Safety-relevant system changes handled under their own validated process
- Retention aligned to regulatory horizons rather than to IT defaults
- Environmental and loss data captured at source rather than estimated later
Enterprise architecture approach
The defining decision is the boundary between operational and business technology, and specifically that data flows outward while control does not flow inward except through narrow, audited paths.
The second is that the business estate must not become a dependency of operations. Where a control room comes to rely on an enterprise system, the availability requirement of the whole IT estate has changed without anyone deciding it should.
The third is the asset register. It is the entity almost every other system references, and where it is inaccurate, maintenance planning, works management and regulatory reporting all inherit the error.
- A narrow, audited boundary with outbound data separated from inbound control
- Operations able to continue when the business estate is unavailable, by design
- One authoritative asset register, with correction from the field designed in
- Legacy control software isolated where it cannot be remediated
Cloud strategy
Control systems stay local. Determinism, safety certification and independence from a wide-area link are functional requirements, and no improvement in connectivity changes that position.
Above the boundary, cloud suits utilities well: telemetry volumes are large and peaked, analytical workloads are intermittent, and multi-site consolidation is frequently the objective. Edge processing at substations and sites handles what must remain local, with only what is needed centrally travelling.
The consolidation case is worth stating plainly, because it is the one most often underestimated. Comparing performance across sites is what turns telemetry into a maintenance and loss-reduction programme, and it is impractical while each site holds its own data in its own form.
- Control and safety systems remain local; that is a requirement, not a stage
- Edge processing at sites, with aggregate data travelling centrally
- Elastic capacity for intermittent analytical and modelling workloads
- Connectivity loss handled as a normal condition with store-and-forward
Data strategy
Utility data is dominated by time series at volume, and the design questions are the economic ones: what resolution to keep, for how long, and what to aggregate. Those decisions determine both cost and what analysis remains possible later.
The second problem is context. A meter or sensor reading is only interpretable alongside the asset it came from, its configuration at the time and any works in progress — and that context lives in the asset register, which is exactly the record that tends to be inaccurate.
- Resolution and retention decided per signal against the analysis it supports
- Telemetry joined to asset context, which requires the register to be trustworthy
- Time synchronisation treated as foundational, because sequence carries meaning
- Regulated reporting derived from the same governed source as operational analysis
Security considerations
Utilities are critical national infrastructure, and compromise of operational systems has physical rather than informational consequences. That inverts the usual priority: availability and integrity outrank confidentiality on the operational side.
The practical constraint is that a meaningful proportion of operational systems cannot be patched on any schedule set by IT. The controls that work are architectural — segmentation that bounds reach, monitoring that does not interfere with control traffic, and named compensating controls where remediation is genuinely impossible.
- Segmentation that bounds what a compromise can reach, since prevention will not hold
- Compensating controls named and owned where a system cannot be patched
- Remote vendor and contractor access scoped, time-bound and recorded
- Monitoring that observes operational networks without interfering with them
Software engineering
Software near operational systems carries a testing burden closer to embedded engineering than enterprise development, because the environment cannot be exercised freely and the consequence of a defect is physical.
Field software is the second demanding area. Crews work in locations without reliable connectivity and frequently in conditions where a device is awkward to use, which makes local-first design and extremely simple interaction more important than feature breadth.
The third consideration is horizon. Software written for a utility will be operated far longer than commercial equivalents, alongside assets depreciated over decades. That argues for conventional, well-supported technology and for documentation treated as a deliverable rather than as an activity that follows delivery.
- Simulation for what cannot be exercised on live infrastructure
- Observation and control separated, with different assurance levels for each
- Local-first field applications that work without connectivity and reconcile after
- Conservative failure behaviour: stop safely rather than proceed uncertainly
Integration strategy
Utility integration spans control protocols, asset and works management, metering, billing and market or settlement interfaces. These have almost nothing in common technically, and a single integration approach across all of them serves none well.
Market and settlement interfaces add externally-set contracts with timing obligations, where a late or malformed submission has commercial consequence. Those warrant their own reliability design rather than sharing the general pattern.
- Operational and business integration treated as separate problems
- Metering and settlement flows designed for their timing obligations specifically
- Store-and-forward from sites, because connectivity interruption is routine
- Reconciliation between metering, billing and settlement designed into the flow
Recommended NG&NR services
The services usually engaged first in this sector, and why.
Enterprise Architecture
The operational boundary, the asset register as a shared entity, and keeping operations independent of the business estate.
AI & Data Engineering
Time-series economics, telemetry joined to asset context, and reporting derived from a governed source with lineage retained.
Cybersecurity
Segmentation that bounds reach where operational systems cannot be patched, and vendor access that is scoped rather than standing.
Cloud Consulting
Edge processing at sites with consolidation centrally, and elastic capacity for intermittent analytical work.
Software Development
Field applications that work without connectivity, and systems near operations built with conservative failure behaviour.
Managed IT Services
Operating estates with no outage window, where knowledge must live in runbooks rather than individuals.
Recommended technologies
Selected against the constraints above, not against a preference. We hold no vendor partnerships.
Databases
Time-series retention and the asset records it must join to — where the cost curve of the whole estate is set.
Python
Telemetry pipelines, loss analysis and the reconciliation between operational and regulated reporting.
Kubernetes
Workloads at the edge and centrally, where site-local processing must run independently of a wide-area link.
.NET
Common across asset, works management and customer systems in utility estates.
Java
Where larger metering, settlement and network management platforms are built and extended.
Microsoft Azure
Frequently the incumbent enterprise platform, with hybrid connectivity to sites that must keep operating independently.
Delivery approach
How an engagement runs where failure has physical consequences.
Free first consultation
Your operational and business estate, and whether the constraint is data access, the boundary, or reporting reproducibility.
Assessment against the running estate
What crosses the boundary today, how trustworthy the asset register is, and how regulated figures are actually produced.
Constraint and obligation mapping
Safety validation requirements, regulated commitments, patching limits and connectivity realities, recorded as hard inputs.
Target architecture and a pilot
Boundary design proven at one site or substation before any wider commitment is made.
Rollout with your teams
Site by site, with field crews involved in design and benefits measured in the field rather than inferred.
Handover
Runbooks, boundary documentation and lineage records, so reporting is defensible without us.
Frequently asked questions
No, and that is a settled position rather than a sequencing question. Determinism, safety certification and independence from a wide-area link are functional requirements of control systems. Cloud pays above the operational boundary — telemetry consolidation, analysis, planning and business systems.
Usually because context is missing rather than volume. A reading is only interpretable alongside the asset it came from, its configuration at the time and any works in progress — and that context lives in the asset register, which is frequently the least trustworthy record in the estate.
By designing correction from the field into normal work rather than running a one-off survey. Registers diverge over decades of works, and a survey restores accuracy briefly unless the mechanism that caused the drift is addressed. Field crews are the only practical source of continuous correction.
By deriving them from a governed source with lineage retained, rather than assembling them from extracts with manual adjustment. Where the derivation lives in working files, reproducing a figure years later becomes an archaeology exercise — and that is exactly when it is asked for.
Name them, bound what a compromise of them can reach through segmentation, and apply compensating controls with named owners. A policy requiring patching that everyone knows will not happen provides no protection and obscures where the risk actually sits.
Decided per signal against the analysis it supports. Full resolution indefinitely is expensive and rarely justified; aggregating too early destroys the detail that diagnoses a fault or proves a loss. Both decisions belong with the engineers who will use the data, not with a storage default.
With local-first applications that work without connectivity and interaction simple enough to use in poor conditions. Crews revert to paper because the alternative is slower or fails in the field, and that is a design outcome rather than a compliance problem.
It can, and the important thing is deciding that deliberately. Where a control room comes to depend on an enterprise system informally, the availability requirement of the entire IT estate has changed without anyone agreeing to it — and that is usually discovered during an unrelated outage.
Usually most of it. The business estate and the boundary between the two carry the majority of the available improvement — asset data, works management, reporting, planning and customer systems — none of which requires changing a control system.
As their own reliability problem rather than as part of the general integration pattern. They carry externally-set contracts and timing obligations where a late or malformed submission has direct commercial consequence, and that warrants specific design rather than a shared default.
We do not name clients or publish case studies in any sector. The first consultation works through the reasoning on your own estate, which is a better test of judgement than a reference list.
Conservatively. Software written for a utility outlives most commercial equivalents and will be maintained by people who were not present when it was built, so a well-supported and widely understood choice is worth more than a currently fashionable one. Documentation is part of that choice, not a step afterwards.
Next step
Discuss a utility estate
A free first consultation covering your operational boundary, how trustworthy your asset data is, and how much improvement is available without touching a control system.
No cost, no obligation. Pricing is transparent and includes GST.