Deutschland-Stack und Deutschland-Architektur: Was der Beschluss des IT-Planungsrats konkret bedeutet und welche Fragen er aufwirft.
Ein vertrautes Bild und warum es sich gerade verändert
Ein Team in einer Behörde sitzt zusammen und bereitet eine neue Ausschreibung vor. Irgendwann kommt die Frage auf: Müssen wir FIT-Connect einbinden? Gilt API-First jetzt verbindlich? Welche Cloud-Umgebung ist noch zulässig? Die Antworten fallen unterschiedlich aus, je nachdem, wen man fragt. Der Rechtsrahmen sagt das eine, die Beschlusslage des IT-Planungsrats das andere, und die IT-Architekturrichtlinie des Bundes folgt nochmals einer eigenen Logik.
Dieses Bild ist nicht untypisch. Die Digitalisierung der deutschen Verwaltung ist seit Jahren in Bewegung – doch sie verläuft oft unkoordiniert. Bund, Länder und Kommunen haben parallel entwickelt, beschafft und betrieben: mit unterschiedlichen Architekturen, unterschiedlichen Standards und ohne ein gemeinsames Zielbild, das über politische Absichtserklärungen hinausgeht.
Genau das ändert sich jetzt mit den Beschlüssen des IT-Planungsrats zu Deutschland-Stack (D-Stack) und Deutschland-Architektur. Erstmals liegt ein verbindlicher, föderal abgestimmter Ordnungsrahmen vor, der ausdrücklich kein weiteres Strategiepapier ist, sondern ein operatives Regelwerk mit Weisungscharakter. Was das konkret bedeutet, welche Fragen es beantwortet und welche es neu aufwirft, beschreibt dieser Beitrag.
Zwei Konzepte – eine gemeinsame Logik
Wer die aktuelle Debatte verfolgt, stößt schnell auf zwei Begriffe, die häufig im gleichen Atemzug genannt werden, aber selten sauber voneinander abgegrenzt sind: der Deutschland-Stack und die Deutschland-Architektur. Wer diese Begriffe verwechselt, verliert in der Projektsteuerung schnell den Faden.
Der Deutschland-Stack: Konkrete Bausteine für die Verwaltungspraxis
Der D-Stack ist die Sammlung zentraler IT-Produkte und -Plattformen, die der Bund für Bund, Länder und Kommunen bereitstellt.
Er gliedert sich in vier Ebenen:
- Auf der Grundebene liegen die Basisdienste:
- digitale Identität über eID und die künftige EUDI-Wallet
- Datenaustausch über FIT-Connect
- automatisierter Nachweisabruf über NOOTS
- Zahlungsabwicklung sowie ein zentrales Bürgerpostfach
- Darüber liegen fachlich neutrale Plattformen: KI-Dienste, eine Low-Code-Umgebung für Workflows sowie ein Marktplatz für digitale Verwaltungsleistungen.
- Die Infrastrukturebene umfasst die Deutsche Verwaltungscloud als Multi-Cloud-Umgebung sowie die Open-Source-Plattform openCode.
- Der Zugang für Bürgerinnen und Bürger erfolgt über das Bundesportal und die Deutschland-App.
Aus technischer Sicht lässt sich der D-Stack in Identitäts-, Integrations-, Plattform-, Zugangs- und Entwicklungsdienste gliedern.
Für Projekte ist diese Unterscheidung relevant, weil sich daraus unterschiedliche Integrationspflichten ergeben. Ein Fachverfahren muss andere Nachweise für die Nutzung eines zentralen Transportdienstes erbringen als für die Einbindung eines Identitätsdienstes oder den Betrieb auf einer föderierten Cloud-Plattform.
Entscheidend ist, dass der Stack kein neues Einzelprodukt ist. Er ist die technologische Grundordnung, auf der künftige Verwaltungsprozesse aufsetzen sollen. Zudem legt er fest, welche Bausteine zentral bereitgestellt sind und damit nicht mehr individuell entwickelt werden müssen.
Die Deutschland-Architektur: Der Rahmen, der den Stack zusammenhält
Während der Stack festlegt, was gebaut wird, definiert die Deutschland-Architektur den verbindlichen Bauplan für die Umsetzung. Sie definiert die Spielregeln nach welchen Prinzipien Architekturentscheidungen getroffen werden, welche Standards verbindlich gelten, welche Bausteine wiederverwendet werden sollen, und was nicht mehr neu entwickelt werden darf, wenn eine geeignete Lösung bereits existiert.
Technisch handelt es sich um die Enterprise-Architektur der gesamten deutschen Verwaltung, entwickelt nach dem international etablierten TOGAF-Standard. Sie umfasst zehn Architekturprinzipien, ein wachsendes Portfolio an Funktionsbausteinen und einen Governance-Rahmen, der den Umgang mit der Architektur über föderale Ebenen hinweg regelt.
Wichtig dabei ist, dass die Architektur keine Produktentscheidungen trifft. Sie legt lediglich fest, was eine Lösung können muss, ohne daseinzusetzende Produkt vorzugeben. Das schafft Raum für föderale Ausprägungen und wahrt zugleich die gemeinsame Linie.
Kurz gefasst: D-Architektur ist der Bauplan. D-Stack ist das, was tatsächlich gebaut wird. Beide bedingen einander – aber sie spielen unterschiedliche Rollen in der Umsetzung.
Was die Beschlusslage konkret verändert – eine nüchterne Einschätzung
Der Beschluss des IT-Planungsrats markiert einen echten Einschnitt, weil den bekannten Inhalten erstmals verbindliche Wirkung zukommt. Fünf Aspekte verdienen dabei besondere Aufmerksamkeit.
Verbindlichkeit entsteht nicht durch Beschluss allein
Ein Ordnungsrahmen mit Weisungscharakter ist das eine. Entscheidend ist, ob er in der operativen Praxis ankommt, etwa in Leistungsverzeichnissen, Architektur-Reviews und Beschaffungsentscheidungen. Erfahrungsgemäß klafft hier eine Lücke. Standards werden beschlossen und in Strategiepapieren zitiert. In konkreten Projektdokumenten tauchen sie jedoch oft erst mit Verzögerung auf, wenn überhaupt. Die eigentliche Herausforderung liegt nicht im Beschluss selbst, sondern in seiner Übersetzung in die Projektpraxis.
Kommunale Anschlussfähigkeit ist die ungelöste Kernfrage
Ein bundesweiter Architekturrahmen funktioniert nur, wenn er auch die letzte Meile erreicht. Viele Kommunen verfügen weder über eigene Architekturkapazitäten noch über die personellen Ressourcen, um einen solchen Rahmen selbstständig umzusetzen. Das ist kein Vorwurf, sondern eine strukturelle Realität, die bei der Ausgestaltung des Stacks berücksichtigt werden muss. Technische Anschlussfähigkeit ist das eine; operative Durchführbarkeit auf kommunaler Ebene ist eine andere Frage.
Souveränität braucht mehr als ein EU-Label
Das Prinzip „Made in EU first“ ist eines der zehn Architekturprinzipien und die Intention dahinter nachvollziehbar. Ein europäischer Anbieter ist jedoch keine hinreichende Bedingung für souveräne Architektur. Entscheidend sind offene Schnittstellen, echte Datenportabilität und belastbare Exit-Optionen. Die Architektur muss das sicherstellen, unabhängig davon, woher der Anbieter kommt. Das ist eine Anforderung, die noch operationalisiert werden muss.
Einige Bausteine sind bereits heute nutzbar
Nicht alles im Stack ist nur Zukunftsmusik. FIT-Connect steht als Datentransportweg bereit und wird noch zu selten flächig eingesetzt. NOOTS schafft die Grundlage für automatisierten Nachweisabruf. Es setzt allerdings voraus, dass Datenhoheit und rechtliche Grundlagen vorab geklärt sind. Die Deutsche Verwaltungscloud definiert ein Betriebszielbild, das für neue Fachverfahren bereits heute maßgeblich sein sollte. Wer diese Bausteine jetzt nicht in die eigene Planung einbezieht, steht später unter erhöhtem Migrationsdruck.
Die Architekturprinzipien haben Governance-Charakter – und das ist ernst gemeint
Die zehn Prinzipien, zu denen unter anderen API-First, Zero Trust, integrierte Sicherheit über den gesamten Entwicklungszyklus und die Präferenz für bestehende Lösungen vor Neuentwicklungen gehören, sind nicht als Leitlinien im weichen Sinne formuliert. Sie sind Entscheidungsregeln. Projekte, die ohne API-Konzept, ohne nachvollziehbare Sicherheitsarchitektur oder ohne Prüfung bestehender Nachnutzungsmöglichkeiten starten, bewegen sich künftig außerhalb des definierten Rahmens und müssen entsprechend begründet werden.
In der Projektpraxis bedeutet das, dass Architekturprinzipien in Artefakte übersetzt werden müssen. API-First ist erst dann wirksam, wenn für relevante Schnittstellen vor Implementierungsbeginn ein versioniertes API-Design, ein Authentisierungskonzept, ein Fehler- und Logging-Modell sowie Regeln für Betrieb und Entkopplung vorliegen. Zero Trust bleibt folgenlos, wenn nicht definiert ist, wie Maschinenidentitäten, Netzsegmentierung, Service-Authentisierung und revisionsfeste Protokollierung umgesetzt werden.
Was der Rahmen ermöglicht – wenn man ihn konsequent nutzt
Ein verbindlicher Ordnungsrahmen ist zunächst eine Anforderung. Er ist aber auch eine Chance, vorausgesetzt, er wird nicht als bürokratische Hürde verstanden, sondern als Grundlage für bessere Architekturentscheidungen.
Der Nutzen entsteht nicht allein durch Wiederverwendung, sondern durch klare Standards an den richtigen Stellen: einheitliche Identitätsanbindung, definierte Transport- und Austauschmuster, wiederverwendbare Sicherheits- und Logging-Bausteine sowie verbindliche Betriebsstandards. Erst wenn diese Querschnittsfunktionen zentralisiert werden, sinken Integrationsaufwand, Testaufwand und Betriebsrisiko tatsächlich. Einheitliche Schnittstellen machen Systeme vergleich- und prüfbar. Zentrale Basisdienste verkürzen Projektlaufzeiten, wenn sie konsequent eingesetzt werden. Eine gemeinsame Architektursprache erleichtert die Koordination über föderale Ebenen hinweg – ein Punkt, der in verteilten Vorhaben regelmäßig unterschätzt wird.
Hinzu kommt die außenpolitische Dimension. Mit den Anforderungen des Single Digital Gateway und dem Once-Only-Prinzip auf EU-Ebene wächst der Druck, Interoperabilität nicht nur innerhalb Deutschlands, sondern auch grenzüberschreitend sicherzustellen. Eine national abgestimmte Architektur ist dafür die Voraussetzung.
Realistisch betrachtet heben sich diese Chancen nicht von selbst. Sie setzen voraus, dass Behörden und ihre Partner den Rahmen aktiv nutzen. Entscheidend ist, dass das nicht erst infolge einer externen Prüfung erfolgt. Wer diesen Schritt nicht geht, wird feststellen, dass Insellösungen und Integrationsprobleme auch unter einem neuen Ordnungsrahmen weiter entstehen. Künftige Abweichungen sind dann begründungspflichtig.
Was wir in der Praxis beobachten
Wir maßen uns keine Empfehlungen an, wie die Verwaltung den Beschluss umzusetzen hat. Was wir beschreiben können, sind Muster, die uns in Projekten regelmäßig begegnen und die zeigen, wo Reibung zwischen Architekturanspruch und Umsetzungsrealität tatsächlich entsteht.
Die Lücke zwischen Beschluss und Leistungsverzeichnis
Der Beschluss ist klar, die Implikationen für Vergabeprozesse sind es noch nicht. Aus früheren Erfahrungen – mit der OZG-Rahmenarchitektur und der föderalen IT-Architekturrichtlinie – kennen wir jedoch das Muster. Standards werden beschlossen und in Strategiepapieren zitiert. In konkreten Leistungsverzeichnissen tauchen sie, wenn überhaupt, oft erst mit erheblicher Verzögerung auf. Welche Architekturvorgabe gilt für welches Vorhaben in welcher Verbindlichkeitsstufe? Diese Übersetzungsarbeit entsteht selten von selbst.
Ein erster Schritt aus unserer Projekterfahrung zeigt, dass bestehende Leistungsverzeichnis-Vorlagen und Musteranforderungen frühzeitig, noch bevor die nächste Ausschreibung ansteht, gegen die neuen Architekturprinzipien gegenlesen werden sollten. Das schafft Klarheit darüber, wo Anpassungsbedarf besteht, und verhindert, dass Projekte mit veralteten Anforderungsprofilen starten.
Governance kostet mehr Zeit als Technik
Was Vorhaben verzögert, ist selten die technische Integration. Es ist die Frage, wer was auf welcher Ebene entscheidet. Wer pflegt Parametrisierungen und hält sie aktuell? Wer steuert den Roll-out auf kommunaler Ebene? Diese Fragen entstehen nicht erst in der Umsetzung – sie sind von Anfang an da. Nur werden sie zu selten am Anfang gestellt.
Ein erster Schritt: Governance-Fragen explizit in die Projektinitialisierung aufnehmen, am besten als eigenen Tagesordnungspunkt im Kick-off, nicht als nachgelagerte Klärung. Wer am Anfang drei Stunden in Rollenklarheit investiert, spart sie später mehrfach ein.
Kommunen starten mit einer anderen Ausgangslage
Der D-Stack setzt implizit voraus, dass bestimmte Grundlagen vorhanden sind: Betriebsplattformen, Architekturverantwortung, Kapazitäten für kontinuierliche Weiterentwicklung. Auf kommunaler Ebene scheitert dies häufig an begrenzten personellen und finanziellen Ressourcen und nicht am fehlenden Willen. Das ist ein strukturelles Problem, das sich nicht durch bessere Dokumentation lösen lässt.
Ein erster Schritt: Kommunen, die Stack-Bausteine einführen wollen, brauchen keine vollständige Digitalisierungsstrategie als Voraussetzung. Vielmehr brauchen sie eine belastbare Antwort auf die Frage, wer den Betrieb verantwortet und wer bei Problemen reagiert. Dieses Betriebskonzept vor der technischen Einführung zu klären, ist in unserer Erfahrung der entscheidende Unterschied zwischen Piloten, die skalieren, und solchen, die es nicht tun.
Bestandssysteme sind der blinde Fleck
Die Architekturdebatte dreht sich überwiegend um Neuentwicklungen. Der größte Teil der tatsächlich betriebenen Verwaltungs-IT ist jedoch Bestand, der oft über Jahrzehnte gewachsen, heterogen dokumentiert und in bestehende Betriebsprozesse eingebettet ist. Migrationspfade für Legacysysteme sind im Rahmenwerk der Deutschland-Architektur noch weitgehend offen. Das ist keine Kritik am Vorprojekt, das sich bewusst auf einen spezifischen Wertstrom konzentriert hat. Gleichwohl ist es eine Lücke, die in der Praxis schnell spürbar wird.
Ein erster Schritt: Eine nüchterne Bestandsaufnahme der eigenen Systemlandschaft ist Voraussetzung für eine realistische Migrationsplanung. Die folgenden Fragestellungen dienen als Richtlinie : Welche unserer Kernsysteme berühren die Basisdienste des Stacks direkt? Wo bestehen Abhängigkeiten zu FIT-Connect, NOOTS oder der Authentifizierungsinfrastruktur?
Souveränität wird erklärt, selten operationalisiert
Das Prinzip europäischer Bevorzugung ist politisch gesetzt. Was in Projekten fehlt, ist eine nachvollziehbare Prüflogik: Welche Kriterien entscheiden, ob eine Lösung als hinreichend souverän gilt? Offene Schnittstellen, Datenportabilität, Auditierbarkeit, Exit-Fähigkeit – das sind die relevanten Dimensionen. Sie müssen jedoch in Beschaffungskriterien und Architektur-Reviews übersetzt werden, bevor sie wirksam werden.
Ein erster Schritt: Souveränität als Prüfkategorie mit konkreten Anforderungen und messbaren Kriterien in den Beschaffungsunterlagen und nicht als Freitextfeld verankern. Wir arbeiten in Projekten mit einem überschaubaren Fragenkatalog, der genau das leisten soll: Kann der Auftraggeber Daten jederzeit exportieren? Sind Schnittstellen offen dokumentiert? Gibt es einen definierten Abkündigungsprozess? Wer diese Fragen stellen kann, führt bessere Beschaffungsgespräche.
Unsere Rolle in diesem Prozess
Wir sind IT-Dienstleister und IT-Berater von Bundes- und Landesverwaltungen sowie öffentlichen IT-Dienstleistern. Unsere Rolle beginnt dort, wo die Beschlüsse auf konkrete Vorhaben treffen. Und das ist meistens komplizierter, als es die Beschlussdokumente nahelegen.
Was wir mitbringen, ist Erfahrung an dieser Schnittstelle: zwischen dem, was föderal vereinbart wird, und dem, was in einem konkreten Projekt umsetzbar ist. Das bedeutet manchmal, bestehende Anforderungsprofile auf ihre Kompatibilität mit dem neuen Rahmen zu prüfen. Es bedeutet auch, Architekturfragen früh zu stellen und zwar dann, wenn sie noch Gestaltungsfreiheit eröffnen, nicht erst, wenn die technischen Entscheidungen gefallen sind. Und es bedeutet manchmal auch, unbequeme Fragen zu stellen, beispielsweise, ob ein geplantes System wirklich stackkonform ist, ob die Betriebsumgebung dem entspricht, was künftig erwartet wird und ob eine Beschaffungsentscheidung in drei Jahren noch vertretbar ist?
Wir verstehen uns dabei nicht als Kontrollinstanz, sondern als Partner für die Übersetzungsarbeit. Der Ordnungsrahmen ist gesetzt. Wie er in einem konkreten Vorhaben zum Tragen kommt, bleibt im Einzelfall offen – und genau dort setzen wir an.
