DERMS, EMS, DCIM — three categories pretending to be one

Buyers in this market walk in asking for a DERMS and leave with a DCIM. Sometimes in reverse. The three categories have been conflated so thoroughly in vendor pitches that most procurement teams can't draw the lines between them, and the lines matter more than the vendors let on.

A DERMS — distributed energy resource management system — was built for grid operators and aggregators. Its purpose is to coordinate thousands of small assets (rooftop solar, EVs, residential batteries) into something a utility can treat as a single dispatchable block. AutoGrid, Kraken Flex, EnergyHub. These platforms assume you don't own the assets, that you're negotiating with hundreds of owners, and that the constraint is as much behavioural as technical.

An EMS in the utility sense is the real-time control system running a power plant or a substation. ABB, Siemens, Schneider PSE. In the building sense the acronym got reused for something adjacent: track energy use, optimise HVAC, report to ESG systems. Two different species using the same three letters, which is some of why the confusion propagates.

A DCIM — data centre infrastructure management — is a 2010s-era product class built around rack-level monitoring. Nlyte, Vertiv Trellis, Schneider EcoStruxure IT. Its centre of gravity is inventory, white-space planning, and M&E monitoring inside the facility perimeter. It assumes the grid is a given, stable input. Power from the wall.

Look at what each category was designed to answer.

DERMS: how do I coordinate fleets I don't own? Grid-side EMS: how do I keep this substation stable in real time? Building EMS: how do I make this facility more efficient? DCIM: what's in this rack and is it running?

Now consider what an AI data centre operator in Frankfurt actually needs to answer in 2024. How do I shape my draw to stay inside my connection limit during the [18:00] peak? How do I capture imbalance revenue when prices spike? What does my 36MW site look like in three hours when the training run kicks off? None of the four categories above was architected for that question.

I know this is a take that will irritate the vendors who read it, and I'm partly playing devil's advocate, but I can't help noticing that each of those product classes has bolted on features to claim adjacency to this problem, and none of them is solving it cleanly. DERMS vendors pitch DC flexibility as just another DER. It isn't. A 40MW DC isn't a fleet of 40,000 residential batteries. The control surface is different. So is the risk profile, and the revenue model doesn't map at all. DCIM vendors pitch grid integration. What ships is a tab showing a single utility-meter reading. Grid-side EMS vendors pitch it too. What ships is out of the operator's price range and requires a two-year SI engagement.

So what buyers tend to do is assemble. One product for rack-level, one for BESS, one for market interface, one for reporting. They back it with spreadsheets. Then they spend the next two years integrating, and discover the integration is the product.

The deeper issue is that these categories all formed before AI became the dominant load class. The assumption was steady, predictable, non-dispatchable load. Lights, servers, HVAC. You didn't orchestrate the load itself because the load didn't want to be orchestrated. AI training changes that. Training jobs are batch-scheduled, flexible within limits, and increasingly aware of their own power footprint. The compute scheduler and the energy scheduler are converging. None of the legacy categories is set up for that convergence.

A category built for this would have real-time as a primary concern rather than an integration challenge. Native bid construction for ancillary markets at DC scale. A control surface that speaks to both breakers and batch schedulers. Safety-critical dispatch logic instead of advisory dashboards. A willingness to be wrong about some things and ship anyway.

The existing acronyms will stretch until they snap.