HOPEX Handbuch ADD (TOGAF)feedback

1. Zweck und Geltungsbereichfeedback

Dieses Handbuch beschreibt verbindlich, wie Architekturdefinitionsdokumente (ADD) nach TOGAF ADM in HOPEX V6 (Codename Aquila) erstellt, strukturiert und kontinuierlich gepflegt werden. Es verwendet die 10 organisationsspezifischen Objekttypen als primäre Fachsprache und ordnet diese den TOGAF-Standardbegriffen sowie den korrespondierenden HOPEX-V6-Objekten zu.

Das Dokument regelt:

• welche 10 Objekttypen das Architekturmetamodell bilden und wie sie in HOPEX V6 abgebildet werden
• welche Rolle welche Objekte erstellt, pflegt und freigibt
• wie Ist-Zustand (Baseline) und Soll-Zustand (Target) im Repository verwaltet werden
• wie Versionierung, Statusübergänge und Changemanagement in HOPEX V6 ablaufen
• wie das Enterprise-Objekt als übergeordnete Klammer für alle 10 Objekttypen genutzt wird

Geltungsbereich: Alle Architekturinitiativen, die den TOGAF-ADM-Zyklus durchlaufen und in HOPEX V6 dokumentiert werden.

2. Organisationsspezifisches Metamodellfeedback

Das Metamodell definiert 10 Objekttypen, die zusammen die vollständige Architekturlandschaft beschreiben. Im Gegensatz zu reinen TOGAF-Standardbegriffen sind diese Typen auf die Erfordernisse einer Bundesbehörde/Organisation zugeschnitten.

Das HOPEX Objekt "Enterprise" steht als Root-Klammer über allen 10 Objekttypen. Es repräsentiert eine Organisation (Behörde, Ressort, Unternehmen) als Ganzes und ermöglicht die scope-bezogene Filterung aller Architekturinhalte in HOPEX V6. Sofern kein Unternehmensweites EAM etabliert ist, wird je Programm ein "Enterprise" Objekt verwendet.

Abbildung 2.1: Enterprise Architecture Metamodell - Die 10 Kern-Objekttypen und ihre Beziehungen in HOPEX V6

Im folgenden werden die Objekte kurz dargestellt.

Nr	Objekttyp	Beschreibung	TOGAF-Äquivalent
1	Geschäftsfähigkeit	Eine stabile, vom organisatorischen Aufbau unabhängige Fähigkeit, die zur Erfüllung des Geschäftsauftrags notwendig ist. Beschreibt was die Organisation leisten muss, nicht wie oder durch wen.	Business Capability
2	Org.-Einheit	Eine organisatorische Einheit (Ressort, Behörde, Dienstleister, Hersteller), die Aufgaben wahrnimmt, in Prozesse involviert ist und IT-Lösungen nutzt, betreibt oder verantwortet.	Organization Unit
3	Funktionsbaustein	Eine in sich geschlossene fachliche Funktion, die durch eine oder mehrere IT-Lösungen bereitgestellt wird. Bildet die funktionale Architektur ab und dient als Grundstruktur für Bedarfs- und Anforderungsmanagement.	Application Function
4	Prozess	Eine strukturierte Abfolge von Aktivitäten zur Erfüllung eines Geschäftsziels. Prozesse können durch IT-Lösungen und Technologien unterstützt werden.	Business Process
5	IT-Lösung	Logische Klammer über n Installationen mit definierter Verantwortung. Realisiert Funktionsbausteine, unterstützt Geschäftsfähigkeiten und Prozesse. Typen: Plattform, Service, Anwendung.	Application Component
6	Technologie	Ein technisches Produkt (Hardware, Software), das den Betrieb von IT-Lösungen ermöglicht. Wird über Standards, Versionen und Lebenszyklen gesteuert.	Technology Component
7	Installation	Eine konkrete Deployed Application – die Verbindung einer IT-Lösung (Application) mit einem Server/Node und einer RZ-Zone (Umgebung: Prod/Test/Dev). Entspricht dem HOPEX-Objekt „Deployed Application".	Node (Deployment Unit)
8	Server	Ein physischer oder virtueller Server, worauf Installationen betrieben werden. Umfasst Laufzeitumgebungen, Hardware, Storage und Netzwerkkomponenten.	Node (Deployment Unit)
9	RZ-Zone	Ein definierter Bereich innerhalb einer Rechenzentrums-Topologie. Installationen werden bei Geo-Redundanz einer RZ-Zone statt einem einzelnen RZ zugeordnet.	Location / Zone
10	Projekt	Eine zeitlich begrenzte Initiative zur Entwicklung, Einführung, Anpassung oder Ablösung von IT-Lösungen, Technologien oder Prozessen.	Work Package / Project

3. Enterprise als übergeordnete Klammerfeedback

Definition der Enterprise-Klammer

Das Enterprise-Objekt definiert den organisatorischen Rahmen und Geltungsbereich aller Architekturelemente. Es fungiert als:

• Scope-Filter: Ermöglicht die spezifische Filterung aller Objekte nach Organisationseinheit
• Root-Element: Übergeordnete Hierarchieebene für alle 10 Objekttypen
• Governance-Rahmen: Definiert Verantwortlichkeiten und Entscheidungskompetenzen

Enterprise-Konfiguration

Je nach organisatorischer Struktur sind verschiedene Enterprise-Konfigurationen möglich:

• Unternehmensweite EAM: Ein Enterprise-Objekt für die gesamte Organisation
• Programm-spezifisch: Ein Enterprise-Objekt je Digitalisierungsprogramm
• Ressort-spezifisch: Ein Enterprise-Objekt je Ministerium/Ressort

Hierarchische Beziehungen

Alle 10 Objekttypen sind dem Enterprise-Objekt untergeordnet und erben dessen Scope-Definition. Diese Hierarchie ermöglicht:

• Konsistente Architektur-Governance
• Einheitliche Reportings und Dashboards
• Klare Abgrenzung verschiedener Architekturbereiche

4. TOGAF-ADM Integrationfeedback

Die 10 Objekttypen sind direkt auf die TOGAF Architecture Development Method (ADM) abgestimmt und unterstützen alle ADM-Phasen:

Phase A: Architecture Vision

• Enterprise-Definition und Scope-Abgrenzung
• Stakeholder-Zuordnung über Org.-Einheiten

Phase B: Business Architecture

• Geschäftsfähigkeiten-Mapping
• Geschäftsprozess-Modellierung
• Organisationsarchitektur

Phase C: Information Systems Architecture

• Funktionsbaustein-Definition (Soll)
• Anwendungslandschaft (Soll)
• Daten- und Informationsarchitektur

Phase D: Technology Architecture

• Technologie-Standards
• Technologie-Produkte
• Physische Infrastruktur

Phase E/F: Roadmap

• Transformationsroadmap (Stufen/Phasen)
• Projekte

5. Governance und Lifecycle Managementfeedback

Rollen und Verantwortlichkeiten

Rolle	Verantwortlichkeit	Objekttypen
Enterprise Architect	Gesamtarchitektur, Standards	Alle Objekttypen
Business Architect	Geschäftsarchitektur	Geschäftsfähigkeit Org.-Einheit Funktionsbaustein Geschäftsprozess Datenobjekt
Solution Architect	Lösungsarchitektur	Funktionsbaustein IT-Service Anwendung Datenbestand
IT Architect	Technische Architektur	Anwendung Datenbestand Technologie Physische Komponente

Lifecycle-Phasen

Jeder Objekttyp durchläuft definierte Lifecycle-Phasen:

1. Entwurf: Initiale Definition und Strukturierung
2. Validierung: Fachliche und technische Prüfung
3. Freigabe: Formelle Genehmigung für Umsetzung
4. Implementation: Operative Umsetzung
5. Betrieb: Produktiver Einsatz
6. Dekommissionierung: Kontrollierte Außerbetriebnahme

6. Best Practicesfeedback

Modellierungsrichtlinien

• Einheitliche Namenskonventionen verwenden
• Klare Abhängigkeiten zwischen Objekten definieren
• Redundanzen vermeiden durch Wiederverwendung
• Regelmäßige Konsistenzprüfungen durchführen

Tool-spezifische Hinweise für HOPEX V6

• Enterprise-Objekttyp als Filter in allen Views nutzen
• Standardisierte Diagramm-Templates verwenden
• Automatisierte Konsistenzprüfungen aktivieren
• Versionierung und Change-Requests dokumentieren

7. Verwaltung von Ist- und Soll-Zustandfeedback

HOPEX V6 bietet mehrere Mechanismen, um Baseline (Ist) und Target (Soll) voneinander zu trennen und parallel zu verwalten.

7.1 Mechanismen im Vergleichfeedback

Mechanismus	Geeignet für	Vorteile	Einschränkungen
Roadmap Stages	IT-Lösungen, Geschäftsfähigkeiten, Technologien	Visuell, zeitlich strukturiert; verknüpft IST→SOLL pro Stage; V6-Standardfunktion	Granularität auf Stage-Ebene, nicht Objekt-Attribut-Ebene
Lifecycle-Status	IT-Lösungen, Technologien, Server	Einfach; direkt am Objekt; filterbar in Diagrammen	Statuswechsel überschreibt; kein paralleles Modell
Variations (Objektvarianten)	IT-Lösungen, Funktionsbausteine	Echte Verzweigung; Varianten parallel bewertbar	Muss aktiviert werden; erhöht Komplexität
Assessment Scores	Geschäftsfähigkeiten	Numerische IST/SOLL-Gaps; Heat Map-fähig	Nur bewertbare Attribute; kein strukturelles Modell
Separate Environments	Gesamte Architekturlandschaft	Vollständige Trennung; sauberste Lösung	Hoher Administrationsaufwand; Synchronisation nötig

7.2 Empfohlenes Vorgehen: Roadmap Stages + Lifecycle-Statusfeedback

Für die Mehrzahl der EAM-Initiativen empfiehlt sich eine Kombination: Roadmap Stages zur zeitlichen Strukturierung der Transformation, ergänzt um Lifecycle-Status an jedem Objekt.

Schritt-für-Schritt-Anleitungfeedback

• Schritt 1 – Roadmap erstellen: Assessment & Roadmap > New Roadmap. Zeitraum und Granularität festlegen (z. B. Quartale/Halbjahre).

• Schritt 2 – Baseline Stage: Erste Stage als "Baseline (IST)" definieren. Alle aktiven IT-Lösungen, Geschäftsfähigkeiten, Technologien, Installationen dieser Stage zuordnen.

• Schritt 3 – Target Stages: Weitere Stages anlegen (z. B. "Stufe 1 – 2026", "Stufe 2 – 2027", "Ziel 2028"). Pro Stage den Soll-Zustand der Objekte definieren.

• Schritt 4 – Objekte positionieren: Jedes Objekt in jeder Stage mit seinem geplanten Zustand versehen (Current, Planned, Sunset, Retired).

• Schritt 5 – Projekte verknüpfen: IT-Maßnahmen (Projekte) den Roadmap-Stages zuordnen; jedes Projekt verknüpft mit den IT-Lösungen und Technologien, die es verändert.

• Schritt 6 – Gap-Analyse: Assessment > Gap Analysis: Automatische Gegenüberstellung Baseline vs. Target; Findings als Objekte speichern.

• Schritt 7 – Roadmap publizieren: Als Dashboard-View oder ADD-Report-Abschnitt exportieren.

Statuswerte pro Objekttypfeedback

Status	IST / SOLL	Anwendbare Objekttypen und Bedeutung
Active	IST	IT-Lösung, Technologie, Installation, Server: in Produktion. Geschäftsfähigkeit: wird aktiv erbracht.
Planned	SOLL	Alle Objekttypen: für eine zukünftige Stage vorgesehen; noch nicht realisiert.
Under Development	SOLL / Übergang	IT-Lösung, Installation: in Entwicklung/Aufbau; bereits budgetiert via Projekt.
Sunset / To Be Retired	IST → Auslauf	IT-Lösung, Technologie: wird in definierter Stage abgelöst. Server: wird dekommissioniert.
Retired	Historisch	Alle Objekttypen: nicht mehr aktiv; bleibt für Nachvollziehbarkeit im Repository.
Candidate	Vorschlag	IT-Lösung, Funktionsbaustein: noch nicht entschieden; wird in Review bewertet.

7.3 Versionierung und Änderungsmanagementfeedback

Object History (Änderungsprotokoll)feedback

Jedes HOPEX-Objekt führt automatisch ein Änderungsprotokoll (Who, When, What). Einsehbar über den Reiter "History" im Objekteigenschaften-Dialog. Gilt für alle 10 Objekttypen.

Variations für Alternativszenarienfeedback

Für Objekte, bei denen mehrere Soll-Alternativen parallel bewertet werden sollen (z. B. Konsolidierung IT-Lösung A vs. Neubeschaffung IT-Lösung B):

• Aktivierung: HOPEX-Optionen > Business Process and Architecture Modeling > Activate Variations.

• Variante anlegen: Am Objekt > Rechtsklick > New Version/Variation.

• Vergleich und Entscheidung: Varianten in Diagrammen parallel darstellen. Nach Entscheidung: gewählte Variante promovieren, übrige archivieren.

Statusübergänge und Freigabeprozessfeedback

ADD-Statusübergänge in HOPEX V6
1. ENTWURF (Draft) → EA/DA erstellt Objekte im WORK-Environment
2. IN REVIEW → EA übergibt an CA über HOPEX-Review-Workflow (Task-basiert)
3. KOMMENTIERUNG → FB und Stakeholder kommentieren via inline Comments
4. ÜBERARBEITUNG → EA überarbeitet auf Basis der Kommentare
5. FREIGEGEBEN (Approved) → CA gibt das ADD frei; Status wird auf "Approved" gesetzt
6. BASELINE → Freigegebener Zustand wird als neuer IST übernommen
7. ARCHIVIERT → Vorherige Baseline bleibt historisch nachvollziehbar

8. ADD-Erstellung in HOPEX V6 – Schritt für Schrittfeedback

8.1 Preliminary Phase und Phase A: Architekturvisionfeedback

• Architekturinitiative anlegen: Architecture Project > New; Scope, Ziele und Stakeholder erfassen.

• Treiber und Ziele: Strategy > Drivers: Driver-Objekte anlegen; Objectives zuordnen.

• Prinzipien prüfen/anlegen: Strategy > Principles: Architekturprinzipien sichten, bei Bedarf ergänzen.

• Stakeholder-Register: Stakeholder-Objekte anlegen; Interesse und Einfluss dokumentieren.

8.2 Phase B: Geschäftsarchitekturfeedback

• Geschäftsfähigkeiten (Baseline): Business Architecture > Capability Map: IST-Capabilities mit Assessment Score bewerten.

• Geschäftsfähigkeiten (Target): In Roadmap die Ziel-Capabilities für Target Stage definieren; neue als "Planned" markieren.

• Org.-Einheiten: Organization > Org. Chart: Aufbauorganisation abbilden; Zuordnung zu Fähigkeiten und Prozessen.

• Prozesse: Business Process Analysis: BPMN-Diagramme für IST-Prozesse; SOLL-Prozesse als Variante oder neue Version.

8.3 Phase C: Informationssystemarchitekturfeedback

Funktionsbausteinefeedback

• IST-Funktionslandkarte: Alle bestehenden Funktionsbausteine als Function-Objekt (IT Architecture > Functions) erfassen.

• SOLL-Funktionslandkarte: Neue/konsolidierte Funktionsbausteine als "Planned" anlegen; in Target Stage positionieren.

• Mapping: Jeder Funktionsbaustein wird mit den IT-Lösungen verknüpft, die ihn implementieren.

Abbildung 8.1: Beispiel einer Funktionslandkarte mit Mapping zu IT-Lösungen

IT-Lösungen / Anwendungenfeedback

• Applikationsportfolio (Baseline): IT Portfolio > Applications: Alle IST-Lösungen mit Status "Active", Typ (Plattform/Service/Anwendung), Lifecycle-Daten, Kosten, Verantwortlichem.

• Soll-Anwendungslandschaft: Neue IT-Lösungen als "Planned" anlegen; abzulösende auf "Sunset" setzen; in Roadmap-Stage positionieren.

• Schnittstellenkatalog: Application Interface-Objekte für alle Integrationen; Datenflüsse und Protokolle dokumentieren.

8.4 Phase D: Technologiearchitekturfeedback

• Technologie-Inventar (Baseline): IT Architecture > Technology: IST-Technologien mit Versionen, EOL, Typ (HW/SW).

• Installationen (Baseline): Alle konkreten Deployed Applications erfassen (IT Architecture > Deployed Applications); Zuordnung zu Application, Server und RZ-Zone.

• Server und RZ-Zonen (Baseline): Technical Infrastructure Diagrams: Server-Bestand und RZ-Topologie.

• Soll-Architektur: Geplante Technologien, neue Installationen und Server-Konsolidierung in Target Stages; Legacy auf "Sunset".

8.5 Phase E/F: Gap-Analyse und Roadmapfeedback

• Gap-Analyse: Assessment > Gap Analysis: Automatische Baseline-vs-Target-Analyse für alle 10 Objekttypen.

• Projekte (IT-Maßnahmen): Jedes Gap wird einem Projekt zugeordnet; Projekte enthalten Zeitplanung, Budget, betroffene Objekte.

• Transformationsroadmap: Roadmap mit allen Stages und zugeordneten Objekten finalisieren.

Abbildung 8.2: TOGAF ADM Transformationsroadmap mit zeitlichen Stages und Objektzuordnungen

8.6 ADD-Report generierenfeedback

Das ADD wird in HOPEX V6 als dynamischer Report generiert – nicht manuell zusammengestellt.

• Standard-Report: Reports > Architecture Definition Document Template; Architekturinitiative auswählen; Report generieren.

• Angepasster Report: Report-Builder (V6) nutzen, um Abschnitte pro Objekttyp, Filter und Diagramme einzubinden.

• Dashboard: Dashboards für Stakeholder ohne HOPEX-Zugang; Live-Sicht auf ADD-Inhalte.

• KI-Analyse (V6): HOPEX AI Assistant für Rationalisierungsempfehlungen im Applikationsportfolio.

Zu klären: Wie kann Report auch automatisiert in Website veröffentlicht werden?

9. Qualitätssicherung und ADD-Governancefeedback

9.1 Vollständigkeitsprüfungfeedback

Vor der Freigabe eines ADD prüft der Enterprise Architect die folgenden Mindestanforderungen:

Prüfkriterium	OK	Verantwortlich
Enterprise-Objekt angelegt und alle 10 Objekttypen zugeordnet	☐	CA / EA
Architecture Project angelegt und dem Enterprise zugeordnet	☐	EA
Alle Geschäftsfähigkeiten mit IST-Score bewertet	☐	DA (Business) / EA
Geschäftsfähigkeiten für Target Stage mit SOLL-Score definiert	☐	DA (Business) / EA
Funktionsbaustein-Katalog vollständig; Mapping zu IT-Lösungen vorhanden	☐	EA
IT-Lösungsportfolio: Alle IT-Lösungen mit Lifecycle-Status und Typ	☐	PM / EA
Soll-Anwendungslandschaft in Target Stage positioniert	☐	EA
Technologieportfolio: Alle Technologien mit Version und EOL-Datum	☐	DA (Tech) / OPS
Installationen mit Zuordnung zu IT-Lösung, Server und RZ-Zone	☐	OPS / SA
Gap-Analyse durchgeführt; Assessment Findings dokumentiert	☐	EA
Projekte mit betroffenen IT-Lösungen und Zeitplanung verknüpft	☐	PM
Stakeholder-Review abgeschlossen; Kommentare berücksichtigt	☐	EA / CA
ADD-Report erfolgreich generiert und geprüft	☐	EA / CA

9.2 Pflegezyklen pro Objekttypfeedback

Objekttyp	Pflegezyklus	Auslöser für außerordentliche Aktualisierung
Geschäftsfähigkeit	Jährlich	Neue strategische Ziele, Reorganisation, gesetzliche Anforderungen
Org.-Einheit	Jährlich	Organisationsänderung, Ressortschnitt, Ausgliederung
Funktionsbaustein	Halbjährlich	Neue fachliche Anforderungen, Konsolidierung, Standardisierung
Prozess	Jährlich	Prozessoptimierung, Digitalisierungsprojekte, Audit-Ergebnisse
IT-Lösung / Anwendung	Quartalsweise	Neue Projekte, Abschaltungen, Beschaffungsentscheidungen, Migrationsprojekte
Technologie	Halbjährlich	EOL-Ankündigungen, Standardänderungen, neue Technologien
Installation (Deployed Application)	Quartalsweise	Deployed Applications erfassen/aktualisieren; Migrationen, Abschaltungen, Standortwechsel
Server	Quartalsweise	Beschaffung, Dekommissionierung, Virtualisierung, Cloud-Migration
RZ-Zone	Jährlich	RZ-Konsolidierung, neue Verfügbarkeitszonen, Georedundanz-Änderungen
Projekt (IT-Maßnahme)	Quartalsweise	Projektstart, -abschluss, Planänderungen, Budget-Entscheidungen

10. Häufige Fehler und Lösungsansätzefeedback

Fehler / Problem	Ursache	Lösung in HOPEX V6
IST- und SOLL-IT-Lösungen nicht unterscheidbar	Kein konsequentes Status-Tagging; alle auf "Active"	Lifecycle-Status aller IT-Lösungen bereinigen; Roadmap-Stages nutzen
Funktionsbausteine und IT-Lösungen vermischt	Keine Trennung zwischen fachlicher Funktion und realisierender Lösung	Function-Objekt (IT Architecture > Functions) konsequent nutzen; "realizes"-Relation zu IT-Lösungen (Application) pflegen
Installationen nicht erfasst	Nur logische IT-Lösungen modelliert; physische Deployed Applications fehlen	Deployed Application anlegen (IT Architecture > Deployed Applications); Verknüpfung mit Application, Server und RZ-Zone herstellen
RZ-Zonen nicht georedundant abgebildet	Installationen direkt einem einzelnen RZ zugeordnet	RZ-Zone als separate Site-Hierarchie (RZ > Zone); Installationen der Zone zuordnen
Redundante Objekte im Repository	Mehrere Architekten legen dasselbe Objekt unterschiedlich an	Vor Neuanlage Repository-Suche nutzen; Naming Conventions durchsetzen; regelmäßige Datenbereinigung
Unvollständige Roadmap-Stages	Nur einzelne Objekttypen in Roadmap erfasst	Alle 10 Objekttypen systematisch pro Stage positionieren; Abhängigkeiten dokumentieren
Fehlende Stakeholder-Zuordnung	Objekte ohne klare Verantwortlichkeiten	Je Objekt mindestens einen Owner und Stakeholder zuordnen; Rollen-Matrix erstellen
Inkonsistente Assessment Scores	Unterschiedliche Bewertungsskalen verwendet	Einheitliche Scoring-Matrix definieren; regelmäßige Kalibrierung durchführen
Veraltete Gap-Findings	Findings nicht mit aktueller Roadmap synchronisiert	Gap-Analyse automatisiert nach jeder Roadmap-Änderung neu ausführen
Fehlende Projekt-Verknüpfungen	Architektur-Objekte nicht mit IT-Maßnahmen verknüpft	Jedes geplante Objekt mindestens einem Projekt zuordnen; Abhängigkeiten dokumentieren

---

Anhang: Weitere Ressourcen

• TOGAF 9.2 Standard (The Open Group)
• HOPEX V6 Documentation (Mega International)
• Organisationsspezifische Architekturrichtlinien
• Enterprise Architecture Governance Framework