Zielgruppen für dieses Framework und Referenzarchitekturen

Erstellt am: 11. Mai 2026 | Zuletzt geändert: 16. Mai 2026 | Autor: Matthias, Enrico (GitLab)

Ziel des Dokuments: Diese Seite beschreibt, warum die Deutschland-Architektur (DA) als Framework über die konkreten Angebote im Deutschland-Stack hinaus notwendig ist. Mit Blick auf konkrete Zielgruppen, ihre täglichen Herausforderungen wird der mehrwert-orientierte Ansatz zur Weiterentwicklung übergreifender Funktionsbausteine dargestellt.

account_tree 1 Was ist ein Framework?feedback

Ein Framework ist ein methodischer und inhaltlicher Ordnungsrahmen für eine Enterprise-Architektur mit konkreten Anwendungen und Technologien. Es legt Begriffe, Artefakte, Qualitätskriterien und Zusammenhänge fest, damit Architekturarbeit reproduzierbar und organisationsübergreifend vergleichbar wird.

1.1 Einordnung im Architekturkontextfeedback

Ein Framework ist kein Produktkatalog und keine Technologieentscheidung. Es beantwortet vor allem die Fragen nach dem "Was" und "Warum" auf Architektur-Ebene und strukturiert das "Wie" für die Umsetzung.

Im Framework werden Zielbilder, Prinzipien, Rollen, Fähigkeiten und standardisierte Funktionsbausteine definiert.

1.2 Was sind Referenzarchitekturen in diesem Kontext?feedback

Referenzarchitekturen sind wiederverwendbare Zielbilder für typische Problemräume der Verwaltung. Sie übersetzen die Leitplanken des Frameworks in strukturierte Lösungsmuster, ohne eine konkrete Produktwahl vorzuschreiben.

Im DA-Kontext verbinden Referenzarchitekturen die Fähigkeitsebene mit der Umsetzungsebene:

• Sie ordnen Funktionsbausteine zu fachlichen Szenarien und definieren deren Zusammenspiel über standardisierte Schnittstellen.
• Sie beschreiben Qualitätsanforderungen wie Sicherheit, Interoperabilität, Betrieb und Skalierbarkeit als verbindliche Architekturkriterien.
• Sie lassen Raum für unterschiedliche Technologieentscheidungen in Behörden, solange die Architekturprinzipien und Schnittstellenstandards eingehalten werden.

Damit sind Referenzarchitekturen der Brückenschlag zwischen Framework und konkreter Implementierung: Sie machen aus Prinzipien und Bausteinen belastbare Umsetzungsoptionen.

1.3 Referenzen: TOGAF, FEAF, EIFfeedback

Die Deutschland-Architektur orientiert sich an verschiedenen Frameworks und konkretisiert diese für den Kontext der deutschen Verwaltungs-IT:

Framework	Fokus	Relevanz für die Deutschland-Architektur
TOGAF	Methode und Governance für Architekturentwicklung (z. B. ADM-Zyklus)	Liefert den Prozessrahmen, wie Zielbilder, Bausteine und Transitionen systematisch entwickelt werden
FEAF	Fähigkeits- und Domänenorientierung in der öffentlichen Verwaltung	Unterstützt die Trennung von Geschäftsfähigkeiten, Architekturbausteinen und Implementierungen
European Interoperability Framework (EIF)	Mehrdimensionale Interoperabilität (rechtlich, organisatorisch, semantisch, technisch)	Setzt Leitplanken für die grenz- und ebenenübergreifende Anschlussfähigkeit im EU-Kontext

1.4 Abgrenzung Framwework vs. Enterprise-Architekturfeedback

Framework	Enterprise-Architektur
Definiert Leitplanken, Prinzipien, Rollen, Governance und Vorgehensmodelle.	Beschreibt den unternehmensweiten Zielzustand von Business, Daten, Anwendungen und Technologie.
Legt fest, wie Architekturarbeit strukturiert und entschieden wird.	Nutzt den Framework-Rahmen, um konkrete Architekturartefakte und Transitionen zu entwickeln.
Ist methodisch und organisatorisch orientiert.	Ist inhaltlich auf die Gestaltung und Weiterentwicklung der IT-Landschaft ausgerichtet.
Gibt Standards für Fähigkeiten und Funktionsbausteine vor.	Ordnet Fähigkeiten, Funktionsbausteine, Anwendungen und Technologien in ein konsistentes Gesamtbild ein.
Ist produkt- und herstellerneutral.	Trifft in der Umsetzungsplanung konkrete Entscheidungen zu Lösungen, Integrationen und Betrieb.

Diese Abgrenzung ist zentral: Das Framework standardisiert die Architekturarbeit und die Interoperabilität, ohne Behörden auf ein einzelnes Produkt oder einen konkreten Technologie-Stack festzulegen.

help 2 Warum ein Framework für die Deutschland-Architektur?feedback

2.1 Ziel: Interoperable Lösungen mit standardisierten Schnittstellenfeedback

Die Deutschland-Architektur verfolgt ein konkretes Ziel: Behörden sollen Fachanwendungen auf Basis standardisierter Schnittstellen und gemeinsamer Querschnittsfunktionen entwickeln und betreiben können. Querschnittsfunktionen wie Identität, Bezahlung, Postfach oder Datenaustausch werden einmal spezifiziert, zentral bereitgestellt und von allen Verwaltungsleistungen genutzt. Standardisierte Schnittstellen zwischen Funktionsbausteinen stellen sicher, dass Komponenten verschiedener Hersteller und Behörden zusammenarbeiten, ohne bilaterale Einzelintegrationen.

Das Framework definiert dafür die Leitplanken (Prinzipien, Rollen, Mindestanforderungen), die Fähigkeiten beschreiben den Bedarf, und die Funktionsbausteine konkretisieren die wiederverwendbaren Architekturkomponenten. Die Auswahl konkreter Produkte und Technologien erfolgt erst in der Umsetzungsarchitektur der jeweiligen Behörde.

Dieses Prinzip reduziert den Integrationsaufwand für jede einzelne Behörde und stellt Interoperabilität über Verwaltungsebenen hinweg her. Neue Verwaltungsleistungen nutzen die bestehenden Bausteine des D-Stacks, statt eigene Parallellösungen zu schaffen. Die Spezifikation der Schnittstellen und Querschnittsfunktionen bildet den Kern der Funktionsbausteine.

Die Deutschland-Architektur entsteht dabei nicht am Reißbrett. Sie ist ein iterativer Prozess aus Verprobung in Reallaboren und übergreifender Standardisierung. Behörden erproben Funktionsbausteine unter realen Bedingungen, die Ergebnisse fließen in die Architekturspezifikation zurück, und die überarbeiteten Standards werden in der nächsten Iteration verbindlich. So wächst die DA schrittweise aus praktischer Erfahrung statt aus theoretischen Annahmen.

2.2 Der D-Stack allein reicht nichtfeedback

Der Deutschland-Stack (D-Stack) beschreibt die modularen Bausteine für die digitale Verwaltung. Die FITKO koordiniert bereits föderale IT-Infrastruktur mit dem Föderalen IT-Architekturboard (FIT-AB) und einer Referenzarchitektur für die Inanspruchnahme digitaler Verwaltungsleistungen. Beide Initiativen liefern Einzelteile, aber kein verbindliches Gesamtbild. Ohne eine Enterprise-Architektur mit klaren Verantwortlichkeiten, Minimalanforderungen und Governance fehlt die Grundlage, auf der Behörden interoperable Systeme aufbauen können.

Das Onlinezugangsgesetz (OZG) hat gezeigt, was passiert, wenn 575 Verwaltungsleistungen ohne verbindliche Architekturvorgaben umgesetzt werden: fragmentierte Insellösungen, die nicht miteinander kommunizieren. Die Deutschland-Architektur zieht die Konsequenz daraus. Sie macht den D-Stack von einem Empfehlungskatalog zu einer Architekturpflicht für neue Verwaltungsleistungen.

2.3 Europäische Einordnungfeedback

Der D-Stack existiert nicht im luftleeren Raum. Vier europäische und internationale Initiativen liefern bereits produktionsreife Bausteine, die in der Deutschland-Architektur verankert werden:

Initiative	Relevanz für den D-Stack
NOOTS (National Once-Only Technical System)	Löst den ebenenübergreifenden Datenaustausch zwischen Registern, den der D-Stack national braucht. Das Once-Only-Prinzip funktioniert nur grenzüberschreitend.
GovStack (DPI-Initiative von GIZ, ITU, DIAL)	Zeigt, wie modulare Building Blocks (Funktionsbausteine) international standardisierbar werden. Die GovStack-Analyse bewertet die Übertragbarkeit auf den D-Stack.
EDC (Eclipse Dataspace Components)	Liefert das souveräne Daten-Sharing-Protokoll bereits produktiv in Catena-X, Manufacturing-X, EHDS und Mobility Data Space. Der D-Stack-Baustein Souveräner Datenaustausch baut darauf auf.
eIDAS 2.0 / EUDI-Wallet	Die europäische Identitätsschicht wird bis Ende 2026 Pflichtangebot. Behörden haben drei Jahre, um die Integration in den D-Stack umzusetzen.

2.4 Was die FITKO leistet und wo die DA ansetztfeedback

Die FITKO betreibt das Föderale IT-Architekturboard und entwickelt Referenzarchitekturen für die föderale IT. Diese Referenzarchitekturen beschreiben den Zielzustand einzelner Verwaltungsleistungen. Die Deutschland-Architektur ergänzt diesen Ansatz um drei Ebenen, die heute fehlen:

1. Architekturpflicht statt Empfehlung. Der D-Stack braucht den Status einer verbindlichen Vorgabe für neue Verwaltungsleistungen, vergleichbar mit dem BSI-Grundschutz für Sicherheit.
2. Klare Betreiberstruktur. Wer betreibt die Identitätsschicht, das Postfach, die Bezahlfunktion, das Datenaustauschprotokoll? Heute ist die Verantwortung föderal verteilt und unklar. Die DA definiert für jede Basiskomponente einen Owner mit SLA und Haftung.
3. NOOTS-Anschluss von Tag 1. Eine Bürger-App, die nur national denkt, baut den nächsten Silo. Once-Only funktioniert nur, wenn der grenzüberschreitende Datenaustausch von Anfang an mitgeplant wird.

Conway's Law (Conways Gesetz) beschreibt, dass Softwaresysteme die Kommunikationsstrukturen ihrer Organisationen abbilden. Die Umkehrung gilt ebenso: Um die gewünschte technische Architektur zu erreichen, müssen Verwaltungsstrukturen entsprechend gestaltet werden. Erst die Frage, welche Strukturen die App erfordert, dann das Frontend.

groups 3 Zielgruppenfeedback

Die folgenden Zielgruppen arbeiten auf unterschiedlichen Ebenen der Enterprise-Architektur: von Framework- und Bausteinentscheidungen bis zur konkreten Implementierung in Anwendungen und Technologien.

IT-Architekten

Persona: Claudia, Enterprise-Architektin bei einer Bundesbehörde. Claudia verantwortet die Zielarchitektur ihrer Behörde und muss Fachanwendungen in die Deutsche Verwaltungscloud migrieren. Sie sucht verbindliche Bausteine, die sie in ihrer Architektur referenzieren kann, statt jedes Mal eigene Lösungen für Identität, Logging oder Datenaustausch zu entwerfen.

Tägliche Herausforderungen: Keine verbindlichen Schnittstellenspezifikationen zwischen Behörden, jede Integration wird bilateral verhandelt. Legacy-Fachanwendungen auf Mainframes oder veralteten Applikationsservern, für die kein Migrationspfad dokumentiert ist. Ohne den Technologie-Radar trifft jede Behörde eigene, oft widersprüchliche Technologieentscheidungen.

Nutzen der DA: Wiederverwendbare Funktionsbausteine mit definierten Schnittstellen und Qualitätsanforderungen reduzieren den Entwurfsaufwand. Klare Zuordnung zu BSI-Grundschutz und Zero Trust macht Sicherheitsnachweise reproduzierbar. Referenzarchitekturen für Cloud-Native und Microservices liefern erprobte Migrationspfade.

Projektleiter

Persona: Thomas, IT-Projektleiter bei einem Landesrechenzentrum. Thomas steuert die Modernisierung eines Melderegisters. Er braucht belastbare Vorgaben, um Aufwände zu schätzen, Ausschreibungen zu formulieren und Dienstleister zu steuern. Jedes Projekt erfindet aktuell den Architekturrahmen neu.

Tägliche Herausforderungen: Ausschreibungen enthalten keine standardisierten Architekturanforderungen, Angebote sind schwer vergleichbar. Risikobewertung von Architekturentscheidungen ist subjektiv, da keine Referenzwerte aus vergleichbaren Projekten vorliegen. Die Abstimmung mit anderen Registerprojekten kostet Monate, weil keine gemeinsame Architektursprache existiert.

Nutzen der DA: Standardisierte Leistungsbeschreibungen auf Basis der Funktionsbausteine machen Ausschreibungen vergleichbar und vereinfachen EVB-IT-konforme Vergabe. Architektur-Blueprints mit definierten Schnittstellen verkürzen die Abstimmung zwischen Projekten. Das Architekturhandbuch mit dem TOGAF-ADM-Prozess liefert einen methodischen Rahmen für die Projektdurchführung.

Entscheidungsträger

Persona: Dr. Yılmaz, CIO einer obersten Bundesbehörde. Dr. Yılmaz verantwortet das IT-Portfolio seiner Behörde mit über 200 Fachanwendungen. Viele davon sind redundant, veraltet oder nicht interoperabel. Er braucht eine Entscheidungsgrundlage, um Investitionen zu priorisieren und gegenüber dem Haushaltsausschuss zu begründen.

Tägliche Herausforderungen: Kein Überblick über die tatsächliche Anwendungslandschaft, Schatten-IT und historisch gewachsene Systeme sind nicht inventarisiert. Jede Behörde betreibt eigene Lösungen für E-Mail, Dokumentenmanagement, Formulare, die Konsolidierung scheitert an fehlenden gemeinsamen Standards. IT-Budgets werden jährlich vergeben, Architekturentscheidungen wirken über Jahrzehnte. Ohne Portfoliosteuerung entstehen strukturelle Schulden.

Nutzen der DA: Das EA-Capability-Modell liefert die Bewertungsgrundlage für das IT-Portfolio. Redundanzen werden sichtbar, Konsolidierungspotenziale quantifizierbar. Verbindliche Bausteine reduzieren das Risiko von Fehlinvestitionen, da Behörden auf geprüfte Komponenten zurückgreifen. Die Verknüpfung mit Compliance-Anforderungen schafft Transparenz gegenüber dem Rechnungshof.

warning 4 Probleme der Modernisierungfeedback

4.1 Fragmentierte Registerlandschaftfeedback

Deutschland betreibt über 375 Register auf Bundes-, Landes- und Kommunalebene. Diese Register wurden über Jahrzehnte unabhängig voneinander aufgebaut und verwenden unterschiedliche Datenmodelle, Schnittstellen und Betriebskonzepte. Das Registermodernisierungsgesetz (RegMoG) schreibt die Vernetzung vor. Die technische Umsetzung scheitert bislang an fehlenden gemeinsamen Standards für Datenaustausch und Identifikation.

4.2 Veraltete Anwendungslandschaftfeedback

Viele Behörden betreiben Fachverfahren auf Technologien aus den 1990er und 2000er Jahren. COBOL-basierte Mainframe-Systeme, proprietäre Middleware und monolithische Java-Anwendungen ohne automatisierte Tests bilden den Kern der IT-Landschaft. Die Migration in Cloud-Umgebungen erfordert Referenzarchitekturen, die den Übergang schrittweise strukturieren, statt einen Big-Bang-Ansatz zu erzwingen. Dabei gilt: Das Framework definiert die Zielkriterien, während die konkrete Technologieerneuerung in der Implementierungsebene der Behörden erfolgt.

4.3 Fehlende Interoperabilitätfeedback

Das OZG hat 575 Verwaltungsleistungen digitalisiert, aber keine einheitliche technische Basis geschaffen. Jedes Land, jede Kommune hat eigene Portale, eigene Nutzerkonten und eigene Bezahlverfahren implementiert. Bürgerinnen und Bürger erleben keinen durchgängigen Service, sondern Systembrüche bei jeder Zuständigkeitswechsel. Die Deutschland-Architektur adressiert dieses Problem durch verbindliche Basiskomponenten: ein Nutzerkonto, ein Postfach, ein Bezahlverfahren.

4.4 Fehlende Portfoliosteuerungfeedback

Ohne eine Architektur, die den Sollzustand definiert, gibt es keinen Maßstab für die Bewertung des Ist-Zustands. Behörden können nicht systematisch entscheiden, welche Anwendungen abgelöst, konsolidiert oder weiterbetrieben werden. Enterprise Architecture Management (EAM) mit dem D-Stack als Zielarchitektur schließt diese Lücke.

science 5 Reallabore als Feedback-Kanalfeedback

Das Bundeserprobungsgesetz vom Mai 2026 gibt Behörden die Freiheit, von verwaltungsrechtlichen Regelungen abzuweichen, um neue Verfahren unter realen Bedingungen zu testen. Diese Reallabore sind der Prüfstand für die Deutschland-Architektur. Jeder Funktionsbaustein, der im D-Stack spezifiziert wird, muss in der Praxis bestehen, nicht nur auf dem Papier.

5.1 Feedback-Kreislauf zwischen Reallabor und Architekturfeedback

Die Sandbox im D-Stack definiert Minimalanforderungen an Sicherheit, Usability und Datenschutz, die ein Baustein erfüllen muss, bevor er in einem Reallabor getestet wird. Diese Anforderungen basieren auf dem BSI-Grundschutz, den Datenschutzvorgaben und den Barrierefreiheitsanforderungen des Portals.

5.2 Konkreter Ablauffeedback

Das Reallabor-Gesetz nennt drei Anwendungsbereiche, die direkt auf D-Stack-Bausteine abbilden:

Reallabor-Bereich	D-Stack-Baustein	Erprobungsziel
EUDI-Wallet für digitale Identität (OZG-Änderung)	EUDI-Wallet, Authentifizierung	Wallet-Einführung in der Fläche vorbereiten
Registervernetzung (Unternehmensbasisdatenregister)	Datenaustausch, Nachweisdatenabruf	Once-Only-Prinzip für Unternehmensdaten
Automatisierter Nachweisabruf (BAföG)	Nachweisdatenabruf, Initiierung Verwaltungsleistung	Antragstellung beschleunigen, Verwaltungsaufwand senken

5.3 Von der Erprobung zum Portfoliofeedback

Jedes Reallabor liefert strukturierte Ergebnisse zurück an die Architektur. Die Ergebnisse fließen in die Portfoliosteuerung ein:

• Erfolgreich getestet: Der Baustein wird in den verbindlichen D-Stack überführt. Die Spezifikation wird auf Basis der Praxiserfahrung angepasst und bundesweit ausgerollt.
• Teilweise erfolgreich: Die Spezifikation wird überarbeitet. Identifizierte Hürden (regulatorisch, technisch, organisatorisch) werden dokumentiert und im nächsten Iterationszyklus adressiert.
• Nicht umsetzbar: Der Baustein wird zurückgestellt oder neu geschnitten. Die Gründe werden transparent im Feedback-Log dokumentiert.

Auf diese Weise entsteht ein evidenzbasiertes Portfoliomanagement. Investitionsentscheidungen stützen sich auf Praxisdaten aus Reallaboren statt auf theoretische Annahmen.

route 6 User Journeysfeedback

6.1 Journey 1: Ausschreibung einer Registermodernisierungfeedback

Phase	Akteure	Tätigkeit	KPI
Planung	Architekt, Projektleiter	Ist-Analyse der Anwendungslandschaft, Ziel-Architektur aus D-Stack ableiten, benötigte Funktionsbausteine identifizieren	Anzahl identifizierter Bausteine, Abdeckungsgrad der Ist-Systeme durch D-Stack-Komponenten
Ausschreibung	Projektleiter, Architekt	Leistungsbeschreibung auf Basis der Funktionsbausteine generieren, Angebote gegen Referenzarchitektur bewerten	Dauer bis zur Vergabe (Ziel: 30 % kürzer als ohne DA), Anteil standardkonformer Anforderungen in der Leistungsbeschreibung
Umsetzung	Projektleiter, Architekt	Reallabor beantragen, Baustein in der Sandbox gegen Minimalanforderungen testen, Ergebnisse dokumentieren und an die Architektur zurückspielen	Anzahl bestandener Sandbox-Tests, Anzahl identifizierter Spezifikationslücken, Time-to-Integration pro Baustein
Betrieb	CIO, Projektleiter	Portfolioentscheidung auf Basis der Testergebnisse treffen, bei Erfolg bundesweiten Rollout einleiten	Anteil wiederverwendeter D-Stack-Bausteine im Produktivbetrieb, Betriebskosten pro Transaktion, SLA-Einhaltungsquote

6.2 Journey 2: EUDI-Wallet-Integration in eine Behördefeedback

Phase	Akteure	Tätigkeit	D-Stack-Bezug
Anforderung	CIO, Fachbereich	Wallet-Pflicht aus eIDAS 2.0 in IT-Roadmap aufnehmen	EUDI-Wallet
Architektur	Enterprise-Architektin	Wallet-Baustein in Zielarchitektur einpassen, Schnittstellen zu Nutzerkonto und Authentifizierung klären	Authentifizierung, Nutzerkonto
Erprobung	Projektleiter	Reallabor nach Bundeserprobungsgesetz beantragen, Wallet im OZG-Kontext testen	Sandbox-Anforderungen
Bewertung	Architekturboard	Testergebnisse bewerten, Spezifikation anpassen	Feedback-Kreislauf
Rollout	CIO, Betrieb	Wallet produktiv schalten, SLA mit Betreiber vereinbaren	Betreiberstruktur

assignment 7 Interview-Leitfaden für Funktionsbausteinefeedback

Die Spezifikation der Funktionsbausteine erfordert systematische Interviews mit den Fachverantwortlichen, die die Bausteine im Alltag nutzen. Dieser Leitfaden strukturiert die Gespräche entlang der täglichen Herausforderungen.

7.1 Interviewstrukturfeedback

Jedes Interview folgt vier Blöcken und dauert 45 bis 60 Minuten. Die Ergebnisse fließen direkt in die Kapitelstruktur der Funktionsbausteine ein.

Block 1: Kontext und Rolle (10 Min.)

• In welchem Fachverfahren setzen Sie den Baustein ein?
• Welche Rolle haben Sie im Betrieb oder in der Nutzung?
• Mit welchen anderen Systemen interagiert der Baustein in Ihrem Kontext?

Block 2: Tägliche Herausforderungen (15 Min.)

• Welche drei Probleme kosten Sie im Alltag die meiste Zeit?
• Wo entstehen Medienbrüche oder manuelle Zwischenschritte?
• Welche Schnittstellen zu anderen Behörden oder Registern fehlen?
• Gibt es Sicherheits- oder Datenschutzanforderungen, die mit der aktuellen Lösung schwer umzusetzen sind?

Block 3: Anforderungen an den Soll-Zustand (15 Min.)

• Wie würde der ideale Ablauf aussehen, wenn Sie frei gestalten könnten?
• Welche Qualitätsmerkmale sind für Sie nicht verhandelbar (Verfügbarkeit, Antwortzeiten, Barrierefreiheit)?
• Welche Standards oder Schnittstellen sollte der Baustein implementieren?
• Gibt es europäische Vorgaben (eIDAS, NOOTS, DSGVO), die den Baustein betreffen?

Block 4: Reallabor und Erprobung (10 Min.)

• Wäre Ihre Behörde bereit, den Baustein in einem Reallabor zu erproben?
• Welche Rahmenbedingungen müssten dafür erfüllt sein (Personal, Budget, Rechtsgrundlage)?
• Wie sollten die Ergebnisse dokumentiert und zurückgespielt werden?

7.2 Zuordnung der Ergebnissefeedback

Die Interview-Ergebnisse werden den Kapiteln der Funktionsbaustein-Spezifikation zugeordnet:

Interview-Block	Zielkapitel im Funktionsbaustein
Kontext und Rolle	description Beschreibung
Tägliche Herausforderungen	settings Kernfunktionalitäten, shield Querschnittsanforderungen
Anforderungen Soll-Zustand	checklist Funktionale Anforderungen, api Service-Schnittstellen
Reallabor und Erprobung	account_tree Interne Workflows