Why two Org Charts slow down the AI-native Power Grid
Disclaimer: The article was originally written for my Ai-Native Power Grid newsletter, but has been adapted for the Energy Central community.
Mel Conway observed that organizations design systems that copy their own organization or communication structure. In 1967, he was writing about compilers. Nearly sixty years later, for me it still looks like the most accurate description of grid (operations) software.
The short Version
A few weeks ago I published a post on LinkedIn and argued that every utility runs four or five maps of the same grid: GIS, OMS, SCADA, AMI, EAM.
But why? Because it has four or five different (siloed) departments:
Engineering has the GIS. As built.
Operations has the OMS and SCADA. As operated.
Metering has the AMI head-end. As measured.
Asset management has the EAM. As inspected.
And that the software vendors often ship those same “departments” back to them as products.
The post was mainly about the static picture: what the grid is or what the grid “looks like”.
This piece here will focus on the dynamic picture: what the grid is about to do. And who gets to decide.
In case you want to fresh up your memory, here the link to the post published on LinkedIn.
Three Forecasts, but only one Feeder
Let’s move into the operational stack. Believe me, in OT, Conway’s law gets more expensive (and expressive). Let us use forecasting as a showcase for our deep dive.
The EMS forecasts load for the transmission system. The ADMS forecasts load for distribution, to run power flow, validate switching and estimate state where measurement data is thin or faulty. The DERMS forecasts DER output and their available flexibility, because that is what it dispatches. Planning forecasts again, on peak-day snapshots, years out.
Same grid. Same feeders. Same customers. Same weather. Three or four forecasting models, trained on different data, owned by different teams, producing different numbers for the same hour.
Nobody designed it this way. The EMS came from the transmission control room. The ADMS from distribution operations. DERMS from renewable initiatives, customer and regulatory programs. Planning from engineering. Each department bought a system for its own problems, tasks and processes. And every major vendor sold each of them a product with its own model, its own data pipeline and its own forecast algorithm.
The hard boundaries and seams show wherever work crosses a box. Where processes cross a silo.
Let’s go deeper:
DERMS dispatches a battery. The ADMS learns about it as a schedule arriving through an interface. ADMS then checks it against constraints calculated on a different load forecast. The transmission operator asks for flexibility at the TSO/DSO boundary. The answer to that is assembled from two systems that disagree on what is connected downstream. Planning grants a flexible connection on the assumption that operations can curtail it. Operations inherits that promise in a model planning never sees.
Seen that before? I have. I have watched a DERMS dispatch order get rejected by the ADMS it was supposed to relieve.
Why it stops being tolerable
For most of the grid’s digital history this was fine, because the functions, processes or workflows barely touched. Planning worked in years, operations in minutes. DER was a rounding error. Each forecast only had to be good enough for its specific use case meaning its specific silo.
That separation is gone. Flexible connections, hosting capacity, DER dispatch, large loads asking to connect on timelines no planning cycle was built for. These are decisions that start in planning and are executed in operations. Sometimes in the same week (or day). The time horizons now overlap. The models, the data, the algorithms: They do not.
What AI actually needs
The default AI roadmap in our industry is a copilot or AI assistant bolted onto each of the system. An assistant in ADMS. Another one in DERMS. Yet another one for planning. That is Conway’s law again: three-four-five departments, three-four-five assistants. Each creating its own system’s perceived or partial truth but more fluently than before.
The real value is not inside the systems. It is in the workflows that span across the silos:
A connection request evaluated against the same forecast operations later will use to curtail it.
A DER dispatch proposed with the switching plan and the outage schedule in the same view.
A restoration plan that knows which batteries are available now, not at the last export.
None of these intelligent workflows needs a smarter model. What they need is planning and operations to run on the same network model and on the same good data. And they must treat time horizons as parameters. Rather than conditions set by departments.
It does not need to be one forecasting module as time horizons differ, and the methods eventually do too. But it must be one “forecast of record”: same inputs, reconciled across horizons, with provenance a planner and a dispatcher can both inspect and trust.
And one boundary stays firm. Intelligence can span functions. Control should not. An AI that reasons across planning and operations proposes. The ADMS and EMS, deterministic and certified, decide and operate. Crossing departments is where the value is. Crossing the cognition/control line is where the risk is.
Here is a reminder on my post about the Cognition / Control Boundary in an AI native Grid.
Who moves first
Which utilities move first (tier-one, two or three) is a cost and organizational question: Is it too much sunk cost? Are there too many teams whose job is keeping the models in sync?
And vendors? Putting ADMS, DERMS and planning on one model means merging the business units and product lines that own them. It’s a question about breaking silos.
The utilities that can move fastest are the ones where planning and operations already sit in the same room (such as municipals and cooperatives). The ones where the org chart is small enough that one model and one forecast are a project, not a transformation. And the builders and providers who can serve them are the ones agile and dynamic enough to sit outside or on top of both org charts.
What are your thoughts?