Over the past two months in this space, I have argued two things. First, that SAP’s Autonomous Enterprise vision is the right move for utilities because it puts governance, security, and performance at the foundation rather than treating them as afterthoughts. Second, that the autonomous enterprise forces us to rethink who actually secures an enterprise where software agents do the work. Both arguments rested on an assumption I did not examine closely enough—and several of you, rightly, called it out: all of that governance and security machinery presumes the agent is reasoning over data worth trusting.

It is the question underneath both of the others, and it belongs squarely in the category I have been calling the questions we aren’t asking: when an agent closes a work order, recommends a switching plan, or proposes a rate adjustment, what exactly is it reading—and can we vouch for it?

SAP’s own utilities leadership has been blunt about the stakes. The message from Sapphire and the months since has been consistent: if your data is siloed or inconsistent, agentic AI will not merely underperform—it will hallucinate and act confidently on what it invents. A governance seal cannot catch that. A SOC cannot detect it. The data foundation is the foundation under the foundation, and for utilities it now has a name: SAP Business Data Cloud.

What BDC Actually Is—and Isn’t

SAP Business Data Cloud is not a new data lake into which we migrate everything. It is a governed fabric that unifies SAP Datasphere, SAP Analytics Cloud, and an embedded edition of Databricks around a single currency: the data product. A data product is a predefined, self-describing, read-only dataset that carries its business semantics and metadata with it. For S/4HANA, these products are built on the same ABAP Core Data Services (CDS) views that already define the system’s analytical model, and they announce themselves to a central catalog through SAP’s Open Resource Discovery protocol.

That last detail matters more than it appears. The reason an agent can be trusted to read BDC data is that the data arrives pre-described—with lineage, semantics, and governance attached—rather than as anonymous rows the agent must guess about. This is the mirror image of a point I made in the security article: there, I argued that process atoms give us the unit of least privilege for scoping what an agent may do. Data products are the parallel on the other side—the unit of trusted data an agent is permitted to read. Authority and data, scoped with the same discipline.

The Architecture to Understand Before You Plan

Two things belong in every utility data architect’s head before scoping a BDC initiative.

First, there are two object stores, not one. SAP-managed data products live in the Foundation Services object store, which SAP manages end to end and which is not directly accessible to users. Customer- and partner-built data products live in the SAP Datasphere object store. Both sit on SAP HANA Cloud Data Lake underneath, but the governance boundary between them is real: to consume an SAP-managed product, you install it into Datasphere or into the embedded Databricks. Datasphere—which many of us first met as a standalone BTP service—is now the workbench inside BDC where that consumption and modeling happens.

Second, and this reframes the entire migration conversation, BDC’s default sharing mechanism is Delta Sharing: an open, zero-copy protocol. Data is not necessarily moved or duplicated; it is shared in place and queried where it lives. HANA Cloud can consume a data product for CDS views, calculation views, and CAP applications without replication. External Databricks, SAP Analytics Cloud, and any client that speaks Delta Sharing can do the same.

Why This Changes the Migration Story

For a decade, many of us built the same pattern: replicate SAP data out into BW, data marts, and cloud data lakes, then run read-only analytics on the copy. The reflex when BDC arrives is to ask, “how do we migrate our data lake into it?” That is the wrong first question.

Because Delta Sharing is zero-copy, the real exercise is not migration but triage—deciding, data product by data product, what to federate in place, what to physically replicate, and what to leave exactly where it sits. SAP has made the data-lake on-ramp concrete: Datasphere can now replicate Parquet files directly from AWS S3, Azure Data Lake, and Google Cloud Storage, so the lakes we already run can feed BDC without a bespoke ETL layer. Some utilities got a head start here, having stood up Datasphere while it was still a BTP service; that work largely carries forward as Datasphere settles into its role within BDC.

The measured posture, then, is not a big-bang lift. It is a phased program: identify the highest-value SAP-managed data products first, share rather than copy wherever the read pattern allows, and reserve physical replication for the cases that genuinely require it.

The Discipline a Methodical Utility Will Bring

A phased posture is not merely prudent—it is how both the economics and the architecture reward you. Two principles should shape any utility’s plan.

First, size the entry deliberately. Standing up the governed object store is a real commitment, and the right-sized footprint for a utility proving the concept is rarely the footprint a vendor reference architecture assumes. Establish value on a contained, well-scoped slice before scaling the environment—and put the entry economics in front of leadership early, especially at a cooperative or municipal utility watching every dollar.

Second, sequence from the source outward. Lead with the source-aligned SAP data products that arrive governed and pre-described, and layer your own custom shaping on top once those foundations are proven. Building bespoke models first and then trying to graft governance onto them inverts the very advantage BDC offers.

Neither principle is a reason to wait. They are reasons to plan with eyes open, which has always been our community’s strength.

Data Products as Audit Evidence

There is a governance dividend hiding in this architecture that our compliance teams should notice. Because a data product is self-describing and carries its own lineage and semantics, it is inherently more auditable than a hand-built replication job whose transformations live in one engineer’s tribal knowledge. When a NERC CIP audit or a rate-case discovery request asks where a number came from and who could touch it along the way, a governed data product with documented lineage is a far better answer than “let me find the person who wrote that data flow.” The same instinct that drove the security argument applies here: governed, documented, and inspectable beats fast and undocumented every time a regulator is in the room.

The Customer-Data Question Is Its Own Article

There is one domain where the data-foundation question gets especially thorny for utilities, and it deserves more room than a single section: the customer. Our customer data is scattered across IS-U or S/4HANA Utilities, CRM, the web channel, the contact center, and a thicket of program-enrollment and third-party systems—and the rise of consumption-to-creation prosumers, dynamic tariffs, and DER participation only raises the stakes on getting it unified and clean. SAP’s answer there runs through a different and frequently misunderstood set of tools, and conflating them with the analytical foundation does justice to neither. I will take that up directly in the next Utility Voice.

The Honest Caveats

Embracing BDC as the data foundation does not mean embracing it uncritically. Three caveats deserve daylight.

First, BDC is a young platform moving fast. Capabilities, tooling, and even the capacity economics are evolving release to release. Our community has learned the discipline of distinguishing announced from delivered from adopted; apply it here as rigorously as anywhere.

Second, BDC does not clean your data for you. Governed data products improve discoverability, lineage, and trust, but they inherit the quality of their sources. A data product built on a flawed business-partner record is a well-governed conduit for a bad number. Master data remediation remains our work—and it remains a prerequisite, not a byproduct.

Third, watch the commercial model. The capacity-unit floor is one signal; the broader question is how SAP prices data products, sharing, and embedded Databricks consumption over time. We should press for pricing that does not penalize the very phased, prove-it-first approach SAP itself recommends.

What We Still Need to Influence

Right-sized entry tiers: Entry-cost economics can put a careful, low-risk pilot out of reach for smaller utilities. We need a development and proof-of-concept tier that lets a co-op or municipal utility validate BDC without an enterprise-scale commitment.
A supported path for custom models: We need clear, documented, well-supported paths for staging our own custom data products alongside the SAP-managed catalog—and clarity on SAP’s roadmap for lighter-weight tooling and entry options.
Utility data product coverage: The value of the SAP-managed catalog depends on whether it includes the products utilities actually need—IS-U, meter-to-cash, asset and plant maintenance, and the operational adjacencies. We need SAP’s utility data product roadmap made explicit.
Lineage and evidence standards for regulators: We should ask SAP to document how data product lineage maps to NERC CIP evidence and rate-case discovery expectations, so each utility is not building that translation alone.
OT data boundaries, again: As in the security discussion, our SCADA, ADMS, and OMS data live outside SAP’s perimeter but inside the analyses agents will run. We need explicit guidance on how operational data participates in—or is deliberately walled off from—the BDC fabric.

A Call to Our Community

Two months ago I asked whether you had a better governance answer than SAP’s. Last month I asked whether you could tell your regulator who secures your agents. This month the question is quieter but no less important: can you tell that same regulator—and your own operators—that the data your agents read is governed, current, and traceable to a source you trust?

If the answer is not yet, that is not a reason to hold back. It is the work in front of us, and BDC gives it a shape it did not have a year ago. A governed fabric built on self-describing data products. A zero-copy sharing model that turns a daunting migration into a series of deliberate choices. An on-ramp for the data lakes we already run. And a lineage story our auditors and regulators can stand behind.

An agent’s judgment will only ever be as good as the data beneath it. Securing the autonomous enterprise was the precondition for letting agents act. Trustworthy data is the precondition for letting them be right. The utilities that build that foundation deliberately—product by product, source by source—will be the ones whose agents earn the trust we are about to place in them.

Next month: the customer data problem, and why the tools meant to solve it are the most misunderstood corner of SAP’s portfolio. To get involved and keep up with the latest, https://utility.community/all-subscriptions/