Asset and network data architecture for utilities
This is the fifth of 10 Information Systems Architecture modules. It examines why asset and network information in utilities carries physical, operational, and planning consequences that change the shape of the information architecture problem. The module introduces the Common Information Model (CIM) as the shared semantic reference for power-systems information.
By the end of this module you will be able to:
- Explain why asset and network information changes the shape of the architecture problem in a utility
- Identify the main utility-style information groupings that must stay coherent across planning and operations
- Describe why operational-system boundaries should not automatically define enterprise information boundaries
- Explain the CIM in plain language and describe what it offers as a shared semantic model for power-systems data
- Describe how CIM alignment affects enterprise integration and publication decisions
- Use the London case to connect data quality, publication, and operational consequence
Real-world case · 2024
A cable route that no longer existed. A cost estimate that was wrong by hundreds of thousands.
In mid-2024, a distribution network operator discovered a discrepancy between its geographic information system and its asset register. The GIS showed a cable route running under a residential street that had been rerouted three years earlier during a highway improvement scheme. The asset register had been updated to reflect the new route, but the GIS had not.
When a planning team used the GIS to model reinforcement options for a housing development, the cost estimate was wrong by over four hundred thousand pounds because the model assumed a cable route that no longer existed.
Nobody had made a deliberate error. The two systems held different lifecycle stages of the same physical truth, and no architecture governed the relationship between them. The planning consequence was significant. The safety consequence could have been worse.
If two systems hold different lifecycle stages of the same physical truth and no architecture governs the relationship between them, what happens when a planning team uses the wrong one?
That story illustrates why asset and network information in utilities needs its own architecture conversation. The consequences of getting it wrong go beyond reporting errors. They affect safety, service continuity, planning accuracy, and regulatory evidence.
30.1 Why utility information is different enough to matter
General enterprise-architecture examples often focus on customer, finance, or workforce information. Those are still relevant, but a utility adds a different layer of consequence. Asset and network information affects safety, service continuity, planning accuracy, resilience, and external evidence obligations all at once.
That means the architecture cannot treat these datasets as background technical detail. They are part of the operating reality the enterprise is trying to govern. A wrong cable route is not a reporting error. It is a planning failure with financial and potentially safety consequences.
Five characteristics distinguish utility information from typical office-system data. First, the information represents physical reality that has safety consequences. Second, multiple teams update different aspects of the same physical asset over time. Third, planning decisions depend on the coherence of asset, network, and spatial data. Fourth, external publication obligations require traceable, governed information chains. Fifth, the information lifecycle can span decades, from design through installation, operation, maintenance, and eventual decommissioning.
“Utility information architecture must account for the physical, operational, and regulatory consequences of information incoherence. Asset, network, planning, and telemetry information serve enterprise purposes that extend well beyond record-keeping.”
Working definition for utility-context information architecture - G190, Information Mapping
The physical and operational consequences that utility information carries distinguish it from typical office-system information. The architecture must account for those consequences explicitly.
30.2 The core utility information groupings
Five groupings carry most of the architectural weight in a utility context. Each one has different authority owners, consumers, and governance pressures.
Asset information. What exists, what condition it is in, and how the enterprise identifies, maintains, and reasons about physical assets. This includes asset identity, specification, condition, maintenance history, and lifecycle state. The asset register, maintenance systems, and design records all participate in this domain.
Network information. How the network is structured, connected, modelled, and constrained for planning and operational use. This includes topology, connectivity, ratings, and the spatial relationships that planners and operators depend on. The GIS, network model, and engineering-design systems all contribute.
Planning and scenario information. Assumptions, options, forecasts, and model outputs that support future investment and operating decisions. Planning information is particularly sensitive because it shapes capital allocation and regulatory evidence. The modelling tools, scenario engines, and investment-planning systems hold this domain.
Telemetry and operational information. Real-time and near-real-time observations from field sensors, SCADA systems, and smart meters. This information feeds operational dashboards, fault detection, and condition monitoring. Its authority is time-based: the most recent valid reading is typically authoritative.
Publication information. External-facing information products that depend on coherent upstream meaning and authority. Publication views face external scrutiny and must carry metadata that allows consumers to interpret them correctly. LTDS-style outputs sit in this domain.
A network reinforcement decision depends on asset condition, network topology, planning assumptions, and telemetry. If any of those information groupings is incoherent with the others, the reinforcement decision is built on conflicting evidence. That is why the architecture must treat these groupings as connected domains, not as separate technical databases.
30.3 The Common Information Model explained simply
The Common Information Model (CIM) is an international standard (IEC 61968 and IEC 61970) that provides a shared language for describing power-system information. It defines standard ways to represent assets, network topology, connectivity, measurements, customers, and operational states so that different systems can exchange and interpret information consistently.
Think of the CIM as a shared vocabulary for power-systems data. Without it, each system invents its own terms for the same concepts. One system might call a transformer by its engineering specification code. Another might use an internal asset identifier. A third might reference it by its geographic location. The CIM provides standard names and structures so that all three systems can understand each other.
The CIM is relevant to enterprise architecture for three reasons. First, it provides a semantic baseline that integration and publication decisions can reference. Second, it aligns internal information structures with the external models that regulators and industry partners expect. Third, it reduces the translation overhead when information moves between systems, because both sides share the same vocabulary.
CIM alignment does not mean every internal system must use CIM natively. It means the enterprise understands the mapping between its internal information structures and the CIM, and that mapping is governed. Some systems will use CIM directly. Others will use internal models with documented CIM mappings at the boundaries. The architecture decision is about where CIM alignment adds enough value to justify the effort.
“The Common Information Model provides a standardised semantic framework for power-system information, enabling consistent representation of assets, network topology, measurements, and operational states across different systems and organisations.”
IEC 61968 / IEC 61970 - CIM Standards
CIM is a shared vocabulary, not a mandatory database schema. The enterprise decides where CIM alignment adds enough value to justify the investment. The architecture should document that decision explicitly.
Common misconception
“Operational-system ownership should define all information boundaries in a utility.”
If operational-system ownership dictates all the information boundaries, later reuse and publication work usually becomes harder than it should be. The architecture needs to distinguish between how information is operationally managed and how it is governed and shared at enterprise level.
30.4 Why system boundaries are not enough
Operational platforms are important, but their boundaries are not automatically the right enterprise information boundaries. One system may be excellent for running a function while still being a poor organising principle for publication, analytics, or enterprise governance.
This is why information architecture has to stand slightly above the operational estate. It needs to explain the enterprise meaning and the cross-domain relationships first. The GIS-versus-asset-register story at the top of this module illustrates the point: both systems were operationally sound, but the enterprise had no architecture governing the relationship between them.
The CIM helps here because it provides a common semantic layer that sits above individual system boundaries. When two systems need to exchange asset or network information, the CIM provides a shared language for the exchange. When the enterprise publishes network development data, the CIM provides the semantic framework that external consumers expect. Without that layer, every integration and every publication becomes a custom translation exercise.
30.5 What good utility data architecture should support
Four outcomes distinguish a working utility information architecture from a passive inventory.
- Safer and more reliable planning and operational decisions. The architecture should ensure that the information feeding planning models and operational dashboards is coherent, current, and traceable.
- Clearer authority over what is published or reused. When the enterprise publishes network data, planning forecasts, or regulatory evidence, the architecture should show which upstream sources are authoritative and how CIM alignment is maintained.
- Better traceability from source systems to enterprise views. If a regulator or governance board asks where a published number came from, the enterprise should be able to trace it back through a governed chain.
- More credible integration between physical-network understanding and enterprise decision support. The architecture should connect operational reality to the decision-support layer, with CIM providing the semantic bridge where appropriate.
London Grid Distribution
In the London case, asset condition, topology, planning assumptions, telemetry, and publication views all need to work together. That is the only way to support a credible LTDS-style and operationally useful information architecture.
CIM alignment is particularly important for London because LTDS publication expects network development information to be structured in ways that external consumers can interpret. If the internal information architecture uses entirely proprietary structures with no CIM mapping, every publication cycle becomes a manual translation exercise. If the architecture includes documented CIM mappings at the key boundaries, publication becomes a governed process rather than an emergency scramble.
- London requires asset and network information to be treated as enterprise assets, not only operational records.
- CIM alignment decisions should be documented in the Phase C pack, showing where CIM is used natively, where mappings exist, and where the enterprise has deliberately chosen a proprietary approach.
- A London planner who uses network topology data that contradicts the asset register is making investment decisions on a foundation that the enterprise has not verified.
- The five information groupings (asset, network, planning, telemetry, publication) must be governed as connected domains in the London Phase C pack.
A utility's GIS and asset register disagree about the route of a cable that was rerouted three years ago. A planning team uses the outdated GIS data to estimate reinforcement costs. The estimate is materially wrong. What is the architecture failure?
An enterprise publishes network development data using entirely proprietary structures with no CIM mapping. Every publication cycle requires manual translation. What architecture decision would reduce this overhead?
An architecture team defines utility information domains using the names of the operational platforms that manage them. A senior architect challenges this approach. What is the strongest reason for the challenge?
Key takeaways
- Utility data architecture has direct enterprise consequences for safety, planning, resilience, and evidence.
- Five information groupings carry the architectural weight: asset, network, planning, telemetry, and publication.
- The CIM provides a shared semantic vocabulary for power-systems information. CIM alignment does not mean every system uses CIM natively, but the enterprise should know where mappings exist.
- Operational systems matter, but they should not define enterprise information boundaries automatically.
- Good utility information architecture supports both operational use and broader enterprise trust.
- CIM alignment decisions should be documented explicitly in the Phase C pack, with rationale for where alignment is maintained and where it is deliberately omitted.
Standards and sources cited in this module
Full guide
Provides the information-domain structuring method applied to utility-specific information groupings.
The TOGAF Standard, 10th Edition (C220)
Part 1, Phase C
Core standard context for information systems architecture in asset-intensive enterprises.
IEC 61968 / IEC 61970 (CIM Standards)
Common Information Model for power systems
The international standard that provides the shared semantic model for power-systems information exchange and publication.
You now understand why utility data architecture carries operational and planning consequences, and how the CIM provides a shared semantic reference. The next question is: how does metadata management ensure that published and shared information carries enough context for consumers to trust it? That is Module 31.
Module 30 of 64 · Information Systems Architecture