Architekturprinzipien
Erstellt am: 12. März 2026 | Zuletzt geändert: 13. Mai 2026 | Autor: Matthias, Enrico (GitLab)
Ziel des Dokuments: Dieses Dokument definiert die verbindlichen Kernprinzipien, an denen sich sämtliche Architektur- und Designentscheidungen im Rahmen des BMDS und des D-Stacks orientieren müssen. Sie gelten übergreifend für alle Referenzarchitekturen und sind die maßgeblichen Designrichtlinien.
Die Architekturprinzipien der Deutschland-Architekturfeedback
Im Rahmen des Vorprojekts Deutschland-Architektur (DA) wurden zehn Architekturprinzipien für den D-Stack definiert und vom IT-Planungsrat beschlossen (IT-PL-Beschluss 2026/04, Anlage 1). Diese Prinzipien sind entscheidungsleitend für alle Architekturarbeiten und konkretisieren die Vorgaben der Nationalen IT-Architekturrichtlinie im Kontext der digitalen Verwaltung.
| Prinzip | Erläuterung |
|---|---|
| API-first | Programmierschnittstellen (APIs) werden von Anfang an als zentrale Elemente der Lösungsarchitekturen konzipiert und spezifiziert. Technische API-Zugriffe werden stets gegenüber manuellen Zugriffen bevorzugt. |
| Serviceorientierung & lose Kopplung | Dienste (Services) sind zentrale Architekturbausteine, die Funktionen bündeln. Sie und ihre Lösungsbausteine sind modular konzipiert, weitgehend unabhängig austauschbar und klar abgegrenzt. |
| Wiederverwendbarkeit & Portierbarkeit | Architekturelemente und bereitgestellte IT-Lösungen sind weitgehend wiederverwendbar und leicht in andere fachliche und technische Kontexte portierbar. |
| DevSecOps Only | Die Entwicklung, die Sicherheit und der Betrieb von IT werden als integrierter Prozess betrachtet. Lösungen der D-Architektur verfolgen einen „Secure by Design"-Ansatz von Beginn an. |
| Zero-Trust | Lösungsbausteine müssen vollständig kompatibel mit Zero-Trust-Architekturen sein. |
| Technologisch aktuell | Der aktuelle Stand der Technik ist bestimmend für Architekturentscheidungen. |
| Made in EU first | Zur Stärkung der digitalen Souveränität setzt die Deutschland-Architektur auf Produkte aus EU-Ländern. |
| Prefer Reuse over Buy over Make | Sofern noch keine nachnutzbaren Angebote existieren, sollen bevorzugt Standardprodukte beschafft werden. Die Nutzung und Förderung von Open-Source-Lösungen werden stets vorgezogen. |
| Ende-zu-Ende-Digitalisierung | Der Standard-Verwaltungsprozess ist digital und über Organisationsgrenzen hinweg optimiert: Verwaltungskunden im Fokus, Medienbrüche vermeiden, Automatisierungspotenziale nutzen. |
| Managed Services Only | Die Nutzung bestehender, zentral gemanagter IT-Dienste ist stets zu bevorzugen, um Effizienz, Sicherheit, Verfügbarkeit und Skalierbarkeit zu erhöhen. |
Neben diesen Prinzipien gelten alle Vorgaben der Nationalen IT-Architekturrichtlinie im dort vorgeschriebenen Verbindlichkeitsgrad (kann/soll/muss). Die DA-Prinzipien wurden auf die OZG-Rahmenarchitektur und die Föderale IT-Architekturrichtlinie gemappt (siehe IT-PL-Beschluss 2026/04, Abschnitt 3.2).
Ergänzende Prinzipien (in Anlehnung an GovStack)feedback
Ergänzend zu den DA-Prinzipien orientiert sich der D-Stack an den 9 High-Level Architecture Principles von GovStack. Diese internationalen Leitlinien wurden auf den spezifischen Kontext des BMDS, des ITZBund und deren Behördenkunden zugeschnitten. Die folgende Auswahl hebt Aspekte hervor, die über die DA-Prinzipien hinausgehen:
-
Offenheit und Neutralität (Openness & Neutrality) Konsequente Bevorzugung von Open-Source-Lösungen zur Vermeidung von Vendor-Lock-in. Insbesondere auf der High-Level-Architekturebene und in fachlichen Spezifikationen gilt das Prinzip der Herstellerunabhängigkeit (Vendor-Agnosticism). Diese müssen stets anbieterneutral dokumentiert sein; konkrete Herstellerprodukte (Vendor Solutions) dürfen nur als Implementierungsbeispiele oder in den detaillierten Betriebsvorgaben referenziert werden.
-
Robustheit, Skalierbarkeit & Performance (Sustainability & Robustness) Die Plattformen müssen horizontale sowie vertikale Skalierung unterstützen, um Lastspitzen und SLAs der Fachverfahren hochverfügbar abzufangen. Dem Abbau von technischen Schulden und der Sicherstellung verlässlicher Antwortzeiten (Performance) wird hohe Priorität eingeräumt.
-
Wartbarkeit und Observability (Observability & Maintainability) D-Stack-Lösungen müssen Observability (Logging, Monitoring, Tracing) von Beginn an implementieren. Das ermöglicht einen kosteneffizienten Betrieb, einfache Fehlerdiagnosen und reibungslose Übergaben zwischen Entwicklerteams.
-
Datensouveränität und Portabilität (Data Ownership & Portability) Bürger:innen und Behörden müssen jederzeit die volle Hoheit und Kontrolle über ihre Daten behalten. Daten müssen portabel sein und Datensilos sind architektonisch zu vermeiden (Federated Data).
-
Nutzerzentriertes Design (User-Centered Design) Architekturentscheidungen müssen Inklusivität, Usability und Barrierefreiheit für verschiedene Nutzergruppen (Bürger, Unternehmen, Verwaltungsmitarbeiter) über alle Kanäle hinweg unterstützen.
-
Policy as Code Governance-Vorgaben, Berechtigungen und Compliance-Regeln (wie Zero-Trust-Policies) sind wo immer möglich maschinenlesbar umzusetzen. Das erhöht die Transparenz, ermöglicht konsistente Validierung und automatisierte Deployments.
Anwendung in der Praxisfeedback
Alle Prinzipien sind nicht isoliert zu betrachten, sondern müssen im Zusammenspiel geprüft werden. Eine hochskalierbare, aber verschlossene Closed-Source-Architektur erfüllt die D-Stack-Kriterien ebenso wenig wie ein prinzipientreues, aber unwartbares System.
Konsistente Architekturarbeit im Behördenumfeld erfordert die Einhaltung von drei eng miteinander verbundenen Leitpfeilern.
Verwendung bewährter Muster bedeutet, dass Lösungsdesigns grundsätzlich auf etablierten, in der Praxis erprobten Architekturmustern (z.B. Cloud-Native, Microservices) aufbauen. Die Einführung proprietärer oder experimenteller Muster ohne nachgewiesenen Mehrwert und klares Risikomanagement ist zu vermeiden, um die langfristige Wartbarkeit und die Übernahmefähigkeit durch Dritte zu sichern.
Konsistenz über Module hinweg stellt sicher, dass Schnittstellen (APIs), Datenmodelle und Kommunikationsmuster projekt- und teamübergreifend einheitlich definiert und dokumentiert werden. Nur so kann die Interoperabilität zwischen verschiedenen Behördenkomponenten der DVC und des D-Stacks dauerhaft gewährleistet werden. Hierbei ist auf die Kompatibilität mit den EU Digital Building Blocks zu achten.
Dokumentation und Nachvollziehbarkeit ist eine Pflicht, keine Option. Alle signifikanten Architekturentscheidungen sind in Form von Architecture Decision Records (ADRs) festzuhalten. Schnittstellen sind maschinenlesbar (OpenAPI) und menschenlesbar zu dokumentieren. Die Einhaltung der hier definierten Richtlinien sowie der Lizenz- und Contribution-Vorgaben ist für alle im Repository verwalteten Inhalte verbindlich.
Ergänzende regulatorische Anforderungen finden sich im Bereich Datenschutz sowie bei den Sicherheits- und Compliance-Standards.