Why IEC 61968 belongs at the center of utility modernization
Every utility I talk with right now is running at least one AI pilot — an outage-prediction model, a vegetation-risk model, an asset-failure model, a customer-service copilot. Nearly all of them share the same fate: the model performs beautifully in the lab and then quietly stalls the moment someone tries to put it into production. The team spends the next six months troubleshooting the algorithm, tuning hyperparameters, gathering more data — when the actual problem was never the model at all.
The real problem, in almost every case I've seen, is the data foundation underneath it. Utilities run dozens of core systems: an outage management system, a GIS, an asset management platform, a customer information system, a work management system, DERMS, SCADA, AMI, and more. Each was built, procured, and integrated for a specific purpose in isolation, often over multiple decades.
The problem is that each system can have its own model of the same physical world.
When a transformer fails, the OMS may have one identifier for it, the EAM another, and the GIS a third. One system might define a customer, feeder, or service point differently from another. Before you can ask AI to identify patterns across those systems, someone has to establish what the data actually means and how it relates.
Reconciling all of that by hand, system by system, is what I call the integration tax: the invisible cost utilities pay every day in duplicated effort, brittle point-to-point interfaces, manual reconciliation, and data that can't easily be trusted for more sophisticated use cases.
We've seen just how deep that complexity can run. In one TSG utility modernization engagement, a critical CIS replacement involved more than 50 surrounding legacy applications, decades of integrations, undocumented dependencies, and manual workarounds that had to be understood before the organization could safely move forward.
That complexity existed long before generative AI entered the conversation. AI is simply exposing its consequences faster.
Why this is coming to a head now
The pressure to fix this has been building for a decade, but it's compounding faster than most utilities' architecture roadmaps anticipated. Grid decentralization, the proliferation of behind-the-meter solar and storage, EV load growth, and rising customer expectations for real-time information are all landing at the same time IT and OT are being asked to converge and AI is becoming economically viable at scale. Any one of these forces would justify a modernization investment on its own. Together, they make a canonical data foundation not a nice-to-have architectural cleanup project, but the precondition for everything else a utility wants to do with its data.
The standard built for exactly this problem
This is precisely the gap IEC 61968 — the IEC Common Information Model standard for distribution — was designed to close. It defines a shared semantic model and a canonical messaging framework so that OMS, GIS, CIS, WMS, DERMS, and asset management systems can describe the same transformer, the same feeder, the same outage event, in exactly the same terms. Implemented well, it turns a utility's enterprise integration layer into a hub that every application can plug into through a well-defined contract, rather than a web of custom, brittle, one-off interfaces that break with every vendor upgrade.
The part of the standard most practitioners actually work with, IEC 61968-100, goes a step further: it defines a canonical message envelope and a fixed vocabulary of action verbs — Get, Create, Change, Execute, and so on — so that any CIM-conformant system can interpret a message without knowing anything else about the system that sent it. Recent editions extend this to REST APIs, which is what makes CIM relevant to modern, cloud-native integration platforms rather than just legacy enterprise service buses.
From interoperability to intelligence
None of this is compelling on its own merits to a utility executive weighing competing modernization priorities — until you connect it to what's actually on most utilities' roadmaps right now: AI. Every one of the AI use cases utilities are racing toward — outage prediction, asset-failure forecasting, crew dispatch optimization, DER and load forecasting, generative AI customer service copilots — depends on training data that is consistent, de-duplicated, and semantically unambiguous. A model trained on inconsistent asset IDs and a dozen different definitions of “transformer” doesn't fail because the algorithm is weak; it fails because it was never given a trustworthy foundation to learn from. CIM-aligned data is what makes that foundation trustworthy, and it's the difference between an AI pilot that never leaves the lab and one that scales into daily operations.
A practical path, not a rip-and-replace
The good news is that adopting this approach doesn't require replacing your existing systems of record. It requires a canonical integration layer sitting between them, a governance function with real authority over the model, and a deliberate decision to mandate CIM conformance in new vendor contracts rather than inheriting another decade of proprietary interfaces. Utilities that treat this as a multi-year architectural discipline — not a single project — are the ones building AI data pipelines today that their peers will still be reverse-engineering five years from now.
Where this leaves you
This is the work I spend most of my time on: helping utilities build the data and integration foundation that makes their AI, analytics, and modernization investments actually pay off, rather than stalling in pilot purgatory.
If your organization is wrestling with fragmented systems, an AI initiative that isn’t gaining traction, or a modernization roadmap that needs an honest architecture conversation, connect with me on LinkedIn. I’ll continue sharing what I’m seeing across the utilities space, what’s working, and where teams are getting stuck.
Latest insights, in your inbox
Subscribe now to receive the latest news and insights from TSG.
%20(2).png?width=100&height=97&name=Inverted%20Logo%20(1)%20(2).png)