DeutschlandStack: Governance After the Fact?
Germany’s national technology stack promises digital sovereignty, but begins where most projects fail: with tools instead of governance.
The DeutschlandStack claims to become the backbone of state service provision in the digital era. Yet long before a governance framework is published, the official site already celebrates layer diagrams and technology landscapes. It is a curious order of priorities: infrastructure first, accountability later. Germany wants its public sector to be sovereign, interoperable, and efficient. The timing is apt, given the European Digital Identity initiative, the once-only principle, and the need for secure cross-border services. Nevertheless, the way this initiative begins reveals an old habit in a new guise. Transformation starts with tools before governance, with infrastructure before capability, with the how before the why. Across Europe, similar initiatives are emerging, from GovStack to EuroStack. All share the aspiration of digital sovereignty. Yet most still confuse the presence of open-source software with the presence of open governance. The result is predictable: a catalogue of technologies without a clear operating model.That is why the DeutschlandStack deserves a closer look, not because of what tools it contains but because of what it still leaves undefined. The heise online article “Deutschland-Stack: Rückgrat der staatlichen Daseinsvorsorge in der Digitalwelt” describes the initiative as the future backbone of Germany’s digital public services. It paints an ambitious picture of how the D-Stack could underpin digital identities, signatures, and payments. Two weeks later, another piece, “Deutschland-Stack: So soll die nationale souveräne Technologieplattform aussehen”, detailed the architecture’s structure and consultation process. Reading both articles makes one thing clear: the narrative remains technical first, governance later.
Starting from Tools Instead of Governance
The public site for the DeutschlandStack is neatly structured. It shows layers, technologies, and architectural visions. It highlights modularity, reuse, and open standards. The heise coverage frames the D-Stack as the backbone of the digital state, meant to ensure the basic digital functions of public service delivery. It mentions building blocks such as identity, payment, and signature services that should enable interoperability across agencies. In principle, that is exactly what a modern state needs. The newer article goes further, presenting a “landkarte” of the platform with six interlocking layers — from infrastructure to user-access — and a maturity model for included technologies. Consultation is open until the end of November. Yet the map shows only the technological terrain. There is no comparable landscape for governance, accountability, or decision-making. The blueprint for the tools exists; the blueprint for the rules does not. That is where the imbalance begins. Governance, in a project of this scale, is not a secondary topic. It is the first capability that must exist before any technology can be meaningful. A stack without governance is simply a collection of tools that happen to live in the same diagram. Both heise pieces already hint at the need for governance. They mention calls for a dedicated task force and a federated operating model coordinated through FITKO and the IT Planning Council. The recognition is there, but the structure is still missing.
A Capability Lens on the DeutschlandStack
Looking at the DeutschlandStack through the lens of Capability Thinking changes the perspective. A capability defines what an organisation must be able to do to deliver value. It is not about the specific tool used to do so. For government, these capabilities include verifying identity, enabling secure payments, sharing data across ministries, or ensuring compliance with data-protection law. These are the true building blocks of a digital public sector. Everything else, from APIs to infrastructure, exists to support them. The current documentation lists technology layers but not the capability map that ties them to policy outcomes. There is no visible structure showing who owns which capabilities, how they interact, or how success will be measured. That omission matters. Without it, the stack remains a technical artefact detached from its purpose.
Governance as the First Capability
Governance should not be treated as an afterthought. It is a capability in itself. The ability to coordinate, decide, and evolve collectively. In a federal system like Germany’s, governance is the hardest part. Each level, from federal to municipal, owns its own systems, budgets, and priorities. Aligning them requires more than a shared toolset. It requires a shared capability for decision-making and trust. If the DeutschlandStack begins with tools and leaves governance to evolve later, it risks repeating the same fragmentation it was created to overcome. Each level may adopt parts of the stack differently, creating new silos under the label of standardisation. The latest heise article notes that the stack will encompass strategic and organisational framework conditions alongside technology. Yet describing a framework is not the same as embedding one. The consultation still focuses mainly on technical standards and tool inclusion, which shows governance remains reactive rather than foundational.
API Thinking: Interactions Over Infrastructure
If Capability Thinking defines what government must be able to do, API Thinking defines how those capabilities connect. APIs are not just integration points. They are contracts between capabilities. They define how a digital identity service interacts with a licensing authority, how payment services link to public registers, or how compliance checks are automated. The DeutschlandStack promises interoperability, but the current narrative still reads like an infrastructure story rather than an interaction story. The question is not whether it runs on containers but whether it can express and evolve consistent APIs across organisations. That requires an API Strategy: a governance system for how APIs are designed, published, versioned, and reused across federal and state boundaries. There is no visible sign of that yet. Without it, reuse remains theoretical.
From Tools to Operations: The APIOps View
To understand what is missing, it helps to apply the APIOps Cycles method. It defines a continuous process for designing, delivering, and governing APIs as products. It begins with strategy, moves through design, delivery, publishing, audit, and improvement. It is not a checklist but a feedback loop. When this logic is applied to the DeutschlandStack, the gap becomes clear. The initiative has started in the middle of the cycle with delivery and architecture but skipped the earlier stages that define purpose and governance. There is no shared API Product Strategy for the public sector. No consistent consumer experience for agencies and states. No federated audit or improvement cycle. This is not a technical issue. It is a structural one. A stack that starts in the middle of the cycle cannot close the loop.
The Stack as a Capability System
The DeutschlandStack should be understood not as a set of components but as a capability system that connects technology, people, and governance. Each capability in particular identity, payments, messaging, consent, or data exchange should be clearly owned, described, and exposed through APIs. Each should have measurable maturity, adoption metrics, and defined ownership across levels of government. Once those are in place, the technical layers of the stack begin to make sense. Infrastructure becomes one enabling layer. The real value lies in defining and connecting the capabilities themselves. Governance then becomes the invisible API between ministries and states. It defines who may call what, under which conditions, and how the system evolves without breaking.
Federated Governance as an Operating Model
A national digital stack cannot be governed by a single committee. Governance has to be federated, distributed across roles and responsibilities that reflect how government actually operates. Team Topologies provides a useful metaphor. Platform teams maintain the core of the stack. Stream-aligned teams in ministries and municipalities build services on top. Enabling teams promote design standards and security practices. Complicated subsystem teams own specialised capabilities such as identity or payments. This is how federated systems stay coherent without becoming centralised. If the DeutschlandStack adopts this kind of role clarity early, it can avoid becoming just another central platform that others resist.
Ecosystem and Value Creation
Seen through Capability Thinking and API Thinking, the ecosystem around the DeutschlandStack looks different. It shifts the focus from vendors and tools to capability contributors.
Vendors contribute implementations of shared capabilities.
States and municipalities act as capability owners.
Citizens become capability beneficiaries.
Governance bodies act as capability enablers.
This reframing changes incentives. It also supports open participation. If capabilities and APIs are described transparently, smaller vendors and open-source communities can take part on equal terms. That is what digital sovereignty should look like. It is not about exclusion but about structured participation.
Governance as Code
To make this kind of system work, governance itself has to become operational. Policies cannot live only in PDFs. They need to be expressed as APIs, rules, and automated checks that systems can enforce. The APIOps Cycle supports this idea. Strategy and design translate policy into artefacts. Delivery and publishing bring them to life. Audit and improvement close the loop with evidence and feedback. Governance then becomes executable. It turns into a living capability that adapts over time.
What Happens If We Don’t Fix It
Without Capability Thinking, the DeutschlandStack risks turning into a list of technologies detached from the outcomes it was meant to deliver. Without API Thinking, it lacks the connective tissue that allows those capabilities to interact and evolve. Without APIOps, it has no mechanism for continuous learning and improvement. The result would be familiar: duplication, slow adoption, and loss of trust.
From Tool Catalogue to Capability Platform
If Germany truly wants to build a sovereign and reusable stack, the first layer should not be infrastructure but governance and capabilities. Start by mapping what the public sector must be able to do. Define those as capabilities. Expose them as APIs. Govern them through continuous APIOps Cycles. Then add the tools that make them work.Only in that order does the stack become more than a diagram.
Closing Reflection
The DeutschlandStack could indeed become an essential foundation for genuine interoperability and sovereignty in public services. But technology alone will not carry that promise. Real sovereignty begins with the ability to govern, evolve, and collaborate across federated levels of administration. It means starting with governance before code, with capabilities before tools, and with APIs before infrastructure. The uncomfortable truth is that digital sovereignty is not first a technical achievement but an organisational one. Until governments treat governance itself as a digital capability, every stack will remain a catalogue of tools, impressive on paper but hollow in practice.