sync TOGAF ADM: Architekturentwicklung für Behördenfeedback
Erstellt am: 17. April 2026 | Zuletzt geändert: 18. Mai 2026 | Autor: BMDS-Architekturteam
1. Was ist TOGAF ADM?feedback
Die Architecture Development Method (ADM) im TOGAF (The Open Group Architecture Framework) ist ein iteratives Vorgehensmodell zur Entwicklung und Pflege von Enterprise Architekturen. Sie besteht aus acht Phasen plus einer zentralen Requirements-Management-Disziplin und ist weltweit der am weitesten verbreitete EA-Standard.
Der Ablaub bezieht sich hierbei immer auf einen Ausschnitt der Gesamtarchitektur - ein sog. Architekturfeld, wobei es in einer Organisation mehrere Architekturfelder mit entsprechenden Programmen und Umsetzungsprojekten parallel geben kann.
Im Zentrum steht das Anforderungsmanagement. Falls in einer Phase neue Anforderungen aufkommen, kann es sein, dass die Inhalte einer früheren Phase überarbeitet werden müssen.
Architecture Decision Records (ADRs): Entscheidungen sollen revisionssicher dokumentieren werden, analog zum Vorbild der Föderalen API-Autorisierungsinfrastruktur mit über 20 ADRs.
sync 2. ADM-Phasen im Behördenkontextfeedback
Vorgehensweise: Verproben → Entscheiden → Beschaffenfeedback
Für Behördenprojekte lässt sich der ADM-Zyklus in drei Kernblöcke verdichten, die den typischen Beschaffungsweg der öffentlichen Verwaltung abbilden:
Verproben (Phasen A–E)
Ziel: Architekturvision entwickeln, Ist- und Soll-Architektur erheben, Funktionsbausteine identifizieren und Lösungsoptionen bewerten.
- Phase A – Architekturvision: Strategisches Ziel und Scope des Vorhabens klären. Welche Verwaltungsleistung wird digitalisiert? Welches Fachverfahren wird abgelöst?
- Phase B – Geschäftsarchitektur: Fachliche Prozesse modellieren (z. B. Antragsverfahren, Genehmigungsprozesse). Geschäftsfähigkeiten (Capabilities) identifizieren.
- Phase C – Informationssystem-Architektur: Datenobjekte und Anwendungslandschaft definieren. Welche Register, Fachverfahren und Schnittstellen sind betroffen?
- Phase D – Technologie-Architektur: Infrastrukturbedarf ableiten. Cloud-Strategie (DVC, SCS), Container-Plattform, Netzwerkarchitektur festlegen.
- Phase E – Chancen & Lösungen: Proof-of-Concepts (PoCs) durchführen. Übersicht D-Stack Funktionsbausteine als Referenz heranziehen. Make-or-Buy-Optionen bewerten.
Entscheiden (Phase F)
Ziel: Verbindliche Migrationsplanung und Architekturentscheidung treffen. Make-or-Buy wird abschließend beantwortet.
- Migrationsplanung: Transition-Architekturen definieren (z. B. Legacy-Integration während der Ablösung).
- Priorisierung: Arbeitspakete nach Nutzen, Risiko und Abhängigkeiten priorisieren.
- EVB-IT-Vorbereitung: Leistungsbeschreibung und Bewertungsmatrix aus der Architekturarbeit ableiten.
Beschaffen (Phasen G–H)
Ziel: Implementierung steuern, Compliance sicherstellen und Architektur im Betrieb weiterentwickeln.
- Phase G – Implementierungs-Governance: Vergabeverfahren durchführen (EVB-IT-konform). Architektur-Compliance der Lieferanten prüfen. Abnahmetests gegen Referenzarchitektur.
- Phase H – Änderungsmanagement: Betriebsphase begleiten. Change Requests architekturkonform bewerten. Lessons Learned in den nächsten ADM-Zyklus einspeisen.
Phasendetails für Architekturfelderfeedback
| ADM-Phase | Behördenspezifische Aktivität | D-Stack-Bezug |
|---|---|---|
| Preliminary | Architektur-Governance einrichten, Architekturboard benennen, Rahmenwerk (TOGAF, ArL Bund) auswählen | Prinzipien & Richtlinien |
| A – Vision | IT-Strategie des Ressorts als Input, Stakeholder-Analyse (Fachseite, BSI, BfDI, Rechnungshof) | Kernprinzipien |
| B – Geschäftsarchitektur | Verwaltungsleistungen nach LeiKa modellieren, Capability Map gegen DA Framework abgleichen | Referenzarchitekturen |
| C – Informationssysteme | Register-Landschaft (NOOTS, XÖV), Fachverfahren, Schnittstellen-Katalog, Datenschutz-Folgenabschätzung | Registerdaten-Transfer |
| D – Technologie | DVC-Zielplattform, BSI-Grundschutz-Profil, Container-Plattform (SCS/K8s) | Cloud-Native, SCS & DVC |
| E – Chancen & Lösungen | PoC mit DA Funktionsbausteinen, Marktanalyse (Open Source vs. COTS), API-Tools-Bewertung | Siehe D-Stack Techstack Siehe D-Stack XaaS |
| F – Migration | EVB-IT-Leistungsbeschreibung, ADRs, Transitionsarchitektur, Rollout-Planung | Föderale API-Infra (ADRs) |
| G – Governance | Vergabe, Architektur-Review der Angebote, Abnahme gegen Referenzarchitektur | Sicherheit & Compliance |
| H – Änderung | Betriebsübergabe, Change-Prozess, Lessons Learned, nächster ADM-Zyklus | Well-Architected Framework |
3. Make-or-Buy-Entscheidung mit dem ADMfeedback
Die zentrale Frage für Behörden lautet bei jedem Funktionsbaustein: Selbst entwickeln, Open Source einsetzen oder kommerziell beschaffen?
Der ADM strukturiert diese Entscheidung systematisch:
| Kriterium | Make (Eigenentwicklung) | Buy (COTS) | Hybrid (OSS + Support) |
|---|---|---|---|
| Digitale Souveränität | Hoch | Niedrig | Hoch |
| Time-to-Market | Lang | Kurz | Mittel |
| Total Cost of Ownership | Variabel (Personalkosten) | Kalkulierbar (Lizenz) | Kalkulierbar (Support-Vertrag) |
| Vendor-Lock-in | Kein | Hoch | Gering |
| Wartbarkeit | Eigene Verantwortung | Hersteller | Community + Dienstleister |
| BSI-Konformität | Eigene Verantwortung | Zertifizierbar | Prüfbar (Open Source Audit) |
| Beispiel | Eigenentwicklung FöPD | SAP, MuleSoft | Kong OSS + Kong Enterprise Support |
Das DA-Portal empfiehlt den Hybrid-Ansatz als Default: Open-Source-Kern (z. B. Keycloak, Kong, OPA) mit kommerziellem Support-Vertrag. Dieser Ansatz maximiert digitale Souveränität bei kalkulierbaren Betriebskosten. Die Übersicht D-Stack Funktionsbausteine liefern die Referenzarchitektur; die API-Tools-Übersicht bewertet konkrete Produkte.
4. Beispiel: ADM-Zyklus für API-Managementfeedback
Ein konkretes Beispiel, wie eine Behörde den ADM-Zyklus für die Einführung eines API-Managements durchläuft:
| Phase | Aktivität | Ergebnis |
|---|---|---|
| A | Ziel: Alle Basisdienst-APIs sollen standardisiert und abgesichert werden | Architekturvision, Stakeholder-Map |
| B | Fachliche API-Landschaft erheben, Wertstromanalyse der API-Consumer | Capability Map, Gap-Analyse |
| C | Datenobjekte (API-Specs, Policies, Tokens) modellieren | Informationsarchitektur |
| D | Technologie-Entscheidung: Kong vs. APISIX vs. Azure APIM | Technologiebewertung |
| E | PoC: Kong Gateway + Föderale API-Autorisierungsinfra + Keycloak testen | PoC-Ergebnis, Machbarkeitsbewertung |
| F | ADR dokumentieren, EVB-IT-Leistungsbeschreibung erstellen, Rollout-Plan | Migrationsplan, ADRs |
| G | Vergabe durchführen, Implementierung begleiten, Abnahme | Produktivsystem |
| H | Betriebsmonitoring, Change Requests, nächster Zyklus für KI-Gateway | Betriebsdokumentation |
build 5. Werkzeugunterstützungfeedback
Der ADM-Zyklus wird durch spezialisierte EA-Tools unterstützt. Das BMDS empfiehlt den Einsatz von MEGA HOPEX als zentrales EA-Repository. Details zur Werkzeugunterstützung finden sich unter HOPEX im TOGAF-Kontext.
link 6. Bezug zu anderen Dokumentenfeedback
- Kernprinzipien – Architekturwerte, die den ADM-Zyklus normativ rahmen
- Kernprinzipien – Grundlegende Architekturprinzipien und konkrete Designvorgaben für Phase C und D
- Übersicht D-Stack Funktionsbausteine – Wiederverwendbare Bausteine als Input für Phase E
- API-Tools & Plattformen – Marktübersicht für Make-or-Buy in Phase F
- HOPEX im TOGAF-Kontext – Werkzeugunterstützung für den ADM-Zyklus