# Chapters > The free look inside the book: all 32 chapters in seven parts, each with its opening epigraph and its learning objectives. Source: https://leanenterprisearchitecture.com/chapters/ ## Part I. EA Foundation Establishes the conceptual foundation for enterprise architecture, covering definitions, roles, communication, lean principles, and maturity assessment. ### Chapter 1. EA Foundation > Nobody was ever promoted for a beautiful diagram. They were promoted for the decision it made possible. Learning objectives: - Explain what Enterprise Architecture and Enterprise Architecture Management are, and distinguish EAM from pure modeling or documentation activities. - Describe the six phases of the EA lifecycle and compare them with the TOGAF ADM. - Identify the four layers of the EA metamodel (Business, Data, Application, Technology) and explain how cross-layer relationships create value. - Apply the concept of planning levels (strategic, tactical, operational) to determine the appropriate granularity for different stakeholder groups. - Evaluate why Business-IT Alignment is the central goal of EA and how EAM connects to adjacent disciplines such as portfolio management and IT controlling. ### Chapter 2. Roles in Enterprise Architecture > Your title doesn't make you an architect. The size of the decisions people trust you with does. Learning objectives: - Describe the nexialist profile of the enterprise architect and explain why holistic thinking is more important than deep specialization in a single domain. - Distinguish between enterprise architect, domain architect, solution architect, and application architect roles using scope, focus, and planning horizon. - Explain the Architect Elevator concept and why the ability to translate between strategic and technical audiences is a core skill. - Compare centralized, federated, and hybrid EA organizational models and identify which model fits a given organizational context. - Apply the AKV model (Aufgaben, Kompetenzen, Verantwortung) to define clear role boundaries for architecture functions. ### Chapter 3. EA Communication and Stakeholder Management > If your stakeholders need a glossary to survive your presentation, the presentation was for you, not for them. Learning objectives: - Apply the Power-Interest Grid to segment EA stakeholders and define appropriate engagement strategies for each quadrant. - Explain the SCQA framework and the Pyramid Principle, and identify when to use each for structuring architecture messages. - Describe the purpose and structure of Architecture Decision Records (ADRs) and explain why they preserve decision context over time. - Design a stakeholder-specific communication approach that adapts the same architectural insight for different audiences (C-level, product owners, engineering teams). - Evaluate common failure patterns when introducing EAM and identify strategies to argue for EAM based on personal benefit for stakeholders. ### Chapter 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. Learning objectives: - Explain the seven success factors for Lean EAM and apply the "Nutzen durch Nutzung" (benefit through usage) principle to evaluate EAM activities. - Identify common failure modes of traditional EAM (over-documentation, analysis paralysis, misaligned incentives) and describe how Lean EAM addresses each. - Describe the three-speed model (Systems of Record, Differentiation, Innovation) and explain how governance should differ across these categories. - Design a Minimum Viable EA that delivers visible results within three months using the staged expansion approach. ### Chapter 5. 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. Learning objectives: - Describe Hanschke's five-level EAM maturity model (Initial, Building Up, Transparency, Planning, Steering) and explain what characterizes each level. - Compare Hanschke's EAM-specific maturity model with the CMMI framework and identify when to use each. - Analyze the five assessment dimensions (documentation, processes, organization, effectiveness, tool support) to conduct a structured maturity self-assessment. - Identify the critical success factors for each maturity level transition, particularly the Level 2 to Level 3 transition where EAM must prove its value. ## Part II. Strategy & Transformation Connects enterprise architecture to organizational change, covering transformation planning and change management. ### Chapter 6. Enterprise Transformation > A target state nobody revisits is not a plan, it is a souvenir. Learning objectives: - Explain the relationship between business strategy and IT strategy, and describe the six steps of IT strategy development. - Apply gap analysis to compare As-Is and To-Be architecture states and identify missing capabilities, redundancies, and technical debt. - Compare the six legacy migration patterns (Retain, Wrap, Refactor, Rehost, Replatform, Retire) and evaluate which pattern fits a given application scenario. - Distinguish between OKRs and KPIs, and explain when each framework is appropriate for managing transformation versus operations. - Apply the eight-step MCDA method to evaluate competing architecture options using weighted criteria and structured scoring. ### Chapter 7. Change Management > Culture doesn't eat strategy for breakfast. It quietly ignores it until the strategy gives up. Learning objectives: - Explain Beckhard's model (Current State, Transition State, Future State) and apply the Change Formula (D x V x F > R) to diagnose readiness for transformation. - Compare three classic change management models (Kuebler-Ross / Streich Change Curve, Kotter's 8-Step Model, St. Gallen Management Model) and identify which is best suited for a given situation. - Describe the seven phases of the Kuebler-Ross / Streich Change Curve and identify appropriate leadership responses for each phase. - Analyze how culture influences transformation success and evaluate why "culture eats strategy for breakfast" applies to architecture initiatives. - Design a change communication strategy that addresses different stakeholder groups using architecture narratives, visual storytelling, and active EA marketing. ## Part III. Architecture Domains Explores the six core architecture domains: business, capability, information, application landscape, data, and integration. ### Chapter 8. Business Architecture > Designing an IT landscape without understanding the business is just very confident guessing with a bigger budget. Learning objectives: - Distinguish business architecture from enterprise architecture and explain their complementary roles - Describe the four key elements of business architecture: capabilities, value streams, organization, and information - Apply the Business Model Canvas to articulate how an organization creates, delivers, and captures value - Explain how Porter's Value Chain classifies activities into primary and support categories for investment prioritization - Identify the bidirectional relationship between business and IT alignment, including how Conway's Law shapes architecture decisions ### Chapter 9. Capability Mapping > A capability map answers the one question most leadership teams can't agree on: what does this company actually do? Learning objectives: - Apply the three-level capability hierarchy (L1 domains, L2 planning capabilities, L3 implementation capabilities) to structure a capability map - Evaluate capability definitions against quality criteria such as outcome orientation, stability, and abstraction consistency - Design a capability mapping workshop using the six-step creation process described in this chapter - Explain how capability maps link to processes, applications, and data to serve as the "Rosetta Stone" of business-IT alignment - Apply heatmap assessments to identify strategic priorities and investment needs across a capability landscape ### Chapter 10. Information Architecture > A knowledge base without information architecture is just a landfill with a search box. Learning objectives: - Distinguish between EA-focused information architecture (business objects, CRUD matrices, data flows) and content-focused information architecture (navigation, labeling, metadata) - Apply CRUD matrices to identify data ownership, redundancy, and integration requirements across applications - Describe business object modeling using three granularity levels (core business objects, business objects, information objects) - Explain how taxonomies and controlled vocabularies support information findability and governance - Identify the key IA deliverables and their role in application landscape planning and integration design ### Chapter 11. 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. Learning objectives: - Explain the application landscape planning (Bebauungsplanung) methodology and its three fundamental goals: business alignment, pain resolution, and IT readiness - Apply Hanschke's analysis patterns in the five categories this book abbreviates as RIOFT (Redundancies, Inconsistencies, Organizational responsibilities, Fulfillment of business requirements, Technical optimization) to assess the current application landscape - Describe the iterative process for designing a target landscape, from establishing business context to evaluating planning scenarios - Evaluate applications using the four-quadrant portfolio assessment framework (strategic, at risk, support, phase out) - Classify applications by criticality level (safety, mission, business critical, non-critical) and explain how RTO and RPO metrics guide resilience planning - Apply the TIME model (Tolerate, Invest, Migrate, Eliminate) to determine rationalization strategies for an application portfolio - Compare big bang and evolutionary migration strategies and explain how roadmaps bridge the gap between current and target landscapes ### Chapter 12. Data Architecture > Everyone wants to be data-driven. Almost nobody wants to agree on what 'customer' means. Learning objectives: - Describe the three data architecture layers (conceptual, logical, physical) and explain which layers are the primary concern of enterprise architects - Explain the data governance role model (Data Trustee, Data Owner, Data Steward, Data Custodian) and its organizational implications - Explain the purpose of Master Data Management, the Golden Record concept, and the four MDM styles (registry, consolidation, coexistence, centralized) - Compare modern data architecture patterns: Data Warehouse, Data Lake, Data Lakehouse, Data Mesh, and Data Fabric - Apply the six data quality dimensions (accuracy, completeness, consistency, timeliness, validity, uniqueness) to assess data health - Identify the architectural implications of AI workloads on data infrastructure, including vector databases, feature stores, and data lineage - Explain the EA-level role of data deletion and system decommissioning, including retention policies, decommissioning discipline, and verifiable deletion ### Chapter 13. Integration Architecture > Ten systems wired straight to each other need forty-five connections, and every one of them was somebody's quick fix. Learning objectives: - Compare integration patterns (point-to-point, hub-and-spoke, event-driven, API-led, iPaaS) and evaluate their trade-offs for different scenarios - Explain API governance principles, including API-first design, lifecycle management, and the role of API gateways - Describe event-driven architecture patterns (event notification, event-carried state transfer, event sourcing, CQRS) and their use cases - Distinguish between integration scenarios (A2A, B2B, B2C, IoT) and identify appropriate patterns for each - Apply integration governance practices, including architecture review for new integrations and documentation in the EA repository ## Part IV. Governance & Steering Covers the governance mechanisms that make architecture decisions stick: compliance frameworks, portfolio management, and IT controlling. ### Chapter 14. Governance and Compliance > Governance built to say 'no' gets what it deserves: a company that stops asking. Learning objectives: - Describe the five components of an EA governance framework: architecture foundation, processes, competency management, leadership structures, and metrics - Compare governance frameworks (TOGAF, COBIT, ITIL, SAFe) and explain how to compose elements pragmatically rather than adopting any framework wholesale - Identify the eight forms of technical debt and explain strategies for making debt visible and managing it systematically - Apply the Three Lines of Defense model to separate risk ownership, oversight, and assurance in an EA context - Evaluate EA organizational structures (centralized, decentralized, federated) and their trade-offs for governance effectiveness ### Chapter 15. Project Portfolio Management > The most important word in portfolio management is 'stop,' and it's the one nobody in the room wants to say. Learning objectives: - Describe the role of enterprise architecture in portfolio decisions, including conformity assessment, impact analysis, and the "one in, one out" rule - Apply portfolio prioritization methods using weighted criteria such as strategic alignment, architecture fit, and cost-benefit - Compare weighted multi-criteria scoring with Weighted Shortest Job First (WSJF) and explain the strengths and limitations of each approach - Explain Lean Demand Management as the mechanism for evaluating new IT demands against the capability map and target landscape - Distinguish portfolio categories (strategic, mandatory, operational, innovation) and evaluate whether a portfolio maintains a healthy balance ### Chapter 16. IT Controlling > A dashboard full of IT costs with no link to business outcomes is just an expensive way to feel informed. Learning objectives: - Explain TCO analysis and apply it to compare investment alternatives, including the shift from CapEx to OpEx in cloud environments - Apply the run/change/innovate model to categorize IT spending and identify the organization's capacity for strategic investment - Describe EAM-specific controlling metrics (Bebauungsplanfit, Standardisierungsgrad, Dokumentationsgrad) and their role in architectural steering - Compare chargeback and showback approaches for IT cost allocation and evaluate their organizational implications - Identify how enterprise architecture data transforms IT controlling from a purely financial exercise into a business-oriented steering instrument ## Part V. Methods & Tools Enterprise architecture does not happen in the abstract. It requires a shared language, a structured process, and the right instruments to turn strategic intent into operational reality. Part V introduces the methods, modeling languages, and tools that enterprise architects use in practice, not as an academic survey but as a working repertoire that practitioners reach for when they need to communicate complexity, govern decisions, and plan transformation. ### Chapter 17. TOGAF > Adopting TOGAF whole is the safest career decision and the slowest architecture decision available to you. Learning objectives: - Describe the evolution of TOGAF from TAFIM through Version 9.2 to the modular Version 10 and explain the significance of the restructuring. - Explain the purpose, key inputs, key activities, and key outputs of each ADM phase and how Requirements Management connects to all phases. - Describe the components of the TOGAF Architecture Repository and explain how the Enterprise Continuum organizes reusable architecture assets. - Apply the concept of ADM tailoring to adapt the framework for different organizational sizes and maturity levels. - Evaluate TOGAF's strengths and limitations and explain how it relates to complementary frameworks such as Zachman, ArchiMate, and COBIT. ### Chapter 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. Learning objectives: - Explain the origin of the Zachman Framework and the engineering analogy that inspired it. - Describe the 6x6 matrix structure, including all six perspectives and six interrogatives, and explain what each cell represents. - Apply the Zachman Framework as a completeness checklist for architecture documentation. - Distinguish between the Zachman Framework (taxonomy) and TOGAF (methodology) and explain how they complement each other. - Evaluate the framework's modern relevance and its limitations for day-to-day architecture practice. ### Chapter 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. Learning objectives: - Describe ArchiMate's layer structure (Business, Application, Technology) and explain how additional layers (Strategy, Implementation and Migration, Motivation) extend the core framework. - Identify the appropriate ArchiMate element types and relationship types for a given modeling scenario. - Distinguish between ArchiMate viewpoints based on purpose (Design, Decide, Inform), content, and scope. - Explain when to use ArchiMate versus domain-specific notations such as BPMN, UML, or C4. - Apply the cross-layer serving and realization relationships to trace from strategic goals to infrastructure components. ### Chapter 20. Process and Decision Modeling > Bury your pricing rules inside the process diagram and every price change becomes a modeling project. Learning objectives: - Describe the core BPMN elements (events, activities, gateways, pools, lanes) and their roles in process modeling. - Compare BPMN and DMN and explain how they complement each other through the business rule task integration pattern. - Apply the three levels of BPMN modeling (descriptive, analytical, executable) and identify the appropriate level for enterprise architecture work. - Explain when to use decision tables with different hit policies (Unique, First, Collect) and how they support auditable business decisions. - Evaluate when BPMN is preferred over simple flowcharts based on the need for standardized semantics, maintainability, and collaboration. ### Chapter 21. Software and System Modeling > Systems are not confusing because the notation was too loose. They are confusing because nobody drew them at all. Learning objectives: - Compare UML, SysML, and C4 in terms of purpose, formality, audience, and typical EA use cases. - Apply the four C4 model levels (Context, Container, Component, Code) and identify which level is appropriate for a given stakeholder and decision. - Identify the UML diagram types most relevant to enterprise architecture (component, deployment, sequence) and explain when each adds value. - Describe the architecture-as-code approach using tools such as Structurizr, PlantUML, and Mermaid, and explain its benefits for version control and review workflows. ### Chapter 22. EA Metamodels > Every organization already has a metamodel. Most just never wrote it down, which is why nobody agrees on what an 'application' is. Learning objectives: - Explain the purpose of an EA metamodel and why making it explicit improves clarity and governance. - Compare the TOGAF Content Framework, Hanschke's four-layer metamodel, and BIZBOK in terms of scope, complexity, and practical applicability. - Design a minimal custom metamodel starting from core entities (applications, capabilities, processes, technologies) and extending based on actual stakeholder questions. - Describe how metamodel entities and relationships serve as the foundation for governance metrics, impact analysis, and portfolio management. - Identify common metamodel pitfalls (over-engineering, missing cross-layer relationships, treating the metamodel as static) and explain how to avoid them. ### Chapter 23. EA Visualizations > A good diagram makes its point before the reader decides to stop reading. Learning objectives: - Identify the appropriate EA visualization type (landscape plan, portfolio graphic, lifecycle graphic, information flow graphic, roadmap) for a given stakeholder question and audience. - Describe the three variants of the Bebauungsplangrafik (business, technical, typical) and explain when to use each one. - Select visualizations by matching the question, audience, and required level of detail to the visualization type. - Evaluate the trade-offs between static diagrams and interactive dashboards for different communication contexts. ### Chapter 24. EA Tooling > You don't have a tooling gap. You have a discipline gap, and no license fixes that. Learning objectives: - Compare the four EA tool categories (dedicated platforms, diagramming tools, architecture-as-code, lightweight approaches) and identify when each is appropriate. - Apply tool selection criteria (organization size, EA maturity, budget, deployment model) to recommend a tooling approach for a given organizational context. - Describe the role of architecture as code (Structurizr, PlantUML, Mermaid, policy-as-code, developer portals) in modern EA practice. - Distinguish between a CMDB and an EA repository in terms of purpose, content, and how they complement each other. ### Chapter 25. Synthesis: Methods and Tools in Practice > The best architects steal from every framework and pledge loyalty to none. ## Part VI. Technology & AI Addresses the technology dimension of enterprise architecture, from strategy through operations and patterns, including AI fundamentals and practice. ### Chapter 26. Technology Strategy > Every technology decision is an organizational decision wearing a technical costume. Learning objectives: - Explain the cybernetic enterprise concept and its intellectual lineage from Beer's Viable System Model through Agile and DevOps to Roth's Triad of Intelligence. - Compare the four technology delivery paradigms (Traditional IT, Agile, DevOps, Cybernetic) across scope, feedback mechanisms, and governance approaches. - Apply the five-step automation framework ("automate last") to evaluate technology initiatives. - Analyze the buy-versus-build decision using the four options (buy, compose, extend, build) and their alignment with strategic differentiation. - Describe the four domains of digital sovereignty (infrastructure, technology, data, application) and explain how DORA, NIS2, GDPR, and the Swiss DSG drive sovereignty as an architectural concern. - Describe how value streams, product-based delivery, and Team Topologies connect organizational structure to technology outcomes. ### Chapter 27. Technology Operations > Speed and safety were never a trade-off. That was the story slow organizations told themselves. Learning objectives: - Describe the DORA four key metrics and explain how they measure both speed and stability of software delivery. - Compare the six operational models for production ownership (from "Ops Runs It" to SRE) and identify which model fits a given workload and organizational maturity. - Explain the platform engineering concept, including golden paths, the floating platform, and developer experience as a success metric. - Analyze cloud service models (IaaS, CaaS, PaaS, FaaS, SaaS), deployment strategies (Cloud Only, Cloud First, Cloud Smart), and the Cloud Foundation framework. - Apply the Cloud Operating Model's six capabilities and five lenses to assess an organization's cloud readiness. ### Chapter 28. Technology Patterns > There are no best practices, only trade-offs someone forgot to tell you about. Learning objectives: - Describe the seven-layer defense-in-depth security model and explain the principles of Zero Trust Architecture. - Identify the six architecture patterns (layered, serverless, hybrid cloud, high availability, scale-out, microservices) and evaluate which pattern fits a given workload and organizational context. - Compare quality attributes (scalability, reliability, availability, security, maintainability) and explain the trade-offs between them. - Distinguish between Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs) and explain how they connect abstract requirements to concrete implementations. - Apply the Technology Radar concept to structure technology governance and innovation management decisions. - Explain OT/IT convergence and the role of ISA-95 in bridging operational and information technology. ### Chapter 29. AI Fundamentals > The model does not know when it is wrong, and that is now your architecture problem. Learning objectives: - Explain the AI hierarchy (AI, Machine Learning, Deep Learning, Generative AI) and describe how LLMs work at a conceptual level. - Identify the five key limitations of current LLMs and explain why human oversight remains essential. - Describe the EU AI Act's four risk tiers and their implications for enterprise AI governance. - Apply the five dimensions of responsible AI (fairness, transparency, accountability, privacy, safety) as design constraints for AI-enabled architectures. - Explain how AI components (models, inference endpoints, data pipelines, monitoring) extend the enterprise architecture metamodel. ### Chapter 30. AI Strategy: A Recipe, Not a Blueprint > AI was in your organization months before the steering committee held its first meeting. Learning objectives: - Explain why AI strategies are typically developed after AI adoption has already begun, and why this is a structural pattern rather than a failure of leadership. - Identify the seven core ingredients of an effective enterprise AI strategy and understand how they interact. - Apply a structured lifecycle model to move from vision and ambition to an operational roadmap. - Distinguish between the three AI governance models (centralized, decentralized, and hybrid) and assess which fits a given organizational context. - Recognize the five most common AI strategy failure patterns and apply evidence-based countermeasures. - Define meaningful success metrics that connect AI investment to measurable business outcomes. ### Chapter 31. AI in Practice > The question was never whether AI can do the task. It's whether you'll notice when it does it wrong. Learning objectives: - Describe the four levels of AI agent sophistication and the governance requirements that scale with each level. - Apply the human-AI work distribution matrix to classify tasks by who leads the work (human vs. AI) and whether the work itself is being transformed, and determine the appropriate collaboration mode. - Explain the RAG (Retrieval-Augmented Generation) architecture and evaluate its three maturity levels (Naive, Standard, Advanced). - Evaluate AI tools for enterprise use based on the ten selection criteria, from privacy and compliance to vendor lock-in and ecosystem compatibility. - Identify concrete AI use cases in enterprise architecture practice and describe the human role that remains for each. - Explain the circular governance problem and argue why governance artifacts, compliance sign-off, and audit trails require human ownership. - Design AI adoption for resilience by identifying dependency risks and defining manual fallbacks for AI-assisted processes. ## Part VII. Conclusion Synthesizes the key themes and provides forward-looking guidance for enterprise architects. ### Chapter 32. Conclusion > Complexity, the path to the dark side it is. Complexity leads to waste. Waste leads to anger. Anger leads to suffering. Learning objectives: - Synthesize the key themes from the book into a coherent understanding of lean enterprise architecture. - Identify the next steps for applying EA concepts in your own organizational context. - Evaluate emerging trends (adaptive architecture, AI-augmented architecture, continuous architecture, sustainability) and their implications for the EA discipline.