hub HOPEX: TOGAF-Vorgehensmodell werkzeuggestützt umsetzenfeedback
Erstellt am: 17. April 2026 | Autor: BMDS-Architekturteam
1. Was ist HOPEX?feedback
MEGA HOPEX ist eine Enterprise-Architecture-Management-Plattform der Firma MEGA International. Sie unterstützt die gesamte EA-Governance, von der Strategieplanung über die Ist-/Soll-Architektur bis zur Transformation. HOPEX ist nach dem TOGAF-Standard zertifiziert und bildet den ADM-Zyklus nativ ab.
Für Behörden bietet HOPEX den Vorteil, dass Architekturarbeit nicht in isolierten Dokumenten stattfindet, sondern in einem zentralen Repository mit konsistenten Metamodellen, Abhängigkeitsgraphen und automatisierten Berichten.
Kernmodulefeedback
| Modul | Funktion | ADM-Phase |
|---|---|---|
| HOPEX Architecture | Ist-/Soll-Architektur, Capability Mapping, Gap-Analyse | B, C, D |
| HOPEX IT Portfolio Management | Anwendungsportfolio, Technologie-Radar, Lifecycle-Management | A, E, H |
| HOPEX Business Process Analysis | Geschäftsprozessmodellierung (BPMN), Wertstromanalyse | B |
| HOPEX Data Governance | Datenobjekte, Datenflüsse, DSGVO-Compliance-Mapping | C |
| HOPEX IT Budget Planning | Kostenmodelle, TCO-Vergleich Make/Buy/Hybrid | E, F |
| HOPEX Risk & Compliance | BSI-Grundschutz-Mapping, Risikobewertung | G, H |
2. Wie unterstützt HOPEX den TOGAF-ADM-Zyklus?feedback
3. Zehn praktische Beispiele mit DA Funktionsbausteinenfeedback
Die folgenden Beispiele zeigen, wie HOPEX den TOGAF-ADM-Zyklus konkret mit den D-Stack Funktionsbausteinen verknüpft, von der Strategie bis zur Beschaffung.
Beispiel 1: IAM-Einführung, Capability Map anlegenfeedback
ADM-Phase: B (Geschäftsarchitektur) Funktionsbaustein: Identität & Zugang (IAM)
Szenario: Eine Landesbehörde will ein zentrales IAM einführen. In HOPEX wird zunächst die Capability Map der Behörde modelliert.
HOPEX-Umsetzung:
- Im Modul Business Process Analysis die bestehenden Authentifizierungsprozesse (LDAP-Anmeldung, Einzelpasswörter) als Ist-Prozesse modellieren.
- Im Modul Architecture eine Capability „Identitäts- und Zugangsmanagement" anlegen und mit den Geschäftsprozessen verknüpfen.
- Die Soll-Capability gegen den DA-Funktionsbaustein Identität & Zugang abgleichen (SSO, MFA, OIDC, SCIM).
- Gap-Analyse automatisch erzeugen: Welche Fähigkeiten fehlen? (z. B. FIDO2, eID-Anbindung, Keycloak-Föderation).
HOPEX-Diagramm: Capability Map mit Gap-Analyse
Ergebnis: Priorisierte Liste fehlender IAM-Fähigkeiten als Input für Phase E (Verproben).
Beispiel 2: API-Management, Technologiebewertungfeedback
ADM-Phase: D → E (Technologie-Architektur → Verproben) Funktionsbaustein: API-Management + API-Tools & Plattformen
Szenario: Ein Bundesministerium evaluiert API-Gateway-Lösungen. HOPEX dient als zentrale Bewertungsplattform.
HOPEX-Umsetzung:
- Im IT Portfolio Management die Kandidaten (Kong, APISIX, Azure APIM, Apigee) als „Technologie-Komponenten" anlegen.
- Jede Komponente gegen die acht Funktionsbausteine F1–F8 bewerten (Skala 0–3).
- Im IT Budget Planning die TCO-Modelle (Lizenz, Betrieb, Personal) je Kandidat hinterlegen.
- Einen Technologie-Radar-Eintrag erzeugen: Ring (Adopt/Trial/Assess/Hold) + Begründung.
HOPEX-Diagramm: Technologie-Radar (Portfolio Assessment)
Ergebnis: Bewertungsmatrix mit TCO-Vergleich und Architecture-Board-Empfehlung (z. B. „Kong OSS mit Enterprise Support, Trial").
Beispiel 3: Zero-Trust-Einführung, Risikoanalysefeedback
ADM-Phase: E → F (Verproben → Entscheiden) Funktionsbaustein: Zero-Trust Policy Engine
Szenario: Eine Bundesoberbehörde plant die Einführung von Zero-Trust-Policies für interne APIs. HOPEX dokumentiert die Risikoanalyse.
HOPEX-Umsetzung:
- Im Risk & Compliance Modul die aktuellen Bedrohungsszenarien modellieren (z. B. Lateral Movement, Token Theft).
- BSI-Grundschutz-Bausteine (NET.3.2, APP.3.1) mit der Zero-Trust-Referenzarchitektur verknüpfen.
- OPA-/Cedar-Policies als „Policy-Artefakte" im Architecture-Repository hinterlegen und mit den geschützten Anwendungen verlinken.
- Impact-Analyse durchführen: Welche Anwendungen sind von der Policy-Engine-Einführung betroffen?
HOPEX-Diagramm: Risiko-Heatmap (Risk & Compliance)
Ergebnis: Risiko-Heatmap mit Rollout-Priorisierung (kritische Anwendungen zuerst).
Beispiel 4: Föderale API-Autorisierung, ADR-Dokumentationfeedback
ADM-Phase: F (Entscheiden) Funktionsbaustein: Föderale API-Autorisierungsinfrastruktur
Szenario: Die Architekturentscheidungen (ADRs) der Föderalen API-Infrastruktur sollen im EA-Repository nachvollziehbar dokumentiert werden.
HOPEX-Umsetzung:
- Im Architecture Modul einen ADR-Objekttyp anlegen (Status, Datum, Optionen, Entscheidung, Konsequenzen).
- Die 22 ADRs der Föderalen API-Infrastruktur importieren (z. B. ADR-001: OAuth 2.0 + FAPI 2.0).
- Jede ADR mit den betroffenen Systemen (FöPD, Authorization Server, API-Gateway) verknüpfen.
- Traceability-Matrix automatisch erzeugen: ADR → betroffene Systeme → betroffene Geschäftsprozesse.
HOPEX-Diagramm: ADR Traceability Matrix
Ergebnis: Revisionssichere Nachvollziehbarkeit jeder Architekturentscheidung im zentralen Repository.
Beispiel 5: Cloud-Migration, Transitions-Architekturfeedback
ADM-Phase: F → G (Entscheiden → Beschaffen) Funktionsbaustein: Container-Orchestrierung + Multi-Cloud-Abstraktion
Szenario: Ein IT-Dienstleister migriert Fachverfahren von On-Premises auf die DVC. HOPEX bildet die Transition ab.
HOPEX-Umsetzung:
- Im Architecture Modul drei Architekturzustände anlegen: Ist (VM-basiert), Transition (Hybrid), Soll (Kubernetes-nativ).
- Jedes Fachverfahren mit seinem Architekturzustand und dem Migrationspfad verknüpfen.
- Im IT Portfolio Management die Anwendungen auf einer Migration-Readiness-Heatmap visualisieren (grün = ready, gelb = Anpassung nötig, rot = Neuentwicklung).
- Rollout-Gantt aus den Abhängigkeiten automatisch generieren.
HOPEX-Diagramm: Transitions-Architektur (Ist → Transition → Soll)
Ergebnis: Visuelle Transitions-Roadmap mit Abhängigkeitsgraph und Ressourcenplanung.
Beispiel 6: DevSecOps-Pipeline, Compliance-Mappingfeedback
ADM-Phase: G (Implementierungs-Governance) Funktionsbaustein: DevSecOps / GitOps
Szenario: Die CI/CD-Pipeline eines Basisdienstes muss BSI-C5-konform sein. HOPEX trackt die Compliance.
HOPEX-Umsetzung:
- Im Risk & Compliance Modul die BSI-C5-Kontrollen importieren (OPS-01 bis OPS-24).
- Jede Kontrolle mit dem entsprechenden Pipeline-Schritt verknüpfen (z. B. OPS-07 „Schwachstellenmanagement" → SAST-Scan-Stage).
- Für jede Kontrolle den Erfüllungsgrad dokumentieren (erfüllt / teilweise / offen) und den Verantwortlichen zuweisen.
- Compliance-Dashboard mit Ampelstatus automatisch bereitstellen.
HOPEX-Diagramm: Compliance-Dashboard (Risk & Compliance)
Ergebnis: Jederzeit aktueller BSI-C5-Compliance-Status der Pipeline im EA-Repository.
Beispiel 7: E-Signatur, Geschäftsprozessmodellierungfeedback
ADM-Phase: B (Geschäftsarchitektur) Funktionsbaustein: E-Signatur
Szenario: Eine Kommune will den Unterschriftenprozess für Baugenehmigungen digitalisieren. HOPEX modelliert den Zielprozess.
HOPEX-Umsetzung:
- Im Business Process Analysis den Ist-Prozess (Papier-Unterschrift, Postweg, Archivierung) als BPMN modellieren.
- Den Soll-Prozess mit qualifizierter elektronischer Signatur (QES) entwerfen und die eIDAS-Vertrauensstufen zuordnen.
- Den Funktionsbaustein E-Signatur als „Anwendungskomponente" verlinken und die Schnittstellen zum IAM und DMS modellieren.
- Prozessvergleich (Ist vs. Soll) mit Durchlaufzeiten und Medienbrüchen visualisieren.
HOPEX-Diagramm: BPMN Prozessmodell (Ist vs. Soll)
Ergebnis: BPMN-Modell des digitalisierten Signaturprozesses mit Nachweis der eIDAS-Konformität.
Beispiel 8: Observability, Anwendungslandkartefeedback
ADM-Phase: C → D (Informationssystem- → Technologie-Architektur) Funktionsbaustein: Observability Stack + Service Mesh & Observability
Szenario: Ein IT-Dienstleister will die Abhängigkeiten seiner 50+ Microservices visualisieren und Monitoring-Lücken identifizieren.
HOPEX-Umsetzung:
- Im Architecture Modul alle Microservices als Anwendungskomponenten anlegen.
- Die Kommunikationsbeziehungen (API-Calls, Events) als Datenflüsse modellieren.
- Für jeden Service den Observability-Reifegrad bewerten: Logging (ja/nein), Metriken (Prometheus?), Tracing (OpenTelemetry?).
- Heatmap generieren: Services ohne Tracing in Rot, Services mit vollständiger Observability in Grün.
HOPEX-Diagramm: Anwendungslandkarte mit Observability-Reifegrad
Ergebnis: Anwendungslandkarte mit Observability-Reifegrad und priorisierter Rollout-Liste für OpenTelemetry.
Beispiel 9: Ein- und Auszahlung, Make-or-Buy-Bewertungfeedback
ADM-Phase: E → F (Verproben → Entscheiden) Funktionsbaustein: Ein- und Auszahlung
Szenario: Ein Landesamt bewertet die Optionen für einen Bezahldienst: Eigenentwicklung, XBezahldienste oder kommerzieller Payment-Provider.
HOPEX-Umsetzung:
- Im IT Budget Planning drei Szenarien modellieren:
- Make: Eigenentwicklung auf Basis des Funktionsbausteins (Personal, Infrastruktur, Wartung).
- Buy: XBezahldienste als föderaler Basisdienst (Anbindungskosten, laufende Gebühren).
- Hybrid: Kommerzieller Payment-Provider (Stripe/Adyen) mit eigener Orchestrierungsschicht.
- Je Szenario die Kriterien bewerten: TCO (5 Jahre), Time-to-Market, Vendor-Lock-in, BSI-Konformität, Integrationskomplexität.
- Im Architecture Modul die Soll-Architektur je Szenario skizzieren und die Abhängigkeiten zum IAM und Workflow-Baustein modellieren.
- Entscheidungsmatrix als Architecture-Board-Vorlage exportieren.
HOPEX-Diagramm: Make-or-Buy-Entscheidungsmatrix (IT Budget Planning)
Ergebnis: Fundierte Make-or-Buy-Empfehlung mit TCO-Modell und Architektur-Skizze je Option.
Beispiel 10: Souveräner Datenaustausch, Datenfluss-Modellierungfeedback
ADM-Phase: C (Informationssystem-Architektur) Funktionsbaustein: Souveräner Datenaustausch + Registerdaten-Transfer
Szenario: Eine Behörde soll an einen europäischen Datenraum (z. B. Mobility Data Space) angebunden werden. HOPEX modelliert die Datenflüsse.
HOPEX-Umsetzung:
- Im Data Governance Modul die betroffenen Datenobjekte (Fahrzeugdaten, Halterinformationen) als „Business Data Objects" anlegen.
- Die Datenhoheit (Data Owner, Data Steward) je Datenobjekt dokumentieren und die DSGVO-Rechtsgrundlage zuordnen.
- Den Datenfluss modellieren: Quellregister → Registerdaten-Transfer → Souveräner Datenaustausch (Eclipse Dataspace Connector) → Datenraum.
- DSFA (Datenschutz-Folgenabschätzung) als verknüpftes Compliance-Artefakt im Risk-Modul anlegen.
HOPEX-Diagramm: Datenfluss mit DSGVO-Zuordnung (Data Governance)
Ergebnis: Vollständige Datenfluss-Dokumentation mit DSGVO-Nachweis als Grundlage für die Datenraum-Anbindung.
hub 4. HOPEX vs. alternative EA-Toolsfeedback
| Kriterium | HOPEX | LeanIX | Ardoq | ADOIT |
|---|---|---|---|---|
| TOGAF-Zertifizierung | Ja | Nein (eigenes Framework) | Nein | Ja |
| Metamodell-Flexibilität | Hoch | Mittel | Hoch | Mittel |
| BSI-Grundschutz-Integration | Plugin verfügbar | Manuell | Manuell | Plugin |
| BPMN-Modellierung | Integriert | Extern | Extern | Integriert |
| Daten-Governance (DSGVO) | Integriertes Modul | Eingeschränkt | Eingeschränkt | Eingeschränkt |
| Cloud-Deployment | SaaS + On-Premises | SaaS only | SaaS only | SaaS + On-Premises |
| Preis-Segment | Enterprise | Enterprise | Mid-Market | Mid-Market |
link 5. Bezug zu anderen Dokumentenfeedback
- TOGAF ADM für Behörden – Das Vorgehensmodell, das HOPEX werkzeugunterstützt umsetzt
- Kernprinzipien – Architekturwerte, die im HOPEX-Repository als Prinzipien-Objekte abgebildet werden
- Übersicht D-Stack Funktionsbausteine – Die Bausteine, die in HOPEX als Referenzkomponenten modelliert werden
- Best Practices für EAM – Vorbilder und Muster für die EA-Governance