Data Centers are Ready to Flex. Their Software Stack Isn’t Yet.

June 30, 2026

We’re excited to have our technology partner, Codibly, contribute this guest column for The Current. 

The math on data center demand response is straightforward.  

With U.S. data center power consumption on track to reach 106 GW by 2035, according to BloombergNEF, grid operators need flexible load. And data center operators — facing both rising energy costs and mounting pressure to demonstrate grid citizenship — have every reason to enroll in demand response and energy flexibility programs. So, the earnings and savings from participating are valuable for data centers. 

Why then does getting data centers from “interested” in demand response to “dispatching” take so long? The answer isn’t willingness.  

Most large data center operators we talk to understand the revenue case for demand response and the strategic value of being a grid resource rather than just a grid burden. The bottleneck is further down the stack — in the integration layer between data center energy systems and aggregator platforms.  

A first wave of vendors is already tackling part of this, mostly by making AI compute flexible. The harder problem — coordinating a facility’s full range of flexible assets and dispatching them in demand response and energy flexibility programs — is where most of the value is still stranded. 

The Control Layer Was Built for a Different World 

Demand response infrastructure evolved to manage distributed, heterogeneous loads — thousands of thermostats, water heaters, EV chargers and commercial HVAC systems, each with modest curtailment capacity. Protocols like OpenADR and CTA-2045 were designed for that world: standardized signals dispatched to many small endpoints. 

Data centers don’t fit that mold. A single campus may draw 50–200 MW, with flexibility spread across cooling systems, UPS reserves, compute workload scheduling and backup generation — each managed by different platforms (DCIM, BMS, power monitoring) that were never designed to take external dispatch signals. The result is not a lack of connectivity solutions, but an integration challenge.  

Aggregators can model the flexibility, and grid operators can value it, but moving from point-to-point connectivity or single-asset flexibility to repeatable orchestration across cooling, UPS, on-site generation and compute together often requires custom engineering that takes months and rarely scales cleanly to the next facility. 

What the Middleware Layer Actually Needs to Do 

This isn’t a protocol problem in the traditional sense. OpenADR 3.0’s shift to RESTful APIs and program-based constructs is a step forward and IEEE 2030.5 handles DER assets like batteries and on-site solar well. But data center demand flexibility requires orchestration across asset types that don’t share a protocol, a vendor or even a control philosophy. 

A functional integration layer for data center DR needs to handle three things simultaneously: 

  1. Translation — converting aggregator dispatch signals into actionable commands for each subsystem. A “reduce 10 MW for two hours” instruction from a capacity market event means something different to a chiller plant than it does to a workload scheduler. 
  2. Coordination — sequencing those actions so they don’t conflict. Reducing cooling while maintaining compute load creates thermal risk. Shifting workloads to another region while shedding backup generation changes the facility’s resilience posture. The middleware must understand these dependencies. 
  3. Verification — reporting actual performance back to the aggregator in near-real-time, with the telemetry granularity that settlement requires. Most DCIM platforms track energy at the facility or zone level, not at the resolution needed for M&V against a baseline.

The Revenue Case Demands the Investment 

Also, data center operators often underestimate the revenue available from demand response because they think about a single program. The real value comes from stacking: capacity markets, energy arbitrage, ancillary services, and increasingly, local flexibility markets in jurisdictions where they exist. 

For a data center with 20 MW of genuinely flexible load, the annual revenue opportunity across stacked programs is material — but only if the facility can respond reliably and automatically to dispatched events. Manual workarounds usually don’t cut it. 

The irony is that data centers are among the most instrumented, automated facilities on the planet. The monitoring, the actuators, the control logic — it all exists. Solutions for the connective tissue between those internal systems and the grid are emerging too. Many early approaches, however, are still optimized around a narrower flexibility use case, asset class or route to market. What remains harder is integration that spans every flexible subsystem and speaks fluently to the market interfaces aggregators operate, including the settlement-grade measurement and verification programs require. 

Building the Bridge, Not Waiting for a Standard 

It would be convenient to wait for a single industry standard that bridges data center energy systems and DR platforms. However, that standard isn’t coming — at least not soon enough to capture the market window current capacity prices and regulatory momentum have created. Nor will any single point solution close the gap on its own, as long as each is tied to a single type of asset or route to market. 

The pragmatic path is vendor-neutral integration: middleware that sits between data center operations and aggregator platforms, speaks both languages and handles the translation-coordination-verification stack described above. Built on existing protocol foundations — OpenADR for signaling, IEEE 2030.5 for DER assets, proprietary APIs for DCIM and BMS platforms — and able to fold in the emerging compute-flexibility tools rather than compete with them, assembled into an orchestration layer specific to data center flexibility. 

The organizations that solve this problem first — whether aggregators, data center operators or their technology partners — will define how the largest new source of grid load becomes the largest new source of grid flexibility.  

The physics and economics are aligned. The next step is making the software layer more interoperable, market-aware and scalable across the full data center flexibility stack. 

 

Spencer Borison is President of US Operations at Codibly, where he leads the company’s renewable energy practice focused on demand response, VPP platforms and grid integration software for energy technology companies and aggregators.

Published by

Spencer Borison

President of US Operations, Codibly

Spencer Borison

President of US Operations, Codibly

Skip to content