# Kapitel > Der freie Blick ins Buch: alle 32 Kapitel in sieben Teilen, jedes mit seinem Epigraph und seinen Lernzielen. Quelle: https://leanenterprisearchitecture.com/de/chapters/ ## Teil I. EA-Grundlagen Legt das begriffliche Fundament der Enterprise Architecture: Definitionen, Rollen, Kommunikation, Lean-Prinzipien und Reifegradbewertung. ### Kapitel 1. EA-Grundlagen (EA Foundation) > Nobody was ever promoted for a beautiful diagram. They were promoted for the decision it made possible. Lernziele: - Erklären, was Enterprise Architecture und Enterprise Architecture Management sind, und EAM von reiner Modellierung oder Dokumentation abgrenzen. - Die sechs Phasen des EA-Lebenszyklus beschreiben und mit der TOGAF ADM vergleichen. - Die vier Ebenen des EA-Metamodells (Business, Data, Application, Technology) benennen und erklären, wie Beziehungen über Ebenen hinweg Wert schaffen. - Das Konzept der Planungsebenen (strategisch, taktisch, operativ) anwenden, um für unterschiedliche Stakeholder-Gruppen die passende Granularität zu bestimmen. - Beurteilen, warum Business-IT-Alignment das zentrale Ziel der EA ist und wie EAM an angrenzende Disziplinen wie Portfoliomanagement und IT-Controlling anschliesst. ### Kapitel 2. Rollen in der Enterprise Architecture (Roles in Enterprise Architecture) > Your title doesn't make you an architect. The size of the decisions people trust you with does. Lernziele: - Das nexialistische Profil des Enterprise Architect beschreiben und erklären, warum ganzheitliches Denken wichtiger ist als tiefe Spezialisierung in einer einzelnen Domäne. - Enterprise Architect, Domain Architect, Solution Architect und Application Architect anhand von Geltungsbereich, Fokus und Planungshorizont unterscheiden. - Das Konzept des Architect Elevator erklären und begründen, warum das Übersetzen zwischen strategischem und technischem Publikum eine Kernkompetenz ist. - Zentrale, föderierte und hybride EA-Organisationsmodelle vergleichen und bestimmen, welches Modell zu einem gegebenen organisatorischen Kontext passt. - Das AKV-Modell (Aufgaben, Kompetenzen, Verantwortung) anwenden, um Rollengrenzen für Architekturfunktionen klar zu ziehen. ### Kapitel 3. EA-Kommunikation und Stakeholder-Management (EA Communication and Stakeholder Management) > If your stakeholders need a glossary to survive your presentation, the presentation was for you, not for them. Lernziele: - Das Power-Interest-Grid anwenden, um EA-Stakeholder zu segmentieren und je Quadrant eine passende Einbindungsstrategie zu definieren. - Das SCQA-Rahmenwerk und das Pyramidenprinzip erklären und bestimmen, wann sich welches zur Strukturierung von Architekturbotschaften eignet. - Zweck und Aufbau von Architecture Decision Records (ADRs) beschreiben und erklären, warum sie den Entscheidungskontext über die Zeit bewahren. - Eine stakeholderspezifische Kommunikation entwerfen, die dieselbe architektonische Einsicht für unterschiedliche Zielgruppen aufbereitet (C-Level, Product Owner, Entwicklungsteams). - Typische Fehlermuster bei der Einführung von EAM beurteilen und Strategien finden, EAM über den persönlichen Nutzen der Stakeholder zu begründen. ### Kapitel 4. Lean EAM > A complete model of a landscape nobody uses is not an achievement. It's a very thorough way of wasting a year. Lernziele: - Die sieben Erfolgsfaktoren für Lean EAM erklären und das Prinzip "Nutzen durch Nutzung" auf die Bewertung von EAM-Aktivitäten anwenden. - Typische Fehlermuster des klassischen EAM benennen (Überdokumentation, Analyseparalyse, falsch gesetzte Anreize) und beschreiben, wie Lean EAM jedes davon adressiert. - Das Drei-Geschwindigkeiten-Modell (Systems of Record, Differentiation, Innovation) beschreiben und erklären, wie sich Governance je Kategorie unterscheiden sollte. - Eine Minimum Viable EA entwerfen, die über schrittweise Erweiterung innerhalb von drei Monaten sichtbare Ergebnisse liefert. ### Kapitel 5. EAM-Reifegrad (EAM Maturity) > A maturity model won't fix your architecture. It will just stop you from lying to yourself about how good it already is. Lernziele: - Hanschkes fünfstufiges EAM-Reifegradmodell (Initial, Aufbau, Transparenz, Planung, Steuerung) beschreiben und erklären, was jede Stufe kennzeichnet. - Hanschkes EAM-spezifisches Reifegradmodell mit CMMI vergleichen und bestimmen, wann welches Modell angebracht ist. - Die fünf Bewertungsdimensionen (Dokumentation, Prozesse, Organisation, Wirksamkeit, Werkzeugunterstützung) für eine strukturierte Selbsteinschätzung nutzen. - Die kritischen Erfolgsfaktoren jedes Stufenübergangs benennen, besonders den Sprung von Stufe 2 auf Stufe 3, wo EAM seinen Wert belegen muss. ## Teil II. Strategie und Transformation Verbindet Enterprise Architecture mit organisatorischem Wandel, von der Transformationsplanung bis zum Change Management. ### Kapitel 6. Enterprise Transformation > A target state nobody revisits is not a plan, it is a souvenir. Lernziele: - Das Verhältnis von Geschäftsstrategie und IT-Strategie erklären und die sechs Schritte der IT-Strategieentwicklung beschreiben. - Eine Gap-Analyse anwenden, um Ist- und Soll-Architektur zu vergleichen und fehlende Capabilities, Redundanzen und technische Schulden aufzudecken. - Die sechs Migrationsmuster für Altsysteme (Retain, Wrap, Refactor, Rehost, Replatform, Retire) vergleichen und bewerten, welches zu einem gegebenen Anwendungsfall passt. - OKR und KPI unterscheiden und erklären, wann sich welches Instrument für Transformation und wann für den Betrieb eignet. - Die achtstufige MCDA-Methode anwenden, um konkurrierende Architekturoptionen über gewichtete Kriterien und strukturierte Bewertung zu beurteilen. ### Kapitel 7. Change Management > Culture doesn't eat strategy for breakfast. It quietly ignores it until the strategy gives up. Lernziele: - Beckhards Modell (Current State, Transition State, Future State) erklären und die Veränderungsformel (D x V x F > R) zur Diagnose der Veränderungsbereitschaft anwenden. - Drei klassische Change-Management-Modelle vergleichen (Veränderungskurve nach Kübler-Ross und Streich, Kotters Acht-Stufen-Modell, St. Galler Management-Modell) und das für eine gegebene Lage passende bestimmen. - Die sieben Phasen der Veränderungskurve nach Kübler-Ross und Streich beschreiben und je Phase die angemessene Führungsreaktion benennen. - Analysieren, wie Kultur den Transformationserfolg prägt, und beurteilen, warum "culture eats strategy for breakfast" auch für Architekturvorhaben gilt. - Eine Change-Kommunikation entwerfen, die verschiedene Stakeholder-Gruppen über Architekturnarrative, visuelles Storytelling und aktives EA-Marketing erreicht. ## Teil III. Architekturdomänen Behandelt die sechs zentralen Architekturdomänen: Business, Capabilities, Information, Applikationslandschaft, Daten und Integration. ### Kapitel 8. Business Architecture > Designing an IT landscape without understanding the business is just very confident guessing with a bigger budget. Lernziele: - Business Architecture von Enterprise Architecture abgrenzen und ihre einander ergänzenden Rollen erklären - Die vier Kernelemente der Business Architecture beschreiben: Capabilities, Value Streams, Organisation und Information - Das Business Model Canvas anwenden, um zu beschreiben, wie eine Organisation Wert schafft, liefert und abschöpft - Erklären, wie Porters Wertkette Aktivitäten in primäre und unterstützende Kategorien einteilt und damit Investitionen priorisierbar macht - Die wechselseitige Beziehung des Business-IT-Alignments erkennen, einschliesslich der Frage, wie Conways Gesetz Architekturentscheidungen prägt ### Kapitel 9. Capability Mapping > A capability map answers the one question most leadership teams can't agree on: what does this company actually do? Lernziele: - Die dreistufige Capability-Hierarchie (L1-Domänen, L2-Planungs-Capabilities, L3-Umsetzungs-Capabilities) anwenden, um eine Capability Map zu strukturieren - Capability-Definitionen gegen Qualitätskriterien prüfen, etwa Ergebnisorientierung, Stabilität und einheitliche Abstraktionsebene - Einen Capability-Mapping-Workshop anhand des sechsstufigen Vorgehens aus diesem Kapitel gestalten - Erklären, wie Capability Maps Prozesse, Applikationen und Daten verknüpfen und so zum Rosetta Stone des Business-IT-Alignments werden - Heatmap-Bewertungen nutzen, um strategische Prioritäten und Investitionsbedarf über eine Capability-Landschaft hinweg zu erkennen ### Kapitel 10. Informationsarchitektur (Information Architecture) > A knowledge base without information architecture is just a landfill with a search box. Lernziele: - EA-orientierte Informationsarchitektur (Geschäftsobjekte, CRUD-Matrizen, Datenflüsse) von inhaltsorientierter Informationsarchitektur (Navigation, Beschriftung, Metadaten) unterscheiden - CRUD-Matrizen anwenden, um Datenhoheit, Redundanzen und Integrationsbedarf über Applikationen hinweg sichtbar zu machen - Geschäftsobjektmodellierung auf drei Granularitätsebenen beschreiben (Kerngeschäftsobjekte, Geschäftsobjekte, Informationsobjekte) - Erklären, wie Taxonomien und kontrollierte Vokabulare die Auffindbarkeit von Information und deren Governance stützen - Die wichtigsten IA-Ergebnisse benennen und ihre Rolle in Bebauungsplanung und Integrationsentwurf erklären ### Kapitel 11. Bebauungsplanung der Applikationslandschaft (Application Landscape Planning) > You don't have 400 applications because you needed 400. You have them because retiring one was always someone else's problem. Lernziele: - Die Methodik der Bebauungsplanung und ihre drei Grundziele erklären: Business-Alignment, Behebung von Schmerzpunkten und IT-Readiness - Hanschkes Analysemuster in den fünf Kategorien, die dieses Buch als RIOFT abkürzt (Redundanzen, Inkonsistenzen, organisatorische Verantwortung, Erfüllung fachlicher Anforderungen, technische Optimierung), auf die heutige Applikationslandschaft anwenden - Das iterative Vorgehen zum Entwurf einer Soll-Landschaft beschreiben, vom fachlichen Kontext bis zur Bewertung von Planungsszenarien - Applikationen über die Vier-Quadranten-Portfoliobewertung einordnen (strategisch, gefährdet, unterstützend, auslaufend) - Applikationen nach Kritikalität klassifizieren (safety, mission, business critical, nicht kritisch) und erklären, wie RTO und RPO die Resilienzplanung steuern - Das TIME-Modell (Tolerate, Invest, Migrate, Eliminate) anwenden, um Rationalisierungsstrategien für ein Applikationsportfolio zu bestimmen - Big-Bang- und evolutionäre Migrationsstrategien vergleichen und erklären, wie Roadmaps die Lücke zwischen Ist- und Soll-Landschaft schliessen ### Kapitel 12. Datenarchitektur (Data Architecture) > Everyone wants to be data-driven. Almost nobody wants to agree on what 'customer' means. Lernziele: - Die drei Ebenen der Datenarchitektur (konzeptionell, logisch, physisch) beschreiben und erklären, welche davon Enterprise Architects primär betreffen - Das Rollenmodell der Data Governance (Data Trustee, Data Owner, Data Steward, Data Custodian) und seine organisatorischen Folgen erklären - Zweck des Master Data Management, das Konzept des Golden Record und die vier MDM-Stile erklären (Registry, Konsolidierung, Koexistenz, zentral) - Moderne Muster der Datenarchitektur vergleichen: Data Warehouse, Data Lake, Data Lakehouse, Data Mesh und Data Fabric - Die sechs Dimensionen der Datenqualität (Korrektheit, Vollständigkeit, Konsistenz, Aktualität, Gültigkeit, Eindeutigkeit) zur Beurteilung des Datenzustands anwenden - Die architektonischen Folgen von KI-Workloads für die Dateninfrastruktur erkennen, einschliesslich Vektordatenbanken, Feature Stores und Data Lineage - Die Rolle von Datenlöschung und Systemstilllegung auf EA-Ebene erklären, einschliesslich Aufbewahrungsfristen, Stilllegungsdisziplin und belegbarer Löschung ### Kapitel 13. Integrationsarchitektur (Integration Architecture) > Ten systems wired straight to each other need forty-five connections, and every one of them was somebody's quick fix. Lernziele: - Integrationsmuster vergleichen (Punkt-zu-Punkt, Hub-and-Spoke, ereignisgetrieben, API-led, iPaaS) und ihre Zielkonflikte je Szenario abwägen - Prinzipien der API-Governance erklären, einschliesslich API-First-Entwurf, Lifecycle-Management und der Rolle von API-Gateways - Muster ereignisgetriebener Architektur beschreiben (Event Notification, Event-Carried State Transfer, Event Sourcing, CQRS) und ihre Anwendungsfälle benennen - Integrationsszenarien unterscheiden (A2A, B2B, B2C, IoT) und je Szenario passende Muster bestimmen - Praktiken der Integrations-Governance anwenden, einschliesslich Architekturreview neuer Integrationen und Dokumentation im EA-Repository ## Teil IV. Governance und Steuerung Beschreibt die Mechanismen, die Architekturentscheidungen tragfähig machen: Compliance-Rahmenwerke, Portfoliomanagement und IT-Controlling. ### Kapitel 14. Governance und Compliance (Governance and Compliance) > Governance built to say 'no' gets what it deserves: a company that stops asking. Lernziele: - Die fünf Bestandteile eines EA-Governance-Rahmenwerks beschreiben: Architekturfundament, Prozesse, Kompetenzmanagement, Führungsstrukturen und Kennzahlen - Governance-Rahmenwerke vergleichen (TOGAF, COBIT, ITIL, SAFe) und erklären, wie man Elemente pragmatisch kombiniert, statt ein Rahmenwerk vollständig zu übernehmen - Die acht Formen technischer Schulden benennen und Strategien erklären, sie sichtbar zu machen und systematisch abzubauen - Das Modell der Three Lines of Defense anwenden, um Risikoverantwortung, Überwachung und Prüfung im EA-Kontext zu trennen - EA-Organisationsformen beurteilen (zentral, dezentral, föderiert) und ihre Zielkonflikte für die Wirksamkeit der Governance abwägen ### Kapitel 15. Projektportfoliomanagement (Project Portfolio Management) > The most important word in portfolio management is 'stop,' and it's the one nobody in the room wants to say. Lernziele: - Die Rolle der Enterprise Architecture in Portfolioentscheidungen beschreiben, einschliesslich Konformitätsprüfung, Auswirkungsanalyse und der Regel "one in, one out" - Methoden der Portfoliopriorisierung mit gewichteten Kriterien anwenden, etwa strategische Passung, Architekturkonformität und Kosten-Nutzen - Gewichtete Mehrkriterienbewertung mit Weighted Shortest Job First (WSJF) vergleichen und Stärken und Grenzen beider Ansätze erklären - Lean Demand Management als Mechanismus erklären, neue IT-Anforderungen gegen Capability Map und Soll-Landschaft zu prüfen - Portfoliokategorien unterscheiden (strategisch, regulatorisch, operativ, Innovation) und beurteilen, ob ein Portfolio ausgewogen ist ### Kapitel 16. IT-Controlling (IT Controlling) > A dashboard full of IT costs with no link to business outcomes is just an expensive way to feel informed. Lernziele: - Die TCO-Analyse erklären und zum Vergleich von Investitionsalternativen anwenden, einschliesslich der Verschiebung von CapEx zu OpEx in der Cloud - Das Modell Run, Change, Innovate anwenden, um IT-Ausgaben einzuordnen und den Spielraum für strategische Investitionen zu bestimmen - EAM-spezifische Controlling-Kennzahlen beschreiben (Bebauungsplanfit, Standardisierungsgrad, Dokumentationsgrad) und ihre Rolle in der Architektursteuerung erklären - Chargeback und Showback für die IT-Kostenverrechnung vergleichen und ihre organisatorischen Folgen abwägen - Erkennen, wie EA-Daten das IT-Controlling von einer rein finanziellen Übung zu einem fachlich orientierten Steuerungsinstrument machen ## Teil V. Methoden und Werkzeuge Enterprise Architecture findet nicht im Abstrakten statt. Sie braucht eine gemeinsame Sprache, einen strukturierten Prozess und die passenden Instrumente, um strategische Absicht in operative Realität zu übersetzen. Teil V stellt die Methoden, Modellierungssprachen und Werkzeuge vor, mit denen Enterprise Architects tatsächlich arbeiten, kein akademischer Überblick, sondern das Repertoire, zu dem man greift, wenn Komplexität kommuniziert, Entscheidungen gesteuert und Transformation geplant werden muss. ### Kapitel 17. TOGAF > Adopting TOGAF whole is the safest career decision and the slowest architecture decision available to you. Lernziele: - Die Entwicklung von TOGAF von TAFIM über Version 9.2 bis zur modularen Version 10 beschreiben und die Bedeutung der Neustrukturierung erklären. - Zweck, wesentliche Eingaben, Aktivitäten und Ergebnisse jeder ADM-Phase erklären und zeigen, wie das Requirements Management alle Phasen verbindet. - Die Bestandteile des TOGAF Architecture Repository beschreiben und erklären, wie das Enterprise Continuum wiederverwendbare Architekturbausteine ordnet. - Das Konzept des ADM Tailoring anwenden, um das Rahmenwerk an Organisationsgrösse und Reifegrad anzupassen. - Stärken und Grenzen von TOGAF beurteilen und das Verhältnis zu ergänzenden Rahmenwerken wie Zachman, ArchiMate und COBIT erklären. ### Kapitel 18. Zachman Framework > A 36-cell grid is a brilliant way to organize your thinking and a spectacular way to spend two years filling in boxes nobody reads. Lernziele: - Die Entstehung des Zachman Framework und die Ingenieursanalogie erklären, die ihm zugrunde liegt. - Die 6x6-Matrix mit allen sechs Perspektiven und sechs Fragewörtern beschreiben und erklären, wofür jede Zelle steht. - Das Zachman Framework als Vollständigkeitscheckliste für die Architekturdokumentation anwenden. - Das Zachman Framework (Taxonomie) von TOGAF (Methodik) unterscheiden und erklären, wie sich beide ergänzen. - Die heutige Relevanz des Rahmenwerks und seine Grenzen für die tägliche Architekturarbeit beurteilen. ### Kapitel 19. ArchiMate > The point of ArchiMate was never a prettier diagram. It was to stop three teams meaning three different things by the same box. Lernziele: - Die Ebenenstruktur von ArchiMate (Business, Application, Technology) beschreiben und erklären, wie die zusätzlichen Ebenen (Strategy, Implementation and Migration, Motivation) den Kern erweitern. - Für ein gegebenes Modellierungsvorhaben die passenden ArchiMate-Elementtypen und Beziehungstypen bestimmen. - ArchiMate-Viewpoints nach Zweck (Design, Decide, Inform), Inhalt und Geltungsbereich unterscheiden. - Erklären, wann ArchiMate und wann eine domänenspezifische Notation wie BPMN, UML oder C4 angebracht ist. - Die ebenenübergreifenden Serving- und Realization-Beziehungen nutzen, um von strategischen Zielen bis zu Infrastrukturkomponenten nachzuverfolgen. ### Kapitel 20. Prozess- und Entscheidungsmodellierung (Process and Decision Modeling) > Bury your pricing rules inside the process diagram and every price change becomes a modeling project. Lernziele: - Die BPMN-Kernelemente (Ereignisse, Aktivitäten, Gateways, Pools, Lanes) und ihre Rolle in der Prozessmodellierung beschreiben. - BPMN und DMN vergleichen und erklären, wie sie sich über das Muster der Business Rule Task ergänzen. - Die drei BPMN-Modellierungsebenen (deskriptiv, analytisch, ausführbar) anwenden und die für die EA-Arbeit passende Ebene bestimmen. - Erklären, wann Entscheidungstabellen mit welcher Hit Policy (Unique, First, Collect) angebracht sind und wie sie prüfbare Geschäftsentscheidungen stützen. - Beurteilen, wann BPMN einem einfachen Flussdiagramm vorzuziehen ist, gemessen an Semantik, Wartbarkeit und Zusammenarbeit. ### Kapitel 21. Software- und Systemmodellierung (Software and System Modeling) > Systems are not confusing because the notation was too loose. They are confusing because nobody drew them at all. Lernziele: - UML, SysML und C4 nach Zweck, Formalisierungsgrad, Zielgruppe und typischen EA-Anwendungsfällen vergleichen. - Die vier Ebenen des C4-Modells (Context, Container, Component, Code) anwenden und die für Stakeholder und Entscheidung passende Ebene bestimmen. - Die für Enterprise Architecture relevantesten UML-Diagrammtypen benennen (Komponenten, Deployment, Sequenz) und erklären, wann jeder Nutzen stiftet. - Den Ansatz Architecture as Code mit Werkzeugen wie Structurizr, PlantUML und Mermaid beschreiben und seinen Nutzen für Versionierung und Review erklären. ### Kapitel 22. EA-Metamodelle (EA Metamodels) > Every organization already has a metamodel. Most just never wrote it down, which is why nobody agrees on what an 'application' is. Lernziele: - Den Zweck eines EA-Metamodells erklären und begründen, warum es Klarheit und Governance verbessert, wenn man es explizit macht. - Das TOGAF Content Framework, Hanschkes vierschichtiges Metamodell und BIZBOK nach Umfang, Komplexität und praktischer Anwendbarkeit vergleichen. - Ein minimales eigenes Metamodell entwerfen, ausgehend von Kernentitäten (Applikationen, Capabilities, Prozesse, Technologien) und erweitert entlang echter Stakeholder-Fragen. - Beschreiben, wie Entitäten und Beziehungen des Metamodells die Grundlage für Governance-Kennzahlen, Auswirkungsanalysen und Portfoliomanagement bilden. - Typische Fallstricke benennen (Überkonstruktion, fehlende ebenenübergreifende Beziehungen, ein als statisch behandeltes Metamodell) und erklären, wie man sie vermeidet. ### Kapitel 23. EA-Visualisierungen (EA Visualizations) > A good diagram makes its point before the reader decides to stop reading. Lernziele: - Für eine gegebene Stakeholder-Frage und Zielgruppe den passenden EA-Visualisierungstyp bestimmen (Bebauungsplan, Portfoliografik, Lebenszyklusgrafik, Informationsflussgrafik, Roadmap). - Die drei Varianten der Bebauungsplangrafik beschreiben (fachlich, technisch, typisiert) und erklären, wann welche angebracht ist. - Visualisierungen auswählen, indem Frage, Zielgruppe und nötiger Detailgrad auf den Visualisierungstyp abgebildet werden. - Die Zielkonflikte zwischen statischen Diagrammen und interaktiven Dashboards für verschiedene Kommunikationssituationen abwägen. ### Kapitel 24. EA-Werkzeuge (EA Tooling) > You don't have a tooling gap. You have a discipline gap, and no license fixes that. Lernziele: - Die vier Werkzeugkategorien vergleichen (spezialisierte Plattformen, Diagrammwerkzeuge, Architecture as Code, leichtgewichtige Ansätze) und bestimmen, wann welche passt. - Auswahlkriterien anwenden (Organisationsgrösse, EA-Reifegrad, Budget, Betriebsmodell), um für einen gegebenen Kontext einen Werkzeugansatz zu empfehlen. - Die Rolle von Architecture as Code (Structurizr, PlantUML, Mermaid, Policy as Code, Developer Portals) in der heutigen EA-Praxis beschreiben. - CMDB und EA-Repository nach Zweck und Inhalt unterscheiden und erklären, wie sie sich ergänzen. ### Kapitel 25. Synthese: Methoden und Werkzeuge in der Praxis (Synthesis: Methods and Tools in Practice) > The best architects steal from every framework and pledge loyalty to none. ## Teil VI. Technologie und KI Behandelt die technologische Dimension der Enterprise Architecture, von der Strategie über den Betrieb bis zu den Mustern, dazu Grundlagen und Praxis der KI. ### Kapitel 26. Technologiestrategie (Technology Strategy) > Every technology decision is an organizational decision wearing a technical costume. Lernziele: - Das Konzept des kybernetischen Unternehmens erklären und seine Herkunft von Beers Viable System Model über Agile und DevOps bis zu Roths Triad of Intelligence nachzeichnen. - Die vier Paradigmen der Technologielieferung (klassische IT, Agile, DevOps, kybernetisch) nach Geltungsbereich, Feedbackmechanismen und Governance vergleichen. - Das fünfstufige Automatisierungsmodell ("automate last") anwenden, um Technologieinitiativen zu beurteilen. - Die Make-or-Buy-Entscheidung über die vier Optionen analysieren (kaufen, komponieren, erweitern, bauen) und gegen die strategische Differenzierung abgleichen. - Die vier Domänen digitaler Souveränität beschreiben (Infrastruktur, Technologie, Daten, Applikation) und erklären, wie DORA, NIS2, DSGVO und das Schweizer DSG Souveränität zur Architekturfrage machen. - Beschreiben, wie Value Streams, produktorientierte Lieferung und Team Topologies die Organisationsstruktur mit den Technologieergebnissen verbinden. ### Kapitel 27. Technologiebetrieb (Technology Operations) > Speed and safety were never a trade-off. That was the story slow organizations told themselves. Lernziele: - Die vier DORA-Kennzahlen beschreiben und erklären, wie sie Geschwindigkeit und Stabilität der Softwarelieferung zugleich messen. - Die sechs Betriebsmodelle für Produktionsverantwortung vergleichen (von "Ops Runs It" bis SRE) und bestimmen, welches zu Workload und Reifegrad passt. - Das Konzept Platform Engineering erklären, einschliesslich Golden Paths, der mitwachsenden Plattform und Developer Experience als Erfolgskennzahl. - Cloud-Servicemodelle (IaaS, CaaS, PaaS, FaaS, SaaS), Bezugsstrategien (Cloud Only, Cloud First, Cloud Smart) und das Cloud-Foundation-Rahmenwerk analysieren. - Die sechs Capabilities und fünf Betrachtungswinkel des Cloud Operating Model anwenden, um die Cloud-Reife einer Organisation zu beurteilen. ### Kapitel 28. Technologiemuster (Technology Patterns) > There are no best practices, only trade-offs someone forgot to tell you about. Lernziele: - Das siebenschichtige Defense-in-Depth-Sicherheitsmodell beschreiben und die Prinzipien der Zero Trust Architecture erklären. - Die sechs Architekturmuster benennen (geschichtet, Serverless, Hybrid Cloud, Hochverfügbarkeit, Scale-out, Microservices) und bewerten, welches zu Workload und Kontext passt. - Qualitätsmerkmale vergleichen (Skalierbarkeit, Zuverlässigkeit, Verfügbarkeit, Sicherheit, Wartbarkeit) und ihre Zielkonflikte erklären. - Architecture Building Blocks (ABBs) von Solution Building Blocks (SBBs) unterscheiden und erklären, wie sie abstrakte Anforderungen mit konkreter Umsetzung verbinden. - Das Konzept des Technology Radar anwenden, um Technologie-Governance und Innovationsentscheidungen zu strukturieren. - Die Konvergenz von OT und IT erklären und die Rolle von ISA-95 als Brücke zwischen Betriebs- und Informationstechnik beschreiben. ### Kapitel 29. KI-Grundlagen (AI Fundamentals) > The model does not know when it is wrong, and that is now your architecture problem. Lernziele: - Die KI-Hierarchie erklären (KI, Machine Learning, Deep Learning, Generative KI) und konzeptionell beschreiben, wie LLMs funktionieren. - Die fünf zentralen Grenzen heutiger LLMs benennen und erklären, warum menschliche Aufsicht unverzichtbar bleibt. - Die vier Risikoklassen des EU AI Act beschreiben und ihre Folgen für die KI-Governance im Unternehmen erklären. - Die fünf Dimensionen verantwortungsvoller KI (Fairness, Transparenz, Rechenschaft, Datenschutz, Sicherheit) als Entwurfsbedingungen für KI-gestützte Architekturen anwenden. - Erklären, wie KI-Komponenten (Modelle, Inferenz-Endpunkte, Datenpipelines, Monitoring) das EA-Metamodell erweitern. ### Kapitel 30. KI-Strategie: ein Rezept, kein Bauplan (AI Strategy: A Recipe, Not a Blueprint) > AI was in your organization months before the steering committee held its first meeting. Lernziele: - Erklären, warum KI-Strategien meist erst entstehen, wenn die KI-Einführung längst läuft, und warum das ein strukturelles Muster ist und kein Führungsversagen. - Die sieben Kernzutaten einer wirksamen KI-Strategie im Unternehmen benennen und verstehen, wie sie zusammenwirken. - Ein strukturiertes Lebenszyklusmodell anwenden, um von Vision und Ambition zu einer operativen Roadmap zu kommen. - Die drei Governance-Modelle für KI unterscheiden (zentral, dezentral, hybrid) und beurteilen, welches zu einem gegebenen Kontext passt. - Die fünf häufigsten Fehlermuster in KI-Strategien erkennen und belegbare Gegenmassnahmen anwenden. - Aussagekräftige Erfolgskennzahlen definieren, die KI-Investitionen mit messbaren Geschäftsergebnissen verbinden. ### Kapitel 31. KI in der Praxis (AI in Practice) > The question was never whether AI can do the task. It's whether you'll notice when it does it wrong. Lernziele: - Die vier Stufen der KI-Agenten beschreiben und erklären, wie die Governance-Anforderungen mit jeder Stufe steigen. - Die Matrix der Arbeitsteilung zwischen Mensch und KI anwenden, um Aufgaben danach einzuordnen, wer die Arbeit führt und ob sich die Arbeit selbst verändert, und daraus den passenden Zusammenarbeitsmodus ableiten. - Die RAG-Architektur (Retrieval-Augmented Generation) erklären und ihre drei Reifestufen beurteilen (Naive, Standard, Advanced). - KI-Werkzeuge für den Unternehmenseinsatz anhand der zehn Auswahlkriterien beurteilen, von Datenschutz und Compliance bis Herstellerbindung und Ökosystem. - Konkrete KI-Anwendungsfälle in der EA-Praxis benennen und beschreiben, welche Rolle dem Menschen jeweils bleibt. - Das Problem zirkulärer Governance erklären und begründen, warum Governance-Artefakte, Compliance-Freigaben und Prüfpfade in menschlicher Verantwortung bleiben müssen. - KI-Einführung auf Resilienz auslegen, indem Abhängigkeitsrisiken benannt und manuelle Rückfallwege für KI-gestützte Prozesse definiert werden. ## Teil VII. Fazit Fasst die Kernthemen zusammen und gibt Enterprise Architects eine Orientierung für das, was kommt. ### Kapitel 32. Fazit (Conclusion) > Complexity, the path to the dark side it is. Complexity leads to waste. Waste leads to anger. Anger leads to suffering. Lernziele: - Die Kernthemen des Buchs zu einem zusammenhängenden Verständnis von Lean Enterprise Architecture verbinden. - Die nächsten Schritte bestimmen, um die EA-Konzepte im eigenen organisatorischen Kontext anzuwenden. - Aufkommende Entwicklungen beurteilen (adaptive Architektur, KI-gestützte Architektur, Continuous Architecture, Nachhaltigkeit) und ihre Folgen für die EA-Disziplin einschätzen.