Enterprise Architecture Management (EAM) bezeichnet die systematische Gestaltung und Weiterentwicklung der Unternehmensarchitektur. Es verbindet Geschäftsziele mit Geschäftsprozessen, Fähigkeiten, Informationen, Anwendungen und technischer Infrastruktur.
Methodik und Funktionsweise
EAM nutzt Architekturprinzipien, Zielbilder, Bestandsaufnahmen und Veränderungsroadmaps. Architektursichten helfen, Abhängigkeiten und Auswirkungen geplanter Maßnahmen zu erkennen. Rahmenwerke wie TOGAF können methodische Orientierung bieten, ersetzen aber keine unternehmensspezifische Ausgestaltung.
Abgrenzung und Grenzen
EAM ist nicht mit IT-Betriebsmanagement gleichzusetzen. Es verfolgt eine übergreifende Architekturperspektive. Ebenso ist ein Architekturmodell noch kein digitaler Unternehmenszwilling, auch wenn es dessen strukturelle Grundlage sein kann.
Praxisbeispiel
Bei der Konsolidierung einer Systemlandschaft lässt sich nachvollziehen, welche Anwendungen dieselbe Geschäftsfähigkeit unterstützen und welche Schnittstellen beim Ersatz betroffen sind.
Voraussetzungen und Hinweise
Architekturarbeit sollte auf konkrete Entscheidungen ausgerichtet sein. Modelle ohne Governance, Verantwortlichkeiten und Pflege veralten und verlieren ihren Nutzen.
Die Verbindung von Geschäftsstrategie und IT-Landschaft
Enterprise Architecture Management verbindet fachliche Ziele mit den Fähigkeiten, Prozessen, Informationsobjekten, Anwendungen und technischen Komponenten eines Unternehmens. Die Architekturperspektive hilft, lokale IT-Entscheidungen in einen übergreifenden Zusammenhang einzuordnen. Eine Anwendung kann beispielsweise mehrere Geschäftsfähigkeiten unterstützen, während eine Geschäftsfähigkeit von verschiedenen Systemen abhängig ist. Ohne diese Transparenz können bei Systemwechseln wichtige Schnittstellen übersehen werden. EAM soll solche Risiken durch gemeinsame Modelle, Prinzipien und Entscheidungsregeln reduzieren. Es übernimmt jedoch nicht automatisch die operative Führung aller betroffenen Einheiten.
Architekturprinzipien, Ist-Bild und Zielbild
Ein EAM-Prozess beschreibt die vorhandene Architektur und entwickelt ein begründetes Zielbild. Architekturprinzipien geben Orientierung, beispielsweise zur Wiederverwendung bestimmter Schnittstellen oder zur Verantwortung für Stammdaten. Solche Prinzipien sollten nicht abstrakt bleiben, sondern auf konkrete Entscheidungen angewandt werden. Ein Zielbild zeigt außerdem, welche Fähigkeiten und Anwendungen künftig benötigt werden und welche Abhängigkeiten bei der Umsetzung bestehen. Die Entwicklung erfolgt idealerweise gemeinsam mit Fachbereichen und IT-Verantwortlichen. Ein rein technisches Zielbild kann wichtige organisatorische Anforderungen übersehen, während eine ausschließlich betriebswirtschaftliche Sicht notwendige Integrationsaufwände unterschätzt.
Architektur-Roadmap und Projektportfolio
Zwischen vorhandener und gewünschter Architektur liegen meist mehrere Veränderungsschritte. Eine Roadmap kann festhalten, welche Anwendungen zuerst ersetzt, welche Daten migriert und welche Übergangslösungen benötigt werden. Dabei sind Abhängigkeiten und begrenzte Ressourcen zu berücksichtigen. EAM liefert damit Informationen für Projektportfolio- und Transformationsentscheidungen. Es sollte aber nicht mit dem operativen Projektmanagement verwechselt werden. Termin- und Budgetverantwortung müssen weiterhin klar zugeordnet sein. Wenn sich Geschäftsziele oder technische Rahmenbedingungen verändern, ist das Architekturzielbild regelmäßig neu zu bewerten.
Governance und laufende Architekturpflege
Ein Architekturmodell verliert seinen Wert, wenn es nur im Rahmen eines einmaligen Projekts erstellt wird. Deshalb braucht EAM Regeln zur Aktualisierung, Verantwortliche für einzelne Architekturelemente und eine nachvollziehbare Behandlung von Ausnahmen. Nicht jede Abweichung von einem Zielprinzip ist automatisch unzulässig; Ausnahmen können wirtschaftlich oder technisch begründet sein. Diese Entscheidungen sollten jedoch dokumentiert werden. Die Wirksamkeit von EAM lässt sich an verbesserten Entscheidungsgrundlagen, transparenteren Abhängigkeiten und einer verlässlichen Weiterentwicklung der Architektur beurteilen. Die reine Anzahl dokumentierter Systeme ist dafür kein ausreichender Maßstab.
Häufige Fragen
Ist Enterprise Architecture Management ein IT-Thema?
Es verbindet Geschäftsziele, Organisation und IT. Ein rein auf technische Systeme beschränkter Ansatz greift für viele Architekturentscheidungen zu kurz.
Muss ein Unternehmen TOGAF vollständig übernehmen?
Nein. Rahmenwerke geben Orientierung. Methoden, Rollen und Detailtiefe sollten auf Größe, Ziele und Entscheidungsbedarf der Organisation abgestimmt werden.
Praktische Prüffragen
- Leiten Sie Architekturprinzipien aus tatsächlichen Geschäftszielen ab, damit technische Vorgaben bei Investitionsentscheidungen nachvollziehbar begründet sind.
- Dokumentieren Sie Geschäftsprozesse, Fähigkeiten, Anwendungen und Datenbeziehungen in konsistenten Sichten, statt voneinander isolierte IT-Inventare zu pflegen.
- Unterscheiden Sie den dokumentierten Ist-Zustand von der geplanten Zielarchitektur und erfassen Sie Abhängigkeiten zwischen notwendigen Migrationsschritten.
- Legen Sie fest, wer über Architekturabweichungen entscheidet und wie begründete Ausnahmen transparent dokumentiert und überprüft werden.
- Beurteilen Sie EAM anhand besserer Projektentscheidungen und reduzierter Unsicherheit, nicht allein anhand der Zahl katalogisierter Anwendungen.
Bei größeren Organisationen sollte zusätzlich feststehen, wie Geschäfts- und IT-Verantwortliche gemeinsam über widersprüchliche Zielarchitekturen und begründete Ausnahmen entscheiden.
Architekturentscheidungen mit Geschäftszielen verknüpfen
Enterprise Architecture Management betrachtet eine Unternehmensarchitektur aus mehreren Perspektiven. Eine neue IT-Anwendung sollte nicht allein anhand ihrer technischen Merkmale beurteilt werden, sondern danach, welche Geschäftsprozesse und Fähigkeiten sie unterstützt. Das setzt nachvollziehbare Beziehungen zwischen fachlichen Anforderungen, Anwendungen, Daten und technischen Komponenten voraus. Architekturprinzipien können Entscheidungen unterstützen, etwa zur Integration oder zur Verantwortlichkeit für Stammdaten. Sie sollten jedoch konkret begründet sein. Bei einer größeren Systemlandschaft sind auch historische Abhängigkeiten und Übergangslösungen zu berücksichtigen. Ein konsistentes Architekturmodell hilft, diese Komplexität zu verstehen, ersetzt aber nicht die wirtschaftliche Bewertung und fachliche Priorisierung einzelner Vorhaben.
Zielarchitektur und Übergang planen
Eine Zielarchitektur beschreibt den angestrebten Zustand. Für ihre Umsetzung benötigt das Unternehmen eine nachvollziehbare Reihenfolge von Maßnahmen. Wenn eine Anwendung ersetzt wird, können Datenmigration, Schnittstellenänderungen, Prozessschulungen und organisatorische Entscheidungen voneinander abhängen. Eine Roadmap sollte diese Beziehungen sowie notwendige Zwischenzustände sichtbar machen. Verantwortlichkeiten für Abweichungen und Zielkonflikte müssen geregelt sein. Eine Architekturgestaltung, die auf Veränderungen nicht reagiert, veraltet schnell. Deshalb sollten neue Geschäftsprioritäten und technische Rahmenbedingungen regelmäßig in die Planung einfließen. TOGAF und ArchiMate bieten methodische Orientierung, müssen aber auf den tatsächlichen Organisationsbedarf angepasst werden; ihre Nutzung garantiert keine erfolgreiche Transformation.
Verwandte Wiki-Begriffe
Weiterführende Erklärungen: Unternehmensmodellierung, Enterprise Model, Datenintegration.
Fachliche Quellen
The Open Group – TOGAF Standard. Praxisbeispiele sind redaktionelle Szenarien ohne behaupteten Kundenbezug.