Definition und Verständnis von IT-Architekturen und IT-Architekturmanagement (EAM)[cite: 2].
Erkennen der Notwendigkeit und des Nutzens von EAM[cite: 2].
Kennenlernen der verschiedenen Sichten und Ebenen einer IT-Architektur[cite: 2].
Verstehen der Rolle und Aufgaben eines IT-Architekten[cite: 2].
Einblick in gängige Frameworks für EAM[cite: 2].

1.1 Was ist eine IT-Architektur?

Definition Architektur (Allgemein): Grundlegende Organisation eines Systems, dargestellt durch seine Komponenten, deren Beziehungen zueinander und zur Umgebung sowie die Prinzipien, die den Entwurf und die Entwicklung des Systems leiten[cite: 5].
Definition IT-Architektur: Umfassende Beschreibung der IT-Strukturen einer Organisation, einschließlich Hardware, Software, Netzwerke, Daten und deren Zusammenspiel zur Unterstützung der Geschäftsziele[cite: 5]. Sie ist eine Generalisierung der Beziehungen zwischen Geschäft, Information, Anwendung und Technologie[cite: 6].
IT-Architektur als Brücke: Verbindet die Geschäftsstrategie mit der technologischen Umsetzung[cite: 5].
Ziele der IT-Architektur:
- Sicherstellung, dass die IT die Geschäftsstrategie effektiv unterstützt[cite: 6].
- Schaffung einer gemeinsamen Vision und Sprache für IT und Business[cite: 6].
- Standardisierung und Konsolidierung der IT-Landschaft zur Kostenreduktion und Effizienzsteigerung[cite: 6].
- Erhöhung der Agilität und Flexibilität der IT, um auf Veränderungen reagieren zu können[cite: 6].
- Management von Komplexität und Risiken[cite: 6].

1.2 Was ist IT-Architekturmanagement (Enterprise Architecture Management - EAM)?

Definition EAM: Kontinuierlicher Prozess zur Definition, Pflege, Weiterentwicklung und Steuerung der IT-Architektur einer Organisation[cite: 7]. EAM ist die kontinuierliche Praxis der Beschreibung, Gestaltung und Verwaltung von Unternehmensarchitekturen[cite: 8].
Aufgaben des EAM:
- Entwicklung und Kommunikation einer Zielarchitektur[cite: 7].
- Analyse der aktuellen Ist-Architektur[cite: 7].
- Planung der Transformation von der Ist- zur Zielarchitektur[cite: 7].
- Sicherstellung der Einhaltung von Architekturstandards und -richtlinien (Governance)[cite: 7].
Nutzen von EAM:
- Bessere Ausrichtung der IT an den Geschäftszielen (Business-IT-Alignment)[cite: 8].
- Höhere Transparenz über die IT-Landschaft[cite: 8].
- Reduktion von Redundanzen und Komplexität[cite: 8].
- Fundierte Entscheidungen für IT-Investitionen[cite: 8].
- Risikominimierung bei IT-Projekten[cite: 8].
- Verbesserte Interoperabilität und Integration von Systemen[cite: 8].

1.3 Ebenen und Sichten der IT-Architektur

Architekturen werden oft in verschiedenen Ebenen oder Domänen betrachtet[cite: 9]:
- Geschäftsarchitektur (Business Architecture): Beschreibt die Geschäftsstrategie, -prozesse, -organisation und -funktionen[cite: 9].
- Informations-/Datenarchitektur (Data Architecture): Struktur und Verwaltung der Datenbestände einer Organisation[cite: 9].
- Anwendungsarchitektur (Application Architecture): Struktur und Zusammenspiel der Anwendungslandschaft[cite: 9].
- Technologiearchitektur (Technology Architecture): Hardware, Software-Infrastruktur, Netzwerke, die zur Unterstützung der Anwendungen benötigt werden[cite: 9].
Sichten (Views): Unterschiedliche Darstellungen der Architektur, zugeschnitten auf die Bedürfnisse verschiedener Stakeholder (z.B. Management, Entwickler)[cite: 10]. Ein View ist eine Repräsentation eines Sets von Systemelementen und deren Beziehungen, die für einen bestimmten Zweck erstellt wurde[cite: 10].
Viewpoints: Definieren die Konventionen für die Konstruktion und Nutzung einer Sicht; eine Art Vorlage für Sichten[cite: 10].

1.4 Die Rolle des IT-Architekten

Aufgaben:
- Entwurf, Entwicklung und Kommunikation der IT-Architektur[cite: 11].
- Beratung von Projekten und Management in Architekturfragen[cite: 11].
- Sicherstellung der Einhaltung von Architekturvorgaben[cite: 11].
- Bewertung neuer Technologien und Trends[cite: 11].
- Vermittlung zwischen Fachbereichen und IT[cite: 11].
Typische Rollen:
- Unternehmensarchitekt (Enterprise Architect): Gesamtarchitektur der Organisation[cite: 12].
- Lösungsarchitekt (Solution Architect): Architektur für spezifische Projekte oder Lösungen[cite: 12].
- Domänenarchitekt (Domain Architect): Spezialisiert auf eine Ebene, z.B. Daten- oder Technologiearchitekt[cite: 12].
- Softwarearchitekt: Fokussiert auf das Design von Softwaresystemen und deren Komponenten[cite: 12].
Benötigte Fähigkeiten: Technisches Know-how, Abstraktionsvermögen, Kommunikationsfähigkeit, strategisches Denken, Überzeugungskraft[cite: 13].

1.5 Architektur-Frameworks

Definition Framework: Strukturierter Ansatz mit Methoden, Werkzeugen und Prozessen zur Entwicklung und Verwaltung von Architekturen[cite: 14].
Ziele von Frameworks: Standardisierung, Vergleichbarkeit, Wiederverwendbarkeit, Reduktion von Komplexität[cite: 14].
Bekannte EAM-Frameworks:
- TOGAF (The Open Group Architecture Framework): Weit verbreitet, prozessorientiert, bietet das Architecture Development Method (ADM)[cite: 15].
  - ADM ist ein iterativer Zyklus zur Entwicklung einer Unternehmensarchitektur[cite: 15].
  - Kernkomponenten: ADM, Architecture Content Framework, Enterprise Continuum, Architecture Capability Framework[cite: 15].
- Zachman Framework: Ontologie zur Strukturierung von Architekturbeschreibungen mittels einer Matrix (Perspektiven vs. Fragewörter)[cite: 16]. Es ist eher ein Klassifikationsschema als eine Methodik[cite: 16].
- FEAF (Federal Enterprise Architecture Framework): Für US-Regierungsbehörden[cite: 17].
- ArchiMate: Eine offene und unabhängige Modellierungssprache für Unternehmensarchitekturen, oft in Verbindung mit TOGAF genutzt[cite: 17].
Die Auswahl eines Frameworks hängt von den spezifischen Bedürfnissen und Zielen der Organisation ab[cite: 17].

Kapitel 2: Architekturprinzipien und -muster

Lernziele des Kapitels:

Bedeutung und Anwendung von Architekturprinzipien verstehen[cite: 18].
Verschiedene Arten von Architekturmustern kennenlernen und deren Einsatzmöglichkeiten bewerten[cite: 18].
Zusammenhang zwischen Prinzipien, Mustern und der Qualität einer Architektur erkennen[cite: 18].

2.1 Architekturprinzipien

Definition: Grundlegende Regeln, Richtlinien und Überzeugungen, die als Basis für Architekturentscheidungen dienen[cite: 20]. Sie sind allgemeine Regeln und Richtlinien, die die Art und Weise bestimmen, wie eine Organisation ihre IT-Systeme entwickelt und verwaltet[cite: 20].
Zweck von Prinzipien:
- Leitplanken für konsistente Entscheidungen[cite: 20].
- Sicherstellung der Ausrichtung an strategischen Zielen[cite: 20].
- Vermittlung der Architekturvision[cite: 20].
Eigenschaften guter Prinzipien: Verständlich, robust, vollständig, konsistent, stabil[cite: 21].
Beispiele für Architekturprinzipien:
- Business Primacy: Geschäftsanforderungen haben Vorrang[cite: 21].
- Maximize Benefit to the Enterprise: Entscheidungen zum maximalen Nutzen des Gesamtunternehmens[cite: 21].
- Information Management is Everybody's Business: Datenverantwortung liegt bei allen[cite: 21].
- Common Use Applications: Bevorzugung gemeinsamer Anwendungen[cite: 21].
- Technology Independence: Unabhängigkeit von spezifischen Technologien (durch Abstraktion)[cite: 21].
- Compliance with Law: Einhaltung gesetzlicher Vorgaben[cite: 21].
Jedes Prinzip sollte eine Begründung (Rationale) und Implikationen (Auswirkungen auf die Praxis) haben[cite: 22].

2.2 Architekturmuster (Patterns)

Definition: Bewährte Lösungsansätze für wiederkehrende Entwurfsprobleme in einem bestimmten Kontext[cite: 23]. Ein Muster beschreibt ein Problem, das in einem bestimmten Kontext wiederholt auftritt, und beschreibt den Kern einer Lösung für dieses Problem[cite: 23].
Struktur eines Musters (typisch): Name, Problem, Kontext, Lösung (Forces), Beispiele, Konsequenzen[cite: 24].
Vorteile von Mustern:
- Wiederverwendung von erprobtem Wissen[cite: 23].
- Verbesserte Kommunikation durch gemeinsames Vokabular[cite: 23].
- Schnellere Entwicklung und höhere Qualität[cite: 23].
Kategorien von Mustern:
- Grundlegende Strukturmuster (Layering, Tiers):
  - Layering (Schichtenarchitektur): Aufteilung des Systems in horizontale Schichten (z.B. Präsentation, Geschäftslogik, Datenhaltung). Jede Schicht kommuniziert nur mit direkt benachbarten Schichten[cite: 25].
  - N-Tier-Architektur: Physische oder logische Verteilung der Schichten auf verschiedene Ebenen (z.B. 3-Tier: Client, Application Server, Database Server)[cite: 26].
- Verteilungsmuster:
  - Client-Server: Aufteilung in einen Dienstleister (Server) und einen Dienstnutzer (Client)[cite: 27].
  - Message Bus: Komponenten kommunizieren asynchron über einen zentralen Nachrichtenkanal[cite: 28].
- Interaktionsmuster:
  - Model-View-Controller (MVC): Trennung von Datenmodell (Model), Präsentation (View) und Steuerungslogik (Controller)[cite: 29]. Varianten wie MVP, MVVM[cite: 29].
- Adaptionsmuster / Entkopplungsmuster:
  - Microservices: System als Sammlung kleiner, unabhängiger Dienste, die über Netzwerke kommunizieren[cite: 30]. Fördert Skalierbarkeit und technologische Vielfalt[cite: 30].
  - Service-orientierte Architektur (SOA): Bereitstellung von Geschäftsfunktionen als wiederverwendbare Services[cite: 31]. Oft basierend auf Web Services[cite: 31].
Antipatterns: Häufige, aber ineffektive oder schädliche Lösungsansätze für Probleme[cite: 32]. Beispiele: God Class, Spaghetti Code[cite: 32].

2.3 Beziehung zwischen Prinzipien und Mustern

Prinzipien geben vor, was erreicht werden soll (Ziele, Qualitäten)[cite: 33].
Muster zeigen, wie etwas erreicht werden kann (konkrete Lösungsstrukturen)[cite: 33].
Muster können helfen, Prinzipien umzusetzen. Zum Beispiel kann das Schichtenmuster helfen, das Prinzip der "Technology Independence" durch klare Trennung von Belangen zu unterstützen[cite: 33].

Kapitel 3: Architekturdokumentation und -kommunikation

Lernziele des Kapitels:

Wichtigkeit und Zweck der Architekturdokumentation verstehen[cite: 34].
Gängige Standards und Notationen zur Architekturbeschreibung kennenlernen (z.B. UML, ArchiMate)[cite: 34].
Effektive Strategien zur Kommunikation von Architekturentscheidungen an verschiedene Stakeholder entwickeln[cite: 34].

3.1 Zweck und Bedeutung der Dokumentation

Warum dokumentieren?
- Kommunikation: Vermittlung der Architektur an Stakeholder (Entwickler, Tester, Management, Kunden)[cite: 36].
- Analyse und Entwurf: Unterstützung des Entwurfsprozesses und Analyse von Alternativen[cite: 36].
- Wissenskonservierung: Festhalten von Entwurfsentscheidungen und Begründungen für die Zukunft[cite: 36].
- Systemwartung und -weiterentwicklung: Erleichterung der Einarbeitung und Vermeidung von Fehlern[cite: 36].
- Schulung: Basis für die Einarbeitung neuer Teammitglieder[cite: 36].
- Compliance und Governance: Nachweis der Einhaltung von Standards und Richtlinien[cite: 36].
Herausforderungen:
- Aktuell halten der Dokumentation (oft vernachlässigt)[cite: 37].
- Angemessener Detaillierungsgrad (nicht zu viel, nicht zu wenig)[cite: 37].
- Zielgruppengerechte Aufbereitung[cite: 37].
"Die Architektur ist das, was dokumentiert wird. Wenn sie nicht dokumentiert ist, ist sie keine Architektur, sondern nur eine Ansammlung von Code." (sinngemäß)[cite: 37].

3.2 Sichten und Viewpoints (nach ISO/IEC/IEEE 42010)

Standard ISO/IEC/IEEE 42010 (Systems and software engineering — Architecture description): Definiert Anforderungen an Architekturbeschreibungen[cite: 38].
Kernkonzepte:
- Stakeholder: Personen oder Gruppen mit Interessen am System (z.B. Nutzer, Entwickler, Betreiber)[cite: 38].
- Concerns (Belange): Interessen der Stakeholder, die die Architektur adressieren muss (z.B. Performance, Sicherheit, Kosten)[cite: 38].
- View (Sicht): Darstellung der Architektur aus der Perspektive spezifischer Concerns eines oder mehrerer Stakeholder[cite: 39].
- Viewpoint (Perspektive/Standpunkt): Spezifikation der Konventionen für die Erstellung und Nutzung einer Sicht. Definiert die zu verwendenden Modelle, Notationen und Regeln[cite: 39].
- Architecture Description (AD): Sammlung von Artefakten, die eine Architektur dokumentieren (inkl. Views, Viewpoints, Modelle)[cite: 39].
- Architecture Model: Ein spezifisches Artefakt, das Aspekte der Architektur darstellt (z.B. ein UML-Diagramm)[cite: 39].
arc42 als praktischer Ansatz: Template für Architekturdokumentation, schlägt eine pragmatische Struktur mit verschiedenen Sichten vor (z.B. Bausteinsicht, Laufzeitsicht, Verteilungssicht)[cite: 40].

3.3 Modellierungssprachen und Notationen

UML (Unified Modeling Language): Standardisierte grafische Sprache zur Spezifikation, Konstruktion und Dokumentation von Softwaresystemen[cite: 41].
- Strukturdiagramme: Zeigen statische Aspekte. Beispiele: Klassendiagramm, Komponentendiagramm, Verteilungsdiagramm[cite: 41].
- Verhaltensdiagramme: Zeigen dynamische Aspekte. Beispiele: Anwendungsfalldiagramm (Use Case), Sequenzdiagramm, Aktivitätsdiagramm, Zustandsdiagramm[cite: 41].
ArchiMate: Offene Modellierungssprache speziell für Unternehmensarchitekturen[cite: 42].
- Bietet Notation für die verschiedenen Architekturebenen (Geschäft, Anwendung, Technologie) und deren Beziehungen[cite: 42].
- Kernframework unterteilt in Aspekte (z.B. Aktiv, Struktur, Verhalten) und Schichten (Business, Application, Technology, ggf. Physical, Strategy, Implementation & Migration)[cite: 42].
BPMN (Business Process Model and Notation): Standard zur grafischen Modellierung von Geschäftsprozessen[cite: 43].
Weitere: ER-Diagramme (Datenmodellierung), Flussdiagramme, etc.[cite: 43].
Wahl der Notation hängt von der Sicht, dem Zweck und der Zielgruppe ab[cite: 43].

3.4 Kommunikation der Architektur

Zielgruppenanalyse: Wer sind die Stakeholder? Welche Informationen benötigen sie? In welcher Form?[cite: 44].
Kommunikationsmittel:
- Diagramme und Modelle[cite: 44].
- Schriftliche Dokumentation (Architekturhandbuch, Wikis)[cite: 44].
- Präsentationen und Workshops[cite: 44].
- Prototypen und Code-Beispiele[cite: 44].
Best Practices:
- Klare und präzise Sprache verwenden, Fachjargon vermeiden oder erklären[cite: 45].
- Visuelle Hilfsmittel einsetzen[cite: 45].
- Begründungen für Entscheidungen transparent machen[cite: 45].
- Interaktive Kommunikation fördern (Fragen, Feedback)[cite: 45].
- Dokumentation aktuell und leicht zugänglich halten[cite: 45].

Kapitel 4: Architekturbewertung und -governance

Lernziele des Kapitels:

Methoden zur Bewertung von IT-Architekturen kennenlernen (z.B. ATAM, Szenario-basiert)[cite: 46].
Qualitätsmerkmale von Architekturen (z.B. nach ISO 25010) verstehen und anwenden[cite: 46].
Konzepte der Architektur-Governance und deren Umsetzung in Organisationen verstehen[cite: 46].

4.1 Qualitätsmerkmale von IT-Architekturen

Definition Softwarequalität (ISO/IEC 25010): Grad, in dem ein Softwaresystem die festgelegten und impliziten Bedürfnisse seiner Stakeholder erfüllt[cite: 48].
Produktqualitätsmodell nach ISO/IEC 25010:
- Funktionale Eignung (Functional Suitability): Erfüllung der funktionalen Anforderungen (Vollständigkeit, Korrektheit, Angemessenheit)[cite: 48].
- Leistungseffizienz (Performance Efficiency): Zeitverhalten, Ressourcenverbrauch, Kapazität[cite: 48].
- Kompatibilität (Compatibility): Koexistenz, Interoperabilität mit anderen Systemen[cite: 48].
- Benutzbarkeit (Usability): Erlernbarkeit, Bedienbarkeit, Ästhetik, Fehlertoleranz für den Nutzer[cite: 49].
- Zuverlässigkeit (Reliability): Reife, Verfügbarkeit, Fehlertoleranz (System), Wiederherstellbarkeit[cite: 49].
- Sicherheit (Security): Vertraulichkeit, Integrität, Nichtabstreitbarkeit, Rechenschaftspflicht, Authentizität[cite: 49].
- Wartbarkeit (Maintainability): Modularität, Wiederverwendbarkeit, Analysierbarkeit, Modifizierbarkeit, Testbarkeit[cite: 49].
- Übertragbarkeit (Portability): Anpassbarkeit, Installierbarkeit, Austauschbarkeit[cite: 49].
Diese Qualitätsmerkmale (auch "ilities" genannt) sind oft Ziel von Architekturentscheidungen[cite: 50]. Es gibt oft Zielkonflikte zwischen ihnen (z.B. hohe Sicherheit vs. hohe Benutzbarkeit)[cite: 50].

4.2 Methoden zur Architekturbewertung

Zweck: Risiken frühzeitig erkennen, Qualität sicherstellen, Alternativen vergleichen, Kommunikation fördern[cite: 51].
Szenario-basierte Bewertung:
- Definiert Qualitätsanforderungen durch konkrete Szenarien (Anwendungsfälle, Änderungsfälle, Fehlerfälle)[cite: 52].
- Szenarien beschreiben, wie das System auf bestimmte Stimuli reagieren soll[cite: 52].
- ATAM (Architecture Tradeoff Analysis Method): Eine bekannte szenario-basierte Methode[cite: 53].
  - Schritte: Präsentation der Architektur, Identifikation von Business Drivers, Generierung von Qualitätsszenarien, Analyse der Architekturansätze bzgl. der Szenarien, Identifikation von Trade-offs, Risiken und Sensitivitätspunkten[cite: 53].
Weitere Methoden:
- SAAM (Software Architecture Analysis Method): Einfachere szenario-basierte Methode als ATAM[cite: 54].
- Checklisten-basierte Reviews: Prüfung anhand vordefinierter Kriterien und Fragen[cite: 54].
- Simulation und Prototyping: Zur Bewertung spezifischer Aspekte wie Performance[cite: 54].
- Formale Modellierung und Verifikation: Mathematische Nachweise von Eigenschaften[cite: 54].

4.3 Architektur-Governance

Definition: Sicherstellung, dass die IT-Architektur effektiv umgesetzt wird und mit den Geschäftszielen übereinstimmt. Umfasst Prozesse, Strukturen und Verantwortlichkeiten zur Steuerung der Architektur[cite: 55].
Ziele:
- Einhaltung von Architekturvorgaben und -standards[cite: 55].
- Konsistenz und Kohärenz der IT-Landschaft[cite: 55].
- Management von Ausnahmen und Änderungen an der Architektur[cite: 55].
- Sicherstellung des Business Value der Architektur[cite: 55].
Elemente der Governance:
- Architektur-Board (Architecture Review Board, ARB): Gremium zur Überprüfung und Genehmigung von Architekturentscheidungen[cite: 56].
- Architekturprozesse: Definierte Abläufe für Architekturentwicklung, -prüfung, -änderung[cite: 56].
- Architektur-Repository: Zentrale Ablage für Architekturartefakte und -standards[cite: 56].
- Rollen und Verantwortlichkeiten: Klare Zuweisung von Aufgaben im Architekturmanagement[cite: 56].
- Compliance-Überwachung: Regelmäßige Prüfung der Einhaltung von Vorgaben[cite: 56].
Architektur-Governance ist ein kontinuierlicher Prozess und integraler Bestandteil des EAM[cite: 57].

Kapitel 5: Business-IT-Alignment

Lernziele des Kapitels:

Bedeutung des Business-IT-Alignments für den Unternehmenserfolg verstehen[cite: 58].
Modelle und Frameworks zur Analyse und Verbesserung des Alignments kennenlernen[cite: 58].
Strategien zur Förderung der Zusammenarbeit zwischen Fachbereichen und IT entwickeln[cite: 58].

5.1 Definition und Bedeutung

Definition Business-IT-Alignment: Grad der Übereinstimmung und Koordination zwischen der Geschäftsstrategie und der IT-Strategie sowie deren Umsetzung[cite: 60]. Es geht darum, wie gut die IT die aktuellen und zukünftigen Geschäftsziele unterstützt[cite: 60].
Bedeutung:
- Wettbewerbsvorteile: IT als Enabler für neue Geschäftsmodelle und Effizienzsteigerungen[cite: 60].
- Wertbeitrag der IT: Sicherstellung, dass IT-Investitionen den maximalen Nutzen für das Geschäft bringen[cite: 60].
- Agilität: Schnellere Reaktion auf Marktveränderungen durch flexible IT-Systeme[cite: 60].
- Risikomanagement: Reduktion von Fehlinvestitionen und projektbezogenen Risiken[cite: 60].
Fehlendes Alignment führt oft zu Ineffizienz, hohen Kosten, verpassten Chancen und Frustration auf beiden Seiten (Business und IT)[cite: 61].

5.2 Ebenen des Alignments

Strategisches Alignment: Übereinstimmung der langfristigen Ziele und Pläne von Business und IT[cite: 62].
- IT-Strategie leitet sich aus der Geschäftsstrategie ab.
- IT versteht die Geschäftsziele, Business versteht die Potenziale der IT.
Strukturelles Alignment: Anpassung der Organisationsstrukturen, Prozesse und Rollen, um die Zusammenarbeit zu fördern[cite: 62].
- Z.B. gemeinsame Gremien, klare Verantwortlichkeiten für Business-IT-Schnittstellen.
Soziales Alignment: Qualität der Beziehung und Kommunikation zwischen Business- und IT-Mitarbeitern[cite: 63].
- Gegenseitiges Verständnis, Vertrauen, gemeinsame Sprache.
Technisches Alignment: Sicherstellung, dass die IT-Infrastruktur und Anwendungen die Geschäftsprozesse optimal unterstützen[cite: 63].
- Flexibilität, Skalierbarkeit, Interoperabilität der Systeme.

5.3 Modelle zum Business-IT-Alignment

Strategic Alignment Model (SAM) von Henderson und Venkatraman: Ein bekanntes Modell, das vier Domänen betrachtet[cite: 64]:
- Geschäftsstrategie (Business Strategy)
- IT-Strategie (IT Strategy)
- Organisationsinfrastruktur und -prozesse (Organizational Infrastructure and Processes)
- IT-Infrastruktur und -prozesse (IT Infrastructure and Processes)
- Das Modell beschreibt verschiedene Alignment-Perspektiven (z.B. "Strategy Execution", "Technology Transformation") basierend darauf, welche Domäne die treibende Kraft ist und welche Domänen angepasst werden[cite: 64].
Luftman's Strategic Alignment Maturity Model: Beschreibt fünf Reifegrade des Alignments, von "Initial/Ad Hoc" bis "Optimized/Pervasive"[cite: 65].
- Hilft Organisationen, ihren aktuellen Stand zu bewerten und Verbesserungsmaßnahmen abzuleiten[cite: 65].

5.4 Erfolgsfaktoren und Barrieren

Erfolgsfaktoren:
- Top-Management-Unterstützung: Commitment der Führungsebene ist entscheidend[cite: 66].
- Gemeinsame Vision und Ziele: Klares Verständnis und Akzeptanz der Strategien[cite: 66].
- Effektive Kommunikation: Regelmäßiger Austausch, gemeinsame Sprache[cite: 66].
- Partnerschaftliche Zusammenarbeit: Business und IT als gleichberechtigte Partner[cite: 66].
- Klare Governance-Strukturen: Definierte Prozesse und Verantwortlichkeiten für Entscheidungen[cite: 66].
- Messung und Controlling: KPIs zur Überwachung des Alignments und des Wertbeitrags der IT[cite: 66].
Barrieren:
- Fehlendes Verständnis füreinander (IT versteht Business nicht und umgekehrt)[cite: 67].
- Unterschiedliche Prioritäten und Ziele[cite: 67].
- Mangelnde Kommunikation und "Silodenken"[cite: 67].
- Kurzfristige Orientierung statt strategischer Planung[cite: 67].
- Unzureichende Einbindung der IT in strategische Geschäftsprozesse[cite: 67].
- Komplexität der IT-Landschaft und Legacy-Systeme[cite: 67].

Kapitel 6: Aktuelle Trends und Ausblick

Lernziele des Kapitels:

Wichtige aktuelle Trends im IT-Architekturmanagement identifizieren (z.B. Cloud Computing, Microservices, DevOps, KI)[cite: 68].
Auswirkungen dieser Trends auf die Gestaltung und Verwaltung von IT-Architekturen analysieren[cite: 68].
Zukünftige Herausforderungen und Entwicklungsperspektiven des EAM einschätzen[cite: 68].

6.1 Cloud Computing

Definition: Bereitstellung von IT-Ressourcen (Rechenleistung, Speicher, Anwendungen) über das Internet als Service[cite: 70].
Servicemodelle:
- IaaS (Infrastructure as a Service): Bereitstellung von virtueller Infrastruktur (Server, Netzwerke, Speicher)[cite: 70].
- PaaS (Platform as a Service): Bereitstellung einer Plattform für Entwicklung, Test und Betrieb von Anwendungen[cite: 70].
- SaaS (Software as a Service): Bereitstellung von Standardsoftware über das Netz[cite: 70].
Deploymentmodelle: Public Cloud, Private Cloud, Hybrid Cloud, Community Cloud[cite: 71].
Auswirkungen auf Architektur:
- Erfordert neue Architekturmuster (z.B. Cloud-native Architekturen)[cite: 71].
- Fokus auf Skalierbarkeit, Elastizität, Ausfallsicherheit[cite: 71].
- Sicherheits- und Datenschutzaspekte müssen besonders berücksichtigt werden (Datenhoheit)[cite: 71].
- Management von Multi-Cloud-Umgebungen wird zur Herausforderung[cite: 71].
- Kostenmanagement (Pay-per-Use) erfordert genaue Überwachung[cite: 71].

6.2 Microservices-Architekturen

Definition: Architekturstil, bei dem eine komplexe Anwendung als eine Suite kleiner, unabhängiger Dienste (Microservices) entwickelt wird[cite: 72]. Jeder Service läuft in seinem eigenen Prozess und kommuniziert über leichtgewichtige Mechanismen (oft HTTP-APIs)[cite: 72].
Vorteile:
- Unabhängige Entwicklung und Deployment: Teams können Services autonom entwickeln und bereitstellen[cite: 72].
- Technologische Vielfalt: Unterschiedliche Technologien für verschiedene Services möglich[cite: 72].
- Bessere Skalierbarkeit: Einzelne Services können gezielt skaliert werden[cite: 72].
- Fehlertoleranz: Ausfall eines Services beeinträchtigt nicht zwingend das Gesamtsystem[cite: 72].
Herausforderungen:
- Erhöhte Komplexität im Betrieb (Deployment, Monitoring, Service Discovery)[cite: 73].
- Verteilte Transaktionen und Datenkonsistenz[cite: 73].
- Notwendigkeit robuster Kommunikationsmechanismen und Fehlerbehandlung (z.B. Circuit Breaker)[cite: 73].
- Höherer Testaufwand für Integrationstests[cite: 73].
Steht im Kontrast zu monolithischen Architekturen[cite: 72].

6.3 DevOps und Agile Methoden

DevOps: Kultur und Praxis, die Entwicklung (Dev) und IT-Betrieb (Ops) enger zusammenführt, um Software schneller und zuverlässiger bereitzustellen[cite: 74].
- Fokus auf Automatisierung (CI/CD - Continuous Integration / Continuous Delivery oder Deployment)[cite: 74].
- Enge Zusammenarbeit und gemeinsame Verantwortung[cite: 74].
Agile Methoden (z.B. Scrum, Kanban): Iterative und inkrementelle Ansätze zur Softwareentwicklung[cite: 75].
- Fokus auf Flexibilität, schnelle Feedbackzyklen, Anpassung an Änderungen[cite: 75].
Auswirkungen auf Architektur:
- Architektur muss Agilität unterstützen (z.B. durch Modularität, lose Kopplung wie bei Microservices)[cite: 74, 75].
- "Evolutionäre Architekturen": Architektur wird nicht vorab komplett festgelegt, sondern entwickelt sich iterativ weiter[cite: 75].
- Infrastruktur als Code (IaC) zur Automatisierung der Bereitstellung[cite: 74].
- Kontinuierliches Architekturfeedback und -anpassung[cite: 75].

6.4 Künstliche Intelligenz (KI) und Maschinelles Lernen (ML)

KI/ML in der IT-Architektur:
- AIOps (AI for IT Operations): Einsatz von KI/ML zur Automatisierung und Optimierung von IT-Betriebsprozessen (z.B. Anomalieerkennung, prädiktive Wartung)[cite: 76].
- KI-gestützte Architekturentscheidungen: Analyse von Daten zur Optimierung von Architekturen (z.B. Performance-Vorhersagen, automatische Skalierung)[cite: 76].
- Architekturen für KI-Anwendungen: Entwicklung von Systemen, die KI/ML-Modelle integrieren und nutzen (z.B. Architekturen für Datenpipelines, Modelltraining, Inferenz)[cite: 77].
Herausforderungen:
- Datenmanagement (Qualität, Menge, Verfügbarkeit)[cite: 77].
- Rechenintensive Workloads[cite: 77].
- Erklärbarkeit und Nachvollziehbarkeit von KI-Entscheidungen (Explainable AI - XAI)[cite: 77].
- Ethik und Bias in KI-Modellen[cite: 77].

6.5 Nachhaltigkeit in der IT (Green IT)

Definition Green IT: Bestrebungen, die Nutzung von Informations- und Kommunikationstechnologie (IKT) über deren gesamten Lebenszyklus hinweg umwelt- und ressourcenschonend zu gestalten[cite: 78].
Aspekte:
- Energieeffizienz von Rechenzentren und Endgeräten[cite: 78].
- Reduktion von Elektroschrott durch längere Nutzungszyklen und Recycling[cite: 78].
- Nachhaltige Softwareentwicklung (z.B. Optimierung von Algorithmen für geringeren Ressourcenverbrauch)[cite: 78].
Auswirkungen auf Architektur:
- Berücksichtigung von Energieverbrauch und Ressourceneffizienz als Architekturziele[cite: 79].
- Auswahl energieeffizienter Hardware und Technologien[cite: 79].
- Cloud Computing kann (richtig eingesetzt) zur Ressourceneinsparung beitragen[cite: 79].
- Design for Longevity: Systeme so gestalten, dass sie länger nutzbar sind[cite: 79].

6.6 Ausblick und zukünftige Herausforderungen für EAM

Zunehmende Komplexität und Dynamik der IT-Landschaften[cite: 80].
Notwendigkeit, EAM agiler und adaptiver zu gestalten[cite: 80].
Stärkere Integration von EAM mit anderen Managementdisziplinen (Risiko-, Sicherheits-, Finanzmanagement)[cite: 80].
Fachkräftemangel im Bereich IT-Architektur[cite: 80].
Umgang mit ethischen Fragestellungen und gesellschaftlicher Verantwortung der IT[cite: 80].

Wichtige Links

Studium an der IU Internationale Hochschule am Standort Hannover im Zeitraum von Oktober 2022 bis April 2026