Zum Hauptinhalt springen

Nationale IT-Architekturrichtlinie

Erstellt am: 16. März 2026 | Zuletzt geändert: 16. März 2026

Ziel des Dokuments: Dieses Dokument mappt die übergreifenden Vorgaben aus der Nationalen IT-Architekturrichtlinie des IT-Planungsrates auf die konkreten Prinzipien, Bausteine und Referenzarchitekturen des EAM-Portals und des D-Stacks.

info Einordnung der Nationalen IT-Architekturrichtliniefeedback​

Die Nationale IT-Architekturrichtlinie ist ein zentrales Rahmenwerk für die öffentliche Verwaltung, das dabei hilft, Architekturentscheidungen systematisch, nachvollziehbar und transparent zu treffen. Sie fördert die passfähige Weiterentwicklung der Informationstechnik und gilt als verbindlicher Leitfaden für die Umsetzung.

Die Architekturrichtlinie gliedert sich ein in vier Vorgabenbereiche (Allgemein, Geschäftlich, Funktional, Technisch), welche in unserem Portal detailliert abgebildet werden:

1. Allgemeine Vorgabenfeedback​

Diese definieren grundlegende und rahmengebende Prinzipien sowie Eigenschaften zur Bewertung und Einordnung von Architekturentscheidungen.

2. Geschäftliche Vorgabenfeedback​

Hier werden Organisation, Motivation und die Fähigkeiten der geschäftlichen Aktivitäten inklusive notwendiger Arbeitsweisen beschrieben.

  • Inklusives Design: Die Einhaltung der Vorgaben zur Barrierefreiheit (BITV 2.0) ist Voraussetzung für rechtssichere digitale Verwaltungsleistungen.
  • Prozesse & Fachlogik: Die abstrakten Geschäftsfähigkeiten werden durch passgenaue D-Stack-Module wie den Workflows oder dem Einwilligungsmanagement unterstützt.

3. Funktionale Vorgabenfeedback​

Sie beschreiben die konkreten Anforderungen und Bedingungen zur Gestaltung sowie Umsetzung von Informationssystemen und Digitalisierungsaktivitäten.

  • Funktionsbausteine: Die Übersicht D-Stack Funktionsbausteine übersetzen die funktionalen Vorgaben in konkrete, wiederverwendbare Software-Bausteine der E-Government-Architektur. Das Modul Identität & Zugang deckt beispielsweise alle Vorgaben bzgl. zentralem IAM und Föderation ab.
  • Interoperabilität: Konzepte wie der Souveräner Datenaustausch definieren, wie fachlicher Datenaustausch standardisiert stattfindet.

4. Technische Vorgabenfeedback​

Die technische Vorgaben beschreiben die konkrete technische Realisierung von Informationstechnik und Digitalisierung.

Die Nationale IT-Architekturrichtlinie definiert das „Was“ und „Warum“ (die normativen, strategischen und regulatorischen Leitplanken). Um diese Vorgaben jedoch systematisch bei der Entwicklung moderner Cloud-Infrastrukturen in die Praxis zu übersetzen, nutzt das D-Stack-Konzept etablierte Methodiken: das Cloud Adoption Framework (CAF) und das Well-Architected Framework (WAF). Sie liefern das „Wie“:

  1. Cloud Adoption Framework (CAF): Das CAF operationalisiert im Wesentlichen die Allgemeinen und Geschäftlichen Vorgaben der Richtlinie.

    • Strategie & Planung: Es strukturiert, wie die organisatorische Transformation, Schulungen (Readiness) und Ressourcenplanung in Behörden erfolgen muss, um den Richtlinien gerecht zu werden.
    • Governance: Es etabliert Konzepte wie souveräne "Landing Zones" (Governance), mit denen rechtliche Rahmenbedingungen (z. B. BSI-Grundschutz) automatisch auf Cloud-Umgebungen erzwungen werden.

  2. Well-Architected Framework (WAF): Das WAF setzt die Funktionalen und Technischen Vorgaben in messbare Design-Prinzipien um.

    • Security Pillar: Erfüllt die Vorgaben zur technischen Sicherheit durch strikte Implementierung von Zero Trust und Verschlüsselung.
    • Reliability & Performance Pillar: Sichert die in der Richtlinie geforderte Ausfallsicherheit, Skalierbarkeit und dauerhafte Performanz von Fachverfahren (Cloud-Native Patterns).
    • Operational Excellence Pillar: Spiegelt die Anforderungen an hohe Wartbarkeit, Automatisierung (DevSecOps) und fortlaufende Überwachung (Observability) wider.

Zusammenfassend: Die Nationale IT-Architekturrichtlinie setzt den regulatorischen Standard des Bundes. Das CAF ermöglicht die organisatorische Einbettung dieses Standards in Behörden-Prozesse, und das WAF liefert die ingenieursmäßigen Blaupausen, um die geforderten hochsicheren Systeme am Ende tatsächlich in Code zu gießen.

rate_review Evaluation und Empfehlungen für die praktische Umsetzungfeedback​

Die aktuelle Version der Architekturrichtlinie stellt ein wichtiges, systematisches Gerüst für Architekturentscheidungen in der öffentlichen Verwaltung dar (angelehnt an das TOGAF-Framework). Für eine zukunftssichere und vor allem praktikabel umsetzbare Plattform-Entwicklung im Umfeld von D-Stack und EAM-Portalen ergeben sich folgende Evaluierungsergebnisse und Empfehlungen für zukünftige (und unsere eigenen) Versionen:

1. Von abstrakten Vorgaben zu "Policy as Code"feedback​

  • Beobachtung: Viele Vorgaben sind abstrakt und papierbasiert, was eine manuelle und zeitaufwändige Compliance-Prüfung in Projekten erzwingt.
  • Empfehlung: Vorgaben müssen in Zukunft maschinenlesbar als Policy as Code (z.B. mittels OPA/Rego oder Kyverno) bereitgestellt werden. Eine moderne Architekturrichtlinie integriert sich direkt in die CI/CD-Pipelines der Projekte.

2. Stärkere Verankerung von Cloud-Native & Open Source (GovStack)feedback​

  • Beobachtung: Aspekte bezüglich "Public Money, Public Code" oder Cloud-Native-Plattformen sind als Optionen vorhanden, aber nicht konsequent als Standard "by default" verankert.
  • Empfehlung: Orientierung an den internationalen GovStack Principles. Es sollte ein striktes „Cloud-Native First“- und „Open-Source First“-Paradigma eingeführt werden, unterstützt durch standardisierte Infrastrukturen wie den Sovereign Cloud Stack (SCS).

3. Modulare Standard-Funktionsbausteine statt Individualisierungfeedback​

  • Beobachtung: Die Richtlinie konzentriert sich stark auf methodische Vorgehensweisen zur Entscheidungsfindung (wie wird entworfen).
  • Empfehlung: Eine neue Iteration sollte zwingend die Wiederverwendung von existierenden, zertifizierten Basisdiensten (wie den DA Funktionsbausteinen) fordern. Bevor eine Architektur entworfen wird, muss nachgewiesen werden, warum nicht auf bestehende GovStack/D-Stack Building Blocks zurückgegriffen werden konnte.

4. Zero Trust als explizites Architektur-Fundamentfeedback​

  • Beobachtung: Sicherheit ist in den allgemeinen Vorgaben enthalten, jedoch fehlen strikt moderne Konzepte für stark verteilte und föderierte Systemlandschaften.
  • Empfehlung: Die Architekturrichtlinie sollte Zero Trust (Identitätsbasierte, kontinuierliche Verifikation ohne implizites Vertrauen) als absolut notwendiges Architekturmuster vorschreiben.