Begriff
Enterprise Architecture
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Stell dir eine Stadt ohne Stadtplaner vor. Jeder baut sein Haus, wo er will. Straßen enden im Nichts. Stromkabel liegen quer über der Wiese. (Chaos). Viele Firmen-IT-Landschaften sehen so aus. Enterprise Architecture (EA) ist die Stadtplanung für die IT. Der Architekt schaut von oben drauf:
- "Wir haben 5 verschiedene Mail-Programme. Wir brauchen nur eins."
- "Wenn wir System A abschalten, funktioniert System B nicht mehr (Abhängigkeit)."
- "Wo wollen wir in 5 Jahren sein?"
Merksatz: Die Disziplin, die IT-Landschaft und Geschäftsprozesse ganzheitlich zu planen und zu strukturieren.
Enterprise Architekten malen oft riesige "Landkarten" (Blueprints).
- Ist-Zustand (As-Is): Das aktuelle Chaos.
- Soll-Zustand (To-Be): Das saubere Ziel in 3 Jahren.
- Roadmap: Der Weg von A nach B.
Sie sind die Feinde von "Wir kaufen mal schnell Software X", weil Software X vielleicht nicht in den Bebauungsplan passt.
1. TOGAF (The Open Group Architecture Framework)
Die Bibel der Architekten. Ein riesiges Buch mit Methoden, wie man Architektur baut. Es teilt alles in 4 Schichten:
- Business: Was macht die Firma? (Autos bauen).
- Data: Welche Daten brauchen wir? (Konstruktionspläne).
- Application: Welche Apps brauchen wir? (CAD-Software).
- Technology: Welche Server brauchen wir? (Linux-Cluster).
2. Conway's Law
Eine berühmte Regel: "Software-Architekturen sehen immer so aus wie die Kommunikations-Strukturen der Firma, die sie gebaut hat." Chaotische Firma = Chaotische Software. Gute EA versucht daher oft zuerst, die Organisation zu ändern, damit die Software besser wird.
1. Bounded Contexts & Domain-Driven Design (DDD)
Ein Hauptproblem der EA in Monolithen: Alle 500 Entwickler nutzen eine zentrale Datenbank für ihre Microservices. Ein "Customer"-Objekt ist ein riesiges 100-Spalten-Monster, an dem das Payment-Team und das Shipping-Team gleichzeitig schrauben. Jede Änderung verursacht Dependency-Konflikte (Datenbank Deadlocks).
Enterprise Architekten zerschlagen dieses Modell mit Domain-Driven Design (DDD).
Die Firma wird zerschnitten in völlig autarke Bounded Contexts ("Shipping Domain" vs "Billing Domain").
Die Shipping-Domain hat eine eigene PostgreSQL-DB und ein abgespecktes Customer Objekt (nur Adresse). Die Billing-Domain hat ebenfalls ein Customer Objekt (nur IBAN). Sie tauschen Daten ausschließlich über asynchrone Event-Driven RabbitMQ/Kafka Busse (UserAddressUpdatedEvent) aus. Maximale Entkopplung ist das Goldziel.
2. API-Led Connectivity Architecture
Mulesoft popularisierte den revolutionären Layer-Ansatz für Integration. Großunternehmen haben 30 verrottete Legacy-Server (SAP/Mainframes). Statt die Frontends der Apps Spaghetti-artig hart an jeden einzelnen Backend-Service zu flanschen (Point-to-Point), führt man Schichten ein:
- System APIs: Wrapper. Sie verstecken das grausame SQL des SAP-Servers hinter sauberem, einfachen REST-JSON.
- Process APIs: Die Orchestratoren. ("Customer Onboarding" api). Sie rufen im Hintergrund die System-API "Lege User an", dann die System-API "Kreditwürdigkeit prüfen" nacheinander ab und verknüpfen Business-Logik.
- Experience APIs: Das Frontend UI (iOS, Web). Diese Reduzieren die großen Process-Flows exakt auf das UI der Smartwatch.
3. Technical Debt Management (Architecture Runways)
Im SAFe Framework (Scaled Agile Framework) hassen Produktmanager (PO) oft Architektur, weil Architektur ("Server upgrade", "Refactoring") null direkten Kunden-Wert generiert. "Wieso sollen wir 2 Sprints an der Datenbank bauen, wenn der Kunde neue Buttons will?". Der EA nutzt den Architectural Runway. Wenn der PO einen fliegenden Laster will (Feature), baut das Entwickler-Team im Vorab-Sprint die Startbahn (Server, DB-Migrations). Architekturschulden (Technical Debt) werden nicht als Ticket in der Ecke versteckt, sondern wie Geld in einem Haushaltsbuch visualisiert (als Zinsschuld, die das Bauen von neuen Buttons in 2 Jahren durch Code-Fäule stoppen wird).
Quick-Check
Braucht ein Startup EA?
Am Anfang nicht ("Move fast and break things"). Aber ab 50 Mitarbeitern rächt es sich, wenn man keinen Plan hatte ("Technical Debt").Ist der Architekt der Chef?
Nein, er hat oft keine Weisungsbefugnis ("Stabsstelle"). Er muss überzeugen ("Diplomatik"). Wenn der CEO sagt "Ich will aber X", muss der Architekt sich fügen.Ist es langweilig?
Es ist sehr abstrakt ("Elfenbeinturm"). Man schreibt keinen Code, sondern Powerpoints. Aber man hat extremen Einfluss auf die Zukunft der Firma.