Data Sovereignty Is Now an Architecture Question

How I stopped treating sovereignty as a legal problem

I remember conversations where 'data sovereignty' got the same treatment as a tax return. Unpleasant. Necessary. Someone else's problem. [ That was convenient. Also wrong. ERP Today put it plainly: data sovereignty is no longer about server location. It covers who runs the workloads, what technology dependencies you're creating, and what legal consequences follow from the whole arrangement. That's not a compliance checkbox. That's an architecture decision.

What sovereignty actually means today

The classic reflex: store data in Germany, done. That's too simple. According to ERP Today, data sovereignty now spans five dimensions — control over the data itself, over workloads, over who operates the infrastructure, over technology dependencies, and over the legal implications of the whole setup.

That sounds like a workshop afternoon. It isn't. These five dimensions regularly contradict each other in practice. Pick the cheapest hyperscaler option and you buy operational efficiency at the cost of operator independence. Go with a European provider and you solve the operator problem — but you may inherit technology dependencies that weigh just as heavily. No setup optimizes all five at once. That's the uncomfortable truth.

• •

  Data control: Who can access the data, even without explicit permission?

• •

  Workload control: Can processes be moved to different infrastructure at any time?

• •

  Operator independence: What rights does the vendor hold in a dispute?

• •

  Technology dependency: How deep is platform lock-in through proprietary APIs or formats?

• •

  Legal implications: Which jurisdiction applies when things get serious?

Why the SAP landscape is especially exposed

For many DACH enterprises, SAP is the central data platform. That's where sovereignty questions get sharpest. Migrating to SAP Business Technology Platform or S/4HANA Cloud is not a purely technical decision. It's a decision about which of the five sovereignty dimensions you're willing to partially give up.

That isn't automatically wrong. But it has to be a deliberate choice. Not an implicit one. Migrate to public cloud without first clarifying which data lands there and under what conditions, and you've still made the decision — you just didn't notice. That's exactly when architects need to be in the room. Before the contract is signed. Not after.

SAP systems rarely stand alone. They're embedded in an ecosystem of middleware, third-party systems, and interfaces. Every connection is a potential sovereignty leak. If you don't see the full picture, you can't assess the individual parts.

What this means for governance decisions

Governance frameworks in DACH enterprises are often historically grown. They define who gets data access, how data is classified, what needs to be documented for an audit. What they rarely define: the architecture dimension of sovereignty. Specifically, which technology decisions need to enter the governance process at all — and which ones quietly bypass it.

That's a structural gap. It won't close with a new policy document. It closes when architecture reviews explicitly include sovereignty criteria. Concretely: every new platform decision, every third-party interface, every cloud extension should be assessed against the five dimensions. Not as bureaucracy. As risk assessment.

Do that systematically and you'll quickly find that many past decisions were made implicitly. That's not a criticism of the people who made them. The framework wasn't there. Building it now isn't a sign of weakness. It's overdue.

Three starting points for architects and IT leaders

If you want to start now without opening a major project, three concrete steps will do. They're not spectacular. But they create clarity before the next platform decision lands on the table.

• •

  Map your operator structure: Which systems run with which vendor, under which jurisdiction, with what contractual access rights?

• •

  Add sovereignty dimensions to existing architecture review checklists: Not as a separate project — as an extension of the process already running.

• •

  Identify critical dependencies: Which systems would be hardest to migrate if you needed to switch vendors — and why?

What I'm taking away — and what's still open

The most important shift for me is this: data sovereignty has stopped being a legal topic and become an architecture topic. That means architects and IT leaders are taking on responsibility that used to sit elsewhere. Not always comfortable. Still right.

What I don't have a good answer for yet: how do you quantify technology dependency? Migration costs can be estimated. The cost of a weakened negotiating position against a hyperscaler is harder to put a number on. I'm still working through that. If you have concrete approaches, I'm genuinely curious.

Sources

This draft was written with AI assistance from the reports below and requires editorial review before publication.

• •

  ERP Today