Lernpfad Enterprise Architektur – visuell und erklärt

Format: 24 Wochen, berufsbegleitend 6–8 Stunden pro Woche
Ziel: Von Business-/IT-Grundlagen zu praxistauglicher Enterprise-Architecture-Arbeit
Ergebnis am Ende: Ein vollständiges EA-Portfolio mit Capability Map, Current-/Target-State, Roadmap, Governance-Modell, Risiko-/Security-Betrachtung und Entscheidungsvorlagen.
Erweiterung: Diese Version enthält zusätzliche Erklärkapitel, mehr bildliche Beispiele und ein großes Glossar mit über 130 praxisnah erklärten Begriffen.

Wie du diesen Lernpfad nutzt: Arbeite jede Woche an einem konkreten Fallbeispiel. Lies nicht nur Konzepte, sondern zeichne sie. Enterprise Architektur wird erst nützlich, wenn Menschen damit Entscheidungen treffen können.

Inhaltsverzeichnis

• 1. Visuelle Lernlandkarte
• 2. Was Enterprise Architektur eigentlich macht
• 3. Das zentrale EA-Denkmodell
• 4. Rollenbild: Wer macht was?
• 5. Voraussetzungen und Lernstrategie
• Zusatz: Vertiefte Erklärungen und Praxisbilder
• 6. 24-Wochen-Roadmap als Übersicht
• 7. Phase 0: Orientierung und Setup
• 8. Phase 1: Business, Strategie und Capabilities
• 9. Phase 2: EA-Grundlagen und Frameworks
• 10. Phase 3: Modellierung und Architekturkommunikation
• 11. Phase 4: Technologie, Daten, Integration und Security
• 12. Phase 5: Governance, Operating Model und Portfolio
• 13. Phase 6: Transformation, Roadmapping und Migration
• 14. Phase 7: Capstone-Projekt
• 15. Bildliche Vorlagen und Templates
• 16. Artefakt-Bibliothek
• 17. Toolchain
• 18. Skill-Matrix
• 19. Zertifizierungs- und Lernressourcen
• 20. Wöchentliche Routine
• 21. Bewertungsrubrik
• 22. Glossar
  • 22.1 Wie du das Glossar nutzt
  • 22.2 Begriffskarte als Lernschema
  • 22.3 Grundlagen
  • 22.4 Strategie
  • 22.5 Business Architecture
  • 22.6 Information & Data
  • 22.7 Applications
  • 22.8 Technology
  • 22.9 Security & Risk
  • 22.10 Governance
  • 22.11 Transformation
  • 22.12 Methoden
  • 22.13 Kommunikation
  • 22.14 Mini-Prüfung: Kannst du die Begriffe anwenden?
  • 22.15 Häufig verwechselte Begriffe
  • 22.16 Begriffe in einfacher Alltagssprache
• 23. Quellen und Referenzen
• Abschluss: Dein Zielbild nach 24 Wochen

1. Visuelle Lernlandkarte

Enterprise Architektur kann man sich wie Stadtplanung für ein Unternehmen vorstellen. Ein Gebäude entspricht einer Anwendung, Straßen sind Integrationen, Versorgungsnetze sind Daten- und Infrastrukturplattformen, Bauvorschriften sind Standards und Governance. Die Stadtplanung entscheidet nicht jede Türklinke, sorgt aber dafür, dass die Stadt langfristig funktioniert.

┌──────────────────────────────────────────────────────────────────────┐
│                          STRATEGIE                                  │
│       Ziele · Treiber · Risiken · Geschäftsmodell · Regulatorik      │
└──────────────────────────────┬───────────────────────────────────────┘
                               │ übersetzen in
┌──────────────────────────────▼───────────────────────────────────────┐
│                    BUSINESS ARCHITECTURE                             │
│       Capabilities · Value Streams · Prozesse · Organisation          │
└──────────────────────────────┬───────────────────────────────────────┘
                               │ braucht
┌──────────────────────────────▼───────────────────────────────────────┐
│                    INFORMATION & APPLICATIONS                         │
│       Daten · Anwendungen · Schnittstellen · Services                 │
└──────────────────────────────┬───────────────────────────────────────┘
                               │ laufen auf
┌──────────────────────────────▼───────────────────────────────────────┐
│                    TECHNOLOGY & PLATFORMS                             │
│       Cloud · Infrastruktur · Netzwerke · DevOps · Operations         │
└──────────────────────────────┬───────────────────────────────────────┘
                               │ abgesichert durch
┌──────────────────────────────▼───────────────────────────────────────┐
│                    SECURITY · GOVERNANCE · ROADMAP                    │
│       Prinzipien · Standards · Entscheidungen · Transformation        │
└──────────────────────────────────────────────────────────────────────┘

Was du daraus lernen sollst

Die Ebenen sind nicht getrennte Silos. Sie beantworten zusammen eine Kette von Fragen:

2. Was Enterprise Architektur eigentlich macht

Enterprise Architektur ist die Disziplin, mit der Organisationen ihre Strategie, Fähigkeiten, Prozesse, Daten, Anwendungen, Technologien und Governance so verbinden, dass Transformation planbar und steuerbar wird.

Einfaches Bild: EA als Übersetzungsmaschine

flowchart LR
    A[Strategische Ziele] --> B[Architektur-Fragen]
    B --> C[Optionen]
    C --> D[Entscheidungen]
    D --> E[Roadmap]
    E --> F[Umsetzung]
    F --> G[Messbare Ergebnisse]
    G --> A

Erklärung: Strategie allein verändert noch nichts. Projekte allein ergeben oft kein stimmiges Gesamtbild. EA verbindet beides: Sie macht sichtbar, welche Fähigkeiten, Daten, Anwendungen und Plattformen nötig sind, damit strategische Ziele tatsächlich umsetzbar werden.

Kernauftrag einer EA-Funktion

Eine Enterprise-Architecture-Funktion beantwortet typischerweise diese Fragen:

1. Wohin will die Organisation? Strategie, Geschäftsmodell, Ziele, Risiken, regulatorische Anforderungen.
2. Was kann die Organisation heute? Business Capabilities, Prozesse, Informationen, Systeme, technische Plattformen.
3. Was muss sich ändern? Zielarchitektur, Transformationsoptionen, Abhängigkeiten, Risiken, Kosten, Nutzen.
4. Wie wird gesteuert? Prinzipien, Standards, Architekturboard, Entscheidungsrechte, Portfolio-Governance.
5. Wie bleibt Architektur nutzbar? Wiederverwendbare Modelle, Architekturrepository, Metriken, Kommunikation.

Was EA nicht ist

3. Das zentrale EA-Denkmodell

Merke dir diese Kette. Fast jede EA-Aufgabe lässt sich darin einordnen:

Ziel → Capability → Prozess/Wertstrom → Daten → Anwendung → Technologie → Risiko → Roadmap

Beispiel: „Schnellere digitale Services“

Strategisches Ziel
  └─ Neue digitale Services 30 % schneller liefern
      └─ Benötigte Capability
          └─ Digital Product Launch Management
              └─ Value Stream
                  └─ Idee → Validierung → Entwicklung → Launch → Betrieb
                      └─ Daten
                          └─ Kundenprofil, Produktdaten, Consent, Nutzungsdaten
                              └─ Anwendungen
                                  └─ CRM, CMS, Identity, API Gateway, Analytics
                                      └─ Technologie
                                          └─ Cloud Platform, CI/CD, Event Streaming
                                              └─ Risiken
                                                  └─ Datenschutz, Vendor Lock-in, Legacy-Kopplung
                                                      └─ Roadmap
                                                          └─ API-Fassade, Datenprodukt, Plattformteam

Erklärung: Der Wert von EA entsteht, wenn du nicht bei einer Lösung startest, sondern bei einem Ziel. Statt „Wir brauchen Kubernetes“ fragst du: „Welche Business-Fähigkeit wollen wir verbessern, welche Einschränkungen haben wir, welche Optionen gibt es, und welche Entscheidung ist unter diesen Bedingungen sinnvoll?“

4. Rollenbild: Wer macht was?

                         ┌──────────────────────────┐
                         │   Enterprise Architect   │
                         │ Gesamtbild · Prinzipien  │
                         │ Roadmap · Governance     │
                         └────────────┬─────────────┘
                                      │ verbindet
        ┌─────────────────────────────┼─────────────────────────────┐
        │                             │                             │
┌───────▼────────┐           ┌────────▼────────┐           ┌────────▼────────┐
│Business Arch.  │           │Solution Arch.   │           │Data Arch.       │
│Capabilities    │           │konkrete Lösung  │           │Datenmodell      │
│Value Streams   │           │Patterns         │           │Governance       │
└───────┬────────┘           └────────┬────────┘           └────────┬────────┘
        │                             │                             │
        └───────────────┬─────────────┴───────────────┬─────────────┘
                        │                             │
                ┌───────▼────────┐           ┌────────▼────────┐
                │Technology Arch.│           │Security Arch.    │
                │Cloud/Platform  │           │Risiken/Controls  │
                │Standards       │           │Compliance        │
                └────────────────┘           └─────────────────┘

Merksatz: Enterprise Architecture ist nicht „der Chef aller Architekturen“, sondern die Rolle, die Zusammenhänge sichtbar macht und Entscheidungen über Domänen hinweg verbessert.

5. Voraussetzungen und Lernstrategie

Du musst nicht in allen Bereichen Expertin oder Experte sein. Du brauchst ein belastbares Grundverständnis in Business, IT, Kommunikation und Entscheidungslogik.

Empfohlenes Vorwissen

• Grundverständnis von Geschäftsprozessen, Wertschöpfung und Organisationsstrukturen.
• Solide IT-Grundlagen: Anwendungen, Datenbanken, APIs, Cloud, Netzwerke, Security-Basics.
• Erfahrung mit Projekten, Produkten, Requirements oder IT-Betrieb ist hilfreich.
• Fähigkeit, komplexe Themen visuell und schriftlich zu erklären.

Lernprinzipien

1. Von Strategie zu Umsetzung denken. Jedes Artefakt muss eine Entscheidung erleichtern.
2. Breite vor Tiefe, dann gezielt vertiefen. EA verbindet Domänen.
3. Immer mit einem Fallbeispiel arbeiten. Sonst bleibt Wissen abstrakt.
4. Artefakte iterativ verbessern. Jede Woche entsteht ein konkretes Ergebnis.
5. Stakeholder-Kommunikation trainieren. Gute EA ist verständlich, nicht nur korrekt.

Dein Fallbeispiel

Wähle ein Beispielunternehmen, das dich durch den Lernpfad begleitet. Geeignet sind:

• mittelständisches Handelsunternehmen mit E-Commerce-Modernisierung,
• Bank oder Versicherung mit regulatorischer und Legacy-Komplexität,
• Krankenhaus mit Daten-, Prozess- und Integrationsproblemen,
• öffentliche Verwaltung mit Digitalisierungsdruck,
• SaaS-Unternehmen mit Skalierungs- und Plattformfragen.

Zusatz: Vertiefte Erklärungen und Praxisbilder

Dieser Zusatzteil ist bewusst ausführlicher geschrieben. Er soll dir helfen, Enterprise Architektur nicht nur als Sammlung von Framework-Begriffen zu lernen, sondern als Denkweise. Lies diese Sektion am Anfang komplett und kehre später immer wieder zu ihr zurück, wenn ein Artefakt oder eine Rolle unklar wirkt.

1. EA in einem Satz

Enterprise Architektur beantwortet die Frage: Wie muss unser Unternehmen aufgebaut sein, damit Strategie, Geschäftsprozesse, Daten, Anwendungen, Technologie, Sicherheit und Veränderung zusammen funktionieren?

Das klingt groß, wird aber greifbar, wenn du EA als Übersetzungsarbeit verstehst:

Geschäftssprache                         Architektursprache                         Umsetzungssprache
────────────────                         ─────────────────                         ─────────────────
"Wir wollen schneller liefern"      →    Capability verbessern                 →    Plattform, APIs, Teams, Roadmap
"Wir müssen Kosten senken"          →    Portfolio rationalisieren             →    Systeme ablösen, Standards setzen
"Wir müssen Compliance erfüllen"    →    Risiken und Controls modellieren      →    IAM, Logging, Datenklassifikation
"Wir wollen Kundenerlebnis verbessern" →  Value Stream optimieren              →    Customer Journey, CRM, Analytics

Wichtig: EA ist nicht zuerst eine technische Disziplin. EA beginnt bei der Frage, welche Veränderung für das Unternehmen wertvoll ist. Technik ist ein wichtiger Teil der Antwort, aber nicht der Startpunkt.

2. Die Stadtplanungs-Metapher ausführlicher

Stell dir ein Unternehmen als Stadt vor:

Unternehmen als Stadt
├─ Geschäftsbereiche        = Stadtviertel
├─ Produkte und Services    = öffentliche Einrichtungen, Läden, Bahnhöfe
├─ Anwendungen              = Gebäude
├─ Daten                    = Wasser, Strom, Verkehrsflüsse, Informationen
├─ Schnittstellen/APIs      = Straßen, Brücken, Tunnel
├─ Infrastruktur/Cloud      = Fundament, Stromnetz, Abwasser, Telekommunikation
├─ Security/Compliance      = Bauordnung, Brandschutz, Polizei, Notfallpläne
├─ Governance               = Stadtplanung, Genehmigungen, Standards
└─ Roadmap                  = Bauplan über mehrere Jahre

Ein einzelnes Projekt baut vielleicht ein neues Gebäude. Enterprise Architektur fragt zusätzlich:

• Passt dieses Gebäude zum Stadtplan?
• Gibt es bereits ein Gebäude mit ähnlicher Funktion?
• Sind Straßen, Strom, Wasser und Sicherheit mitgedacht?
• Entsteht ein schöner Neubau, der später niemand warten kann?
• Wird dadurch ein Stadtviertel verbessert oder nur eine lokale Ausnahme geschaffen?

Diese Metapher hilft besonders bei Gesprächen mit Business-Stakeholdern. Statt über abstrakte Frameworks zu sprechen, kannst du erklären: „Wir entscheiden nicht jede technische Schraube, aber wir sorgen dafür, dass die Landschaft langfristig tragfähig bleibt.“

3. Die vier Hauptfragen jeder Architekturarbeit

Fast jedes Architekturgespräch lässt sich auf vier Fragen reduzieren:

1. Warum?       → Ziel, Treiber, Problem, Risiko, Nutzen
2. Was?         → Fähigkeiten, Prozesse, Daten, Anwendungen, Plattformen
3. Wie gut?     → Qualität, Kosten, Risiko, Reife, Standardkonformität
4. Wie weiter?  → Optionen, Entscheidung, Roadmap, Governance

4. Current State, Target State, Gap und Roadmap

Viele Lernende verwechseln diese Begriffe. Dieses Bild hilft:

HEUTE                         LÜCKE                         ZUKUNFT
Current State                 Gap                           Target State
─────────────                 ───                           ────────────
Was existiert?                Was fehlt?                    Was soll entstehen?
Was tut weh?                  Was ist zu ändern?            Welche Prinzipien gelten?
Was kostet/riskant ist?       Was ist abhängig?             Welche Zielarchitektur?

                    ↓
              ROADMAP / MIGRATION
              Welche Schritte in welcher Reihenfolge?

Current State ist keine Inventarliste um der Inventarliste willen. Er ist eine Diagnose. Du sammelst nur so viel Detail, wie du brauchst, um eine Entscheidung zu treffen.
Target State ist kein Wunschbild ohne Grenzen. Er beschreibt ein erreichbares Zielbild unter realen Bedingungen: Budget, Skills, Legacy, Zeit, Regulatorik.
Gap Analysis ist die Brücke: Welche Fähigkeiten, Daten, Anwendungen, Integrationen, Technologien oder organisatorischen Elemente fehlen?
Roadmap ist die Übersetzung in machbare Veränderungsschritte.

5. Modell, View und Artefakt – der Unterschied

Diese drei Wörter werden oft durcheinandergeworfen:

Bildlich: Das Modell ist die Datenbasis. Die View ist der Kartenausschnitt. Das Artefakt ist das gedruckte oder präsentierte Ergebnis.

Architektur-Repository
├─ Fakten: Anwendungen, Daten, Capabilities, Owner, Schnittstellen
├─ Beziehungen: App unterstützt Capability, Daten fließen von A nach B
└─ Views:
   ├─ CIO: Kosten, Risiko, Redundanzen
   ├─ Product Owner: betroffene Services und Abhängigkeiten
   ├─ Security: Schutzbedarf und Controls
   └─ Engineering: Integrationsmuster und Plattformstandards

6. Business Capability einfach erklärt

Eine Business Capability beschreibt, was ein Unternehmen können muss, unabhängig davon, wer es tut oder welches System es unterstützt.

Beispiele:

Kunden gewinnen
Kunden identifizieren
Angebote erstellen
Bestellungen abwickeln
Rechnungen stellen
Schäden prüfen
Lieferungen planen
Produkte entwickeln
Mitarbeiter befähigen
Risiken steuern

Eine Capability ist stabiler als ein Prozess oder eine Anwendung. Prozesse ändern sich, Teams werden umgebaut, Systeme werden ersetzt. Die Fähigkeit bleibt oft bestehen. Deshalb eignet sich eine Capability Map gut als „Landkarte“ für Strategie und Investitionen.

Typische Anfängerfehler:

7. Value Stream einfach erklärt

Ein Value Stream zeigt, wie Wert entsteht. Während Capabilities sagen, was die Organisation können muss, zeigt der Value Stream, wie Wert durch Schritte fließt.

Beispiel: Online-Kauf
Interesse erzeugen → Produkt finden → Warenkorb füllen → Bezahlen → Liefern → Support erhalten

Der Value Stream ist hilfreich, wenn du erklären willst, warum ein Architekturproblem nicht nur ein IT-Problem ist. Wenn zum Beispiel die Zahlung langsam ist, kann die Ursache im Payment Provider, im Fraud Check, im Datenmodell, im Monitoring oder in Verantwortlichkeiten liegen. EA hilft, diese Zusammenhänge sichtbar zu machen.

8. Von Ziel zu Architekturentscheidung

So sieht ein guter Denkfluss aus:

Business-Ziel
  ↓
betroffene Capability
  ↓
heutiger Schmerzpunkt
  ↓
Optionen
  ↓
Bewertung nach Nutzen, Risiko, Kosten, Zeit, Standards
  ↓
Architekturentscheidung
  ↓
Roadmap-Schritt
  ↓
Messgröße

Beispiel:

9. Architekturprinzipien ausführlicher

Ein Prinzip ist keine schöne Parole. Ein Prinzip muss helfen, wenn es einen Zielkonflikt gibt.

Schwaches Prinzip:

Wir nutzen moderne Technologie.

Stärkeres Prinzip:

API-first für fachliche Services
Aussage: Fachliche Funktionen werden über dokumentierte APIs bereitgestellt.
Begründung: Teams können entkoppelt arbeiten und Wiederverwendung wird möglich.
Konsequenz: Direkte Datenbankzugriffe zwischen Anwendungen sind nur als genehmigte Ausnahme erlaubt.
Metrik: Anteil neuer Integrationen über standardisierte APIs.

Gute Prinzipien bestehen aus:

• Name: leicht merkbar.
• Aussage: klar und überprüfbar.
• Begründung: warum dieses Prinzip existiert.
• Konsequenz: was Teams dadurch tun oder lassen müssen.
• Ausnahmen: wann Abweichungen erlaubt sind.
• Metrik: woran man erkennt, ob das Prinzip wirkt.

10. Application Portfolio verständlich lesen

Ein Application Portfolio ist wie eine Gebäudeliste in der Stadtplanung. Du willst wissen:

• Welche Gebäude gibt es?
• Wofür werden sie genutzt?
• Sind sie kritisch?
• Sind sie teuer?
• Sind sie modernisierungsbedürftig?
• Gibt es doppelte Gebäude für denselben Zweck?

Anwendung bewerten
├─ Business Fit: Unterstützt sie wichtige Fähigkeiten gut?
├─ Technical Fit: Ist sie technisch tragfähig?
├─ Cost Fit: Sind Kosten angemessen?
├─ Risk Fit: Gibt es Sicherheits-, Betriebs- oder Compliance-Risiken?
└─ Strategic Fit: Passt sie zur Zielarchitektur?

Eine typische Portfolioentscheidung:

11. Datenarchitektur verständlich erklärt

Datenarchitektur fragt nicht nur: „Welche Datenbank nutzen wir?“ Sie fragt:

Welche Daten sind für das Geschäft kritisch?
Wer besitzt sie fachlich?
Wo entstehen sie?
Wo werden sie kopiert?
Welche Qualität brauchen sie?
Welcher Schutzbedarf gilt?
Welche Datenprodukte oder Reports hängen daran?

Bildlich sind Daten das Wasser in der Unternehmensstadt. Wenn Leitungen und Zuständigkeiten unklar sind, kommt an manchen Stellen verschmutztes Wasser an, an anderen Stellen fehlt es, und niemand weiß, wer verantwortlich ist.

Datenprobleme zeigen sich oft als Business-Probleme: falsche Kundenansprache, langsame Berichte, widersprüchliche KPIs, manuelle Excel-Korrekturen, Compliance-Risiken.

12. Integration und APIs einfach erklärt

Integration ist das Straßennetz zwischen Anwendungen. Ohne saubere Integration entstehen Staus, Umwege und gefährliche Abkürzungen.

Schlechte Kopplung
App A → direkte DB von App B → Skript → Excel → manuelle E-Mail → App C

Bessere Kopplung
App A → API/Event → Integrationsplattform → App C

Typische Integrationsmuster:

13. Technologiearchitektur verständlich erklärt

Technologiearchitektur definiert die technischen Fundamente. Sie beantwortet zum Beispiel:

• Welche Cloud- oder Infrastrukturplattformen sind erlaubt?
• Wie werden Identitäten, Netzwerke, Secrets und Logs verwaltet?
• Welche Standards gelten für Deployment, Observability und Resilienz?
• Wie vermeiden wir zu viele Einzellösungen?

Bildlich: Technologiearchitektur ist das Fundament, die Stromversorgung, das Straßennetz und der Wartungsplan der Stadt. Ein schönes Gebäude ist wertlos, wenn es keinen Strom, keine Rettungswege und keine Wartung gibt.

14. Security-by-Design in EA

Security gehört nicht ans Ende. In EA wird Security früh mitgedacht:

Business-Ziel → Datenklassifikation → Bedrohungen → Controls → Architekturentscheidung → Betriebskontrolle

Beispiel:

15. Governance ohne Bürokratie

Architektur-Governance bedeutet nicht, dass ein Board alles blockiert. Gute Governance ist ein Entscheidungsprozess mit klaren Leitplanken.

leichtes Thema         → Self-Service-Checkliste
mittleres Thema        → Review mit Domain Architect
hohes Risiko/hohe Kosten → Architecture Board
Ausnahme               → dokumentierte Begründung + Ablaufdatum

Gute Governance erkennt man daran, dass Teams schneller gute Entscheidungen treffen, nicht daran, dass mehr Meetings entstehen.

16. Wie du EA-Diagramme erklärst

Ein Diagramm ist nur gut, wenn jemand damit eine Entscheidung treffen kann. Verwende beim Erklären diese Reihenfolge:

1. Kontext: Warum schauen wir darauf?
2. Legende: Was bedeuten Formen, Farben und Pfeile?
3. Kernaussage: Was ist die wichtigste Erkenntnis?
4. Entscheidung: Was müssen wir entscheiden?
5. Nächster Schritt: Was passiert danach?

Beispielsatz:

„Diese Map zeigt nicht alle Details, sondern die drei größten Engpässe im digitalen Onboarding. Rot markiert sind Capabilities mit hoher strategischer Bedeutung und niedriger Reife. Daraus folgt, dass wir zuerst Identity, Dokumentenprüfung und Kundenkommunikation priorisieren sollten.“

17. Häufige Denkfehler in Enterprise Architektur

18. Mini-Fallstudie: Digitales Schadenmanagement

Ausgangslage: Ein Versicherer möchte Schäden schneller bearbeiten. Heute kommen Dokumente per E-Mail, Bilder liegen in verschiedenen Systemen, Kundinnen müssen mehrfach nachfragen und Sachbearbeiter arbeiten mit manuellen Listen.

Business-Ziel:
Schadenbearbeitung von 10 Tagen auf 2 Tage reduzieren

Betroffene Capabilities:
Claims Intake · Document Management · Fraud Detection · Customer Communication · Payment Processing

Current-State-Probleme:
E-Mail-Eingang · manuelle Prüfung · doppelte Daten · keine Ende-zu-Ende-Sicht · hohe Fehlerquote

Target-State-Idee:
Omnichannel Intake · Dokumentenklassifikation · Workflow Engine · API-Schicht · Echtzeitstatus für Kunden

Roadmap:
1. Transparenz herstellen: Prozess, Systeme, Datenflüsse
2. Dokumentenplattform anbinden
3. API-Fassade vor Legacy-Systeme setzen
4. Workflow automatisieren
5. Altsysteme konsolidieren

Diese Mini-Fallstudie kannst du in jeder Woche wiederverwenden. Jede neue Methode wird daran konkreter: Capability Map, Value Stream, Application Portfolio, Data Domain Map, Security Controls, Governance und Roadmap.

19. EA-Spickzettel: Welches Artefakt hilft bei welcher Frage?

20. Lernmethode: Jede Woche ein „One-Pager“

Erstelle nach jeder Woche einen One-Pager. Dadurch lernst du, komplexe Inhalte zu verdichten.

One-Pager-Struktur
├─ Problem / Ziel
├─ wichtigste Erkenntnis
├─ Diagramm oder Tabelle
├─ Entscheidungsvorschlag
├─ Risiken / offene Fragen
└─ nächster Schritt

Der One-Pager ist eine der wichtigsten Übungen für angehende Enterprise Architects, weil du nicht nur analysierst, sondern kommunizierst.

6. 24-Wochen-Roadmap als Übersicht

Woche:  01 | 02 03 04 | 05 06 07 | 08 09 10 | 11 12 13 14 15 16 | 17 18 19 | 20 21 22 | 23 24
Phase:  SETUP | BUSINESS | FRAMEWORKS | MODELLIERUNG | DOMÄNENARCHITEKTUR | GOVERNANCE | ROADMAP | CAPSTONE
Output: Canvas | Capability Map | Prinzipien | Viewpoints | Daten/App/Tech/Sec | Board | Migration | EA-Dossier

7. Phase 0: Orientierung und Setup

Dauer: Woche 1
Ziel: Du legst dein Lernsystem, dein Fallbeispiel und dein Architekturrepository an.

Woche 1: EA-Canvas und Repository

Warum diese Woche wichtig ist

Viele EA-Initiativen scheitern, weil sie ohne klares Problem starten. In Woche 1 definierst du deshalb nicht nur einen Lernordner, sondern auch die Fragestellung, an der du alles übst.

Bildliche Vorstellung

EA-Repository
├─ 01_strategy                  → Warum verändern wir uns?
├─ 02_business_architecture      → Welche Fähigkeiten brauchen wir?
├─ 03_data_architecture          → Welche Daten sind kritisch?
├─ 04_application_architecture   → Welche Systeme unterstützen das Geschäft?
├─ 05_technology_architecture    → Welche Plattformen tragen die Systeme?
├─ 06_security_risk              → Welche Risiken und Controls gibt es?
├─ 07_governance                 → Wie werden Entscheidungen getroffen?
├─ 08_roadmap                    → Wie kommen wir vom Ist zum Ziel?
└─ 09_decision_records           → Warum haben wir was entschieden?

Aufgaben

1. Wähle ein Fallbeispiel mit echter Komplexität.
2. Formuliere eine Problemhypothese.
3. Lege dein Repository an.
4. Erstelle deinen ersten EA Canvas.

Artefakt der Woche: EA Canvas 1.0

Ergebnisprüfung

Du kannst in 3 Minuten erklären, warum dein Fallbeispiel Enterprise Architektur braucht und welche Entscheidungen durch EA verbessert werden sollen.

8. Phase 1: Business, Strategie und Capabilities

Dauer: Wochen 2–4
Ziel: Du lernst, Architektur von Geschäftszielen, Fähigkeiten und Wertströmen aus zu denken.

Woche 2: Strategie und Business Motivation

Kernidee

Architekturentscheidungen sollen nicht aus Technologievorlieben entstehen, sondern aus strategischen Zielen, Treibern, Einschränkungen und Risiken.

Treiber → Ziel → Outcome → Constraint → Architekturimplikation

Beispiel

Übung

Erstelle eine Business-Motivation-Map mit mindestens 5 Treibern, 5 Zielen und 5 Architekturimplikationen.

Erklärung für die Praxis

Wenn ein Stakeholder sagt „Wir brauchen eine neue Plattform“, frage zuerst: „Welches Ziel soll dadurch besser erreicht werden?“ Diese Rückfrage macht aus einer Lösungsidee eine Architekturfrage.

Woche 3: Business Capabilities und Value Streams

Kernidee

Eine Capability beschreibt, was ein Unternehmen können muss. Ein Prozess beschreibt, wie es konkret abläuft. Eine Anwendung ist nur ein Mittel, um eine Capability zu unterstützen.

Capability = Was wir können müssen
Prozess    = Wie wir es tun
System     = Womit wir es unterstützen
Team       = Wer es ausführt

Beispiel einer Capability Map

┌──────────────────────────────────────────────────────────────────────┐
│                         Kunden & Markt                               │
├──────────────┬──────────────┬──────────────┬────────────────────────┤
│ Lead Mgmt    │ Kampagnen    │ Kundenservice│ Kundenanalyse          │
│ 🟡 mittel    │ 🔴 schwach   │ 🟢 gut       │ 🔴 schwach             │
├──────────────┼──────────────┼──────────────┼────────────────────────┤
│ Angebot      │ Bestellung   │ Lieferung    │ Retouren               │
│ 🟢 gut       │ 🟡 mittel    │ 🟡 mittel    │ 🔴 schwach             │
└──────────────┴──────────────┴──────────────┴────────────────────────┘

Erklärung

Eine Capability Map hilft, Gespräche von Organisationspolitik zu entkoppeln. Statt „Team A gegen Team B“ diskutiert man: „Welche Fähigkeit ist strategisch wichtig, aber heute schwach?“ Genau dort entsteht Investitionslogik.

Übung

1. Erstelle 15–30 Capabilities für dein Fallbeispiel.
2. Bewerte jede Capability nach strategischer Wichtigkeit und aktueller Reife.
3. Markiere Top-5-Handlungsfelder.

Woche 4: Stakeholder, Value Streams und Business-Architektur

Kernidee

EA muss verschiedene Stakeholder verbinden. Dafür brauchst du eine klare Sicht auf Interessen, Konflikte und Informationsbedarf.

CEO/CFO        → Nutzen, Kosten, Risiko, Prioritäten
Business Lead  → Fähigkeiten, Prozesse, Time-to-Market
CIO/CTO        → Plattformen, technische Schulden, Standards
CISO/DPO       → Risiken, Compliance, Schutzbedarf
Product Teams  → Umsetzbarkeit, Abhängigkeiten, Patterns
Operations     → Stabilität, Monitoring, Betriebskosten

Value-Stream-Bild

Kundenbedarf → Beratung → Angebot → Bestellung → Lieferung → Nutzung → Support
      │            │          │           │           │          │        │
      ▼            ▼          ▼           ▼           ▼          ▼        ▼
   Insights      CRM       Pricing      ERP        Logistics  Portal   Ticketing

Übung

Erstelle eine Stakeholder Map und einen Value Stream. Markiere bei jedem Schritt:

• beteiligte Rollen,
• genutzte Daten,
• unterstützende Anwendungen,
• Pain Points,
• Risiken.

9. Phase 2: EA-Grundlagen und Frameworks

Dauer: Wochen 5–7
Ziel: Du verstehst, wie EA methodisch strukturiert wird, ohne dich in Framework-Dogmatismus zu verlieren.

Woche 5: TOGAF, ADM und Architekturdomänen

Bildliche Vorstellung des ADM-Zyklus

       ┌──────────────┐
       │  Strategie   │
       └──────┬───────┘
              ▼
┌─────────────────────────────┐
│ Architekturvision            │
└──────────────┬──────────────┘
               ▼
┌─────────────────────────────┐
│ Business Architecture        │
└──────────────┬──────────────┘
               ▼
┌─────────────────────────────┐
│ Data & Application           │
└──────────────┬──────────────┘
               ▼
┌─────────────────────────────┐
│ Technology Architecture      │
└──────────────┬──────────────┘
               ▼
┌─────────────────────────────┐
│ Opportunities & Roadmap      │
└──────────────┬──────────────┘
               ▼
┌─────────────────────────────┐
│ Governance & Change          │
└──────────────┘

Erklärung

Frameworks geben Sprache, Struktur und Vollständigkeit. Sie ersetzen aber nicht Urteilskraft. Ein guter Enterprise Architect nimmt aus Frameworks das, was Entscheidungsqualität verbessert, und vermeidet unnötige Bürokratie.

Übung

Ordne deine bisherigen Artefakte in Domänen ein: Business, Data, Application, Technology, Security, Governance.

Woche 6: Architekturprinzipien und Standards

Kernidee

Prinzipien sind Leitplanken für viele Einzelentscheidungen. Gute Prinzipien sind nicht banal, sondern helfen bei echten Zielkonflikten.

Beispiel für ein Prinzip

Entscheidungsbild

Neue Lösung?
   │
   ├─ Unterstützt sie Ziel-Capabilities? ─ Nein → Stop/Überarbeiten
   │
   ├─ Verwendet sie Standardplattformen? ─ Nein → Ausnahme begründen
   │
   ├─ Sind Datenverantwortung und Security klar? ─ Nein → Nacharbeiten
   │
   └─ Roadmap- und Betriebsfolgen verstanden? ─ Ja → Freigabe/Empfehlung

Woche 7: Current State, Target State und Gap Analysis

Kernidee

EA bewegt sich zwischen Ist, Ziel und Übergang. Ohne Current State weißt du nicht, wo du startest. Ohne Target State weißt du nicht, wohin du willst. Ohne Gap Analysis weißt du nicht, was sich ändern muss.

┌──────────────┐         ┌──────────────┐         ┌──────────────┐
│ Current State│  Gap    │ Transition   │  Gap    │ Target State │
│ Heute        │ ──────▶ │ 1–2 Jahre    │ ──────▶ │ Zielbild     │
└──────────────┘         └──────────────┘         └──────────────┘

Übung

Erstelle eine Gap-Tabelle:

10. Phase 3: Modellierung und Architekturkommunikation

Dauer: Wochen 8–10
Ziel: Du lernst, unterschiedliche Sichten für unterschiedliche Zielgruppen zu erstellen.

Woche 8: Viewpoints und „richtige Tiefe“

Kernidee

Ein Diagramm ist nur gut, wenn es zur Frage und Zielgruppe passt. Executives brauchen andere Sichten als Entwicklerteams.

Executive View      → Warum, Nutzen, Risiko, Investition
Business View       → Fähigkeiten, Wertströme, Operating Model
Solution View       → Komponenten, Schnittstellen, Datenflüsse
Technology View     → Plattformen, Netzwerke, Betriebsmodell
Security View       → Bedrohungen, Controls, Verantwortlichkeiten

Übung

Erstelle für dieselbe Problemstellung drei Sichten:

1. Eine Executive-Folie auf einer Seite.
2. Ein Business-Architekturdiagramm.
3. Ein Solution-/Technologiediagramm.

Woche 9: ArchiMate, C4 und BPMN als Werkzeugkasten

Wann nutzt du was?

C4-ähnliches Beispiel

[Customer]
    │ nutzt
    ▼
[Web/Mobile App] ──API──▶ [Customer Platform]
                           │
                           ├──▶ [CRM]
                           ├──▶ [Identity Provider]
                           └──▶ [Analytics Platform]

Erklärung

Die beste Notation ist die, die der Zielgruppe hilft. Nutze ArchiMate für strukturelle Unternehmenszusammenhänge, C4 für konkrete Systemlandschaften und BPMN für Prozessdiskussionen.

Woche 10: Storytelling und Entscheidungsunterlagen

Kernidee

EA-Artefakte müssen oft eine Entscheidung vorbereiten. Dazu braucht es eine klare Geschichte: Problem, Ziel, Optionen, Bewertung, Empfehlung, nächste Schritte.

1. Kontext: Warum sprechen wir darüber?
2. Problem: Was ist heute schwierig?
3. Ziel: Was muss besser werden?
4. Optionen: Welche Wege gibt es?
5. Bewertung: Kosten, Nutzen, Risiko, Abhängigkeiten
6. Empfehlung: Welche Option und warum?
7. Entscheidung: Was muss wer beschließen?

Übung

Schreibe ein Architecture Decision Record für eine wichtige Architekturentscheidung.

11. Phase 4: Technologie, Daten, Integration und Security

Dauer: Wochen 11–16
Ziel: Du verbindest Domänenarchitektur mit praxistauglichen Standards und Risiken.

Woche 11: Application Architecture und Portfolio

Application-Portfolio-Bild

                         Strategischer Wert
                         niedrig        hoch
Technische Fitness  ┌──────────────┬──────────────┐
hoch                │ Tolerieren   │ Investieren  │
                    │ beobachten   │ ausbauen     │
                    ├──────────────┼──────────────┤
niedrig             │ Eliminieren  │ Modernisieren│
                    │ ersetzen     │ entkoppeln   │
                    └──────────────┴──────────────┘

Erklärung

Nicht jede alte Anwendung muss sofort ersetzt werden. Entscheidend ist die Kombination aus Business-Wert, technischer Fitness, Risiko, Kosten und Veränderungsbedarf.

Übung

Bewerte 10 Anwendungen deines Fallbeispiels nach:

• Business Criticality,
• technischem Zustand,
• Kosten,
• Datenkritikalität,
• Integrationskomplexität,
• Modernisierungsoption.

Woche 12: Data Architecture

Datenlandkarte

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│ Customer     │     │ Product      │     │ Order        │
│ Domain       │     │ Domain       │     │ Domain       │
└──────┬───────┘     └──────┬───────┘     └──────┬───────┘
       │                    │                    │
       ▼                    ▼                    ▼
┌────────────────────────────────────────────────────────┐
│                 Analytics / Data Platform              │
└────────────────────────────────────────────────────────┘

Erklärung

Datenarchitektur beantwortet nicht nur „Wo liegen Daten?“, sondern auch: Wer besitzt sie? Wie gut sind sie? Wie fließen sie? Welche Bedeutung haben sie? Welche Risiken entstehen bei Nutzung, Kopie oder Analyse?

Übung

Erstelle eine Daten-Domain-Map mit Owners, Quellen, Konsumenten, Qualitätsproblemen und Schutzbedarf.

Woche 13: Integration Architecture

Integrationsmuster

Punkt-zu-Punkt:       System A ───── System B ───── System C
API-zentriert:        App ──▶ API Gateway ──▶ Services
Event-zentriert:      Producer ──▶ Event Broker ──▶ Consumers
Datenreplikation:     Source ──▶ ETL/ELT ──▶ Data Platform

Erklärung

Integration entscheidet über Veränderungsgeschwindigkeit. Punkt-zu-Punkt ist am Anfang schnell, wird aber bei vielen Systemen unübersichtlich. APIs schaffen klare Verträge. Events entkoppeln Systeme zeitlich. Datenpipelines unterstützen Analyse, sind aber kein Ersatz für operative Integration.

Übung

Zeichne deine wichtigsten 10 Schnittstellen und markiere, welches Muster jeweils genutzt wird.

Woche 14: Technology und Cloud Architecture

Plattformbild

┌─────────────────────────────────────────────────────────┐
│                    Produktteams                         │
└───────────────┬───────────────────────────────┬─────────┘
                │ nutzt                          │ nutzt
┌───────────────▼──────────────┐   ┌────────────▼─────────┐
│ Developer Platform           │   │ Data Platform         │
│ CI/CD · IaC · Observability   │   │ Lakehouse · Catalog   │
└───────────────┬──────────────┘   └────────────┬─────────┘
                │                               │
┌───────────────▼───────────────────────────────▼─────────┐
│ Cloud Landing Zone · Network · IAM · Security Baselines  │
└─────────────────────────────────────────────────────────┘

Erklärung

Cloud-Architektur ist nicht nur „Server in der Cloud“. Eine Enterprise-Sicht betrachtet Landing Zones, Identität, Netzwerk, Kostensteuerung, Betriebsmodell, Security-Baselines und Plattformfähigkeit.

Übung

Definiere Standardplattformen für dein Fallbeispiel: Compute, Integration, Daten, Identity, Observability, CI/CD, Secrets, Backup.

Woche 15: Security, Risk und Compliance

Risiko-zu-Control-Bild

Asset → Bedrohung → Schwachstelle → Risiko → Control → Nachweis

Beispiel

Erklärung

Security Architecture ist wirksam, wenn sie früh in Architekturentscheidungen eingebaut wird. Nachträgliche Security führt oft zu teuren Umbauten.

Woche 16: Domänen zusammenführen

Gesamtbild

Capability Map
    │ zeigt Bedarf
    ▼
Application Portfolio
    │ zeigt Systemabdeckung
    ▼
Data Domain Map
    │ zeigt Informationsabhängigkeiten
    ▼
Integration Map
    │ zeigt Kopplung
    ▼
Technology Standards
    │ zeigen Zielplattformen
    ▼
Risk Register
    │ zeigt Schutz- und Compliancebedarf
    ▼
Roadmap

Übung

Führe deine bisherigen Artefakte zu einem zusammenhängenden Architekturüberblick zusammen. Jede Verbindung muss eine Aussage haben, nicht nur eine Linie.

12. Phase 5: Governance, Operating Model und Portfolio

Dauer: Wochen 17–19
Ziel: Du lernst, wie Architekturentscheidungen in Organisationen wirksam werden.

Woche 17: Architecture Governance

Governance-Kreislauf

flowchart LR
    A[Prinzipien & Standards] --> B[Projekt-/Produktidee]
    B --> C[Architekturreview]
    C --> D{Konform?}
    D -->|Ja| E[Umsetzung]
    D -->|Nein| F[Ausnahme oder Anpassung]
    F --> C
    E --> G[Metriken & Lessons Learned]
    G --> A

Erklärung

Governance ist nicht Bürokratie, wenn sie gute Entscheidungen schneller macht. Sie wird bürokratisch, wenn sie nur kontrolliert, aber nicht hilft.

Übung

Definiere einen Architekturreview-Prozess mit Eingaben, Review-Kriterien, Entscheidungstypen und Eskalation.

Woche 18: Portfolio und technische Schulden

Portfolio Heatmap

Capability        Strategie  Reife  Systemabdeckung  Risiko  Investitionssignal
Kundenanalyse     hoch       niedrig schlecht         hoch    Jetzt investieren
Bestellung        hoch       mittel  mittel           mittel  Modernisieren
Finanzabschluss   mittel     hoch    gut              niedrig Erhalten
Retouren          mittel     niedrig schlecht         mittel  Selektiv verbessern

Erklärung

EA hilft, Investitionsentscheidungen über Projekte hinweg zu treffen. Eine Heatmap zeigt, wo Business-Wichtigkeit, schlechte Reife und hohes Risiko zusammenkommen.

Woche 19: EA Operating Model

Operating-Model-Bild

                  ┌─────────────────────┐
                  │ Architecture Board  │
                  └──────────┬──────────┘
                             │ entscheidet Leitplanken
┌────────────────────────────▼────────────────────────────┐
│ EA Core Team: Methoden · Repository · Prinzipien · Roadmap│
└───────────────┬──────────────────────────────┬──────────┘
                │ unterstützt                   │ koordiniert
     ┌──────────▼─────────┐          ┌─────────▼──────────┐
     │ Domain Architects  │          │ Product/Solution    │
     │ Business/Data/etc. │          │ Teams               │
     └────────────────────┘          └────────────────────┘

Übung

Beschreibe, welche Architekturentscheidungen zentral, föderiert oder teamnah getroffen werden.

13. Phase 6: Transformation, Roadmapping und Migration

Dauer: Wochen 20–22
Ziel: Du übersetzt Zielarchitektur in machbare Transformation.

Woche 20: Roadmaps und Transition Architectures

Roadmap-Bild

Heute                    6 Monate                 12 Monate                24 Monate
│                        │                        │                        │
├─ API-Fassade           ├─ Customer Data Domain  ├─ Event Broker          ├─ Legacy-Abbau
├─ IAM-Zielbild          ├─ Produktteam Pilot     ├─ Self-Service Analytics├─ Plattform-Skalierung
└─ App-Portfolio Scan    └─ Governance MVP        └─ Kostensteuerung       └─ Zielbetrieb

Erklärung

Eine Roadmap ist keine Wunschliste. Sie muss Abhängigkeiten, Sequenz, Risiken, Ressourcen und Nutzenlogik sichtbar machen.

Woche 21: Migrationsplanung und Abhängigkeiten

Abhängigkeitsbild

IAM-Zielbild ─────┐
                  ├─▶ API Gateway ──▶ Digital Customer Portal
Datenmodell ──────┘          │
                             └─▶ Analytics Use Cases
Cloud Landing Zone ─────────────▶ Plattformbetrieb

Übung

Erstelle eine Migrationsmatrix:

Woche 22: Business Case und Nutzenlogik

Nutzenbaum

Ziel: Time-to-Market verbessern
├─ weniger Systemkopplung
│  └─ API/Event-Integration
├─ bessere Datenqualität
│  └─ Customer Data Domain
├─ schnellere Deployments
│  └─ CI/CD und Plattformstandards
└─ klarere Entscheidungen
   └─ Architecture Governance

Erklärung

Ein Business Case in EA muss nicht jede Zahl perfekt beweisen. Er muss aber zeigen, warum bestimmte Investitionen logisch zusammengehören und welche Annahmen überprüft werden müssen.

14. Phase 7: Capstone-Projekt

Dauer: Wochen 23–24
Ziel: Du erstellst ein präsentationsfähiges EA-Dossier.

Woche 23: EA-Dossier zusammenführen

Struktur des Dossiers

1. Executive Summary
2. Ausgangslage und Problemhypothese
3. Strategische Ziele und Business Outcomes
4. Capability Map und Handlungsfelder
5. Current-State-Architektur
6. Target-State-Architektur
7. Gap Analysis
8. Roadmap und Transition Architectures
9. Governance-Modell
10. Risiken, Annahmen und Entscheidungen

Woche 24: Präsentation und Review

Präsentationslogik

Warum ändern? → Was ist heute schwierig? → Was ist das Zielbild?
→ Welche Optionen gibt es? → Welche Roadmap empfehlen wir? → Was muss entschieden werden?

Ergebnisprüfung

Dein Dossier ist gut, wenn ein Entscheider nach 20 Minuten versteht:

• welche Business-Ziele unterstützt werden,
• welche Architekturveränderungen notwendig sind,
• welche Abhängigkeiten und Risiken bestehen,
• welche Entscheidungen jetzt getroffen werden müssen.

15. Bildliche Vorlagen und Templates

15.1 EA One-Page Canvas

15.2 Architekturprinzip-Karte

┌───────────────────────────────────────────────┐
│ Prinzip: API-first Integration                │
├───────────────────────────────────────────────┤
│ Aussage: Neue Integrationen nutzen APIs/Events│
│ Warum: Entkopplung und Wiederverwendung       │
│ Konsequenz: Punkt-zu-Punkt nur als Ausnahme   │
│ Metrik: Anteil standardisierter Schnittstellen│
└───────────────────────────────────────────────┘

15.3 Architecture Decision Record

Titel: Entscheidung für Event Broker im Zielbild
Status: Vorgeschlagen / Beschlossen / Ersetzt
Kontext: Systeme sind eng gekoppelt, Echtzeitbedarf steigt
Optionen: Punkt-zu-Punkt, API-only, Event Broker
Entscheidung: Event Broker für relevante Domain Events
Konsequenzen: Neue Skills, Governance für Events, Betriebskosten
Review-Datum: in 6 Monaten

15.4 Capability Card

15.5 Architecture Review Checkliste

□ Unterstützt die Lösung ein klares Business-Ziel?
□ Sind betroffene Capabilities benannt?
□ Gibt es eine Current-/Target-State-Sicht?
□ Sind Datenowner und Schutzbedarf klar?
□ Werden Integrationsstandards eingehalten?
□ Sind Security und Compliance früh berücksichtigt?
□ Sind Betriebsmodell und Kosten verstanden?
□ Gibt es dokumentierte Entscheidungen und Ausnahmen?

16. Artefakt-Bibliothek

17. Toolchain

Empfehlung für den Lernpfad: Starte einfach. Markdown + draw.io/diagrams.net + Tabellen reichen für 80 % des Lernens. Spezialtools lohnen sich erst, wenn du Modellpflege, Repository, Reports und Governance im größeren Maßstab brauchst.

18. Skill-Matrix

19. Zertifizierungs- und Lernressourcen

Sinnvolle Lernfelder

• TOGAF / EA Frameworks: Struktur, ADM, Architecture Governance, Architekturdomänen.
• ArchiMate: Modellierungssprache für Business-, Application- und Technology-Sichten.
• BIZBOK / Business Architecture: Capabilities, Value Streams, Business Motivation.
• C4 Model: Softwarearchitektur verständlich darstellen.
• BPMN: Prozessmodellierung.
• Cloud Fundamentals: Landing Zones, IAM, Netzwerk, Kosten, Resilienz.
• Security Frameworks: Risiko, Controls, Cybersecurity Governance.
• Data Governance: Datenowner, Datenqualität, Datenkatalog, Data Products.

Lernreihenfolge

1. EA-Grundlagen und Business Architecture
2. Capability Mapping und Value Streams
3. ArchiMate/C4/BPMN als Visualisierung
4. Daten, Integration, Cloud, Security
5. Governance und Roadmapping
6. Zertifizierung oder Spezialisierung

20. Wöchentliche Routine

Mini-Retrospektive jede Woche

Beantworte drei Fragen:

1. Welche Entscheidung kann mein neues Artefakt verbessern?
2. Welche Annahme ist noch unbewiesen?
3. Welche Zielgruppe würde dieses Artefakt verstehen?

21. Bewertungsrubrik

22. Glossar

Dieses Glossar ist bewusst groß und praxisnah. Es erklärt nicht nur Begriffe, sondern auch, warum sie in Enterprise Architektur wichtig sind. Nutze es wie ein Nachschlagewerk: Wenn du ein Artefakt erstellst, prüfe die relevanten Begriffe und frage dich, ob du sie in deinem Fallbeispiel wirklich anwenden kannst.

22.1 Wie du das Glossar nutzt

• Beim Lesen: Markiere Begriffe, die du zwar kennst, aber noch nicht erklären könntest.
• Beim Üben: Wähle pro Woche 5–10 Begriffe und verwende sie in deinem EA-One-Pager.
• Im Projekt: Übersetze Framework-Sprache in Alltagssprache, damit Stakeholder die Bedeutung verstehen.
• Für Interviews: Übe, jeden Begriff in maximal 30 Sekunden mit einem Beispiel zu erklären.

22.2 Begriffskarte als Lernschema

Begriff
├─ Was bedeutet er einfach gesagt?
├─ Zu welcher EA-Domäne gehört er?
├─ Welche Entscheidung verbessert er?
├─ Welches Artefakt nutzt ihn?
└─ Was wäre ein Beispiel in meinem Fallunternehmen?

22.3 Grundlagen

22.4 Strategie

22.5 Business Architecture

22.6 Information & Data

22.7 Applications

22.8 Technology

22.9 Security & Risk

22.10 Governance

22.11 Transformation

22.12 Methoden

22.13 Kommunikation

22.14 Mini-Prüfung: Kannst du die Begriffe anwenden?

Beantworte diese Fragen schriftlich. Wenn du sie klar beantworten kannst, ist das Glossar nicht nur gelesen, sondern verstanden.

1. Welche drei Capabilities sind in deinem Fallbeispiel strategisch am wichtigsten?
2. Welche Anwendungen unterstützen diese Capabilities heute?
3. Welche Datenobjekte sind kritisch und wer sollte Data Owner sein?
4. Welche Integrationen sind riskant oder zu stark gekoppelt?
5. Welche Architekturprinzipien würden die meisten Entscheidungen verbessern?
6. Welche Risiken müssen in einem Architecture Review zwingend geprüft werden?
7. Welche drei Roadmap-Schritte bringen frühen Nutzen, ohne das Zielbild zu beschädigen?

22.15 Häufig verwechselte Begriffe

22.16 Begriffe in einfacher Alltagssprache

23. Quellen und Referenzen

Diese Referenzen sind als Orientierung gedacht. Für den Lernpfad reicht es, die Ideen praktisch anzuwenden, nicht jedes Framework vollständig auswendig zu lernen.

• The Open Group: TOGAF Standard, 10th Edition.
• The Open Group: ArchiMate Specification.
• Business Architecture Guild: BIZBOK Guide.
• ISO/IEC/IEEE 42010: Architecture description.
• NIST Cybersecurity Framework 2.0.
• SFIA Foundation: SFIA 9 skills framework.
• C4 Model von Simon Brown.
• BPMN 2.0 als Standardnotation für Geschäftsprozesse.

Abschluss: Dein Zielbild nach 24 Wochen

Nach diesem Lernpfad solltest du in der Lage sein, eine komplexe Unternehmenssituation strukturiert zu analysieren, visuell verständlich darzustellen und in eine realistische Transformationsroadmap zu übersetzen. Du musst nicht jede technische Detailfrage selbst beantworten. Aber du solltest wissen, welche Fragen gestellt werden müssen, welche Stakeholder beteiligt sind, welche Artefakte Entscheidungen verbessern und wie Architekturarbeit Wirkung im Unternehmen erzielt.