EAM einführen: In 6 Schritten zu funktionierendem Enterprise Architecture Management

Kurzfassung: Eine EAM-Einführung scheitert selten an der Methode und fast immer am Betriebsmodell. Wer mit der vollständigen Aufnahme der Ist-Landschaft beginnt, verliert die Aufmerksamkeit der Leitung, bevor der erste Nutzen sichtbar wird. Dieser Artikel beschreibt das Vorgehen, das sich in Portamus-Kundenprojekten bewährt hat: sechs Schritte von der Zielsetzung über Metamodell und Zielbild bis zur Verankerung in Projektfreigabe, Beschaffung und Change – mit Zeitachse, Rollen und Kennzahlen. Was Enterprise Architecture Management inhaltlich ist, setzen wir dabei voraus; hier geht es um die Einführung.

Das Wichtigste in Kürze

• Anwendungsfälle zuerst. Drei konkrete Entscheidungen, die EAM verbessern soll – sonst entsteht Dokumentation ohne Adressat.
• Betriebsmodell vor Datenaufnahme. Rollen, Mandat und Kapazität entscheiden über den Fortbestand.
• Minimales Metamodell, rund ein Dutzend Objekttypen. Erweiterung nur bei nachgewiesenem Bedarf.
• Erster Nutzen in 90–120 Tagen, nicht nach einem Jahr.
• Verankerung in Projektfreigabe, Beschaffung und Change ist der Schritt, der über Erfolg entscheidet.
• Tool zuletzt. Software skaliert eine Praxis; sie erzeugt keine.

Schritt 1: Zielsetzung und Anwendungsfälle

Die erste Frage lautet nicht „Welches Tool?“, sondern: Welche drei Entscheidungen sollen künftig besser getroffen werden? Typische Antworten aus unseren Projekten:

• „Wir wollen vor jeder Beschaffung wissen, ob die Funktion bereits lizenziert ist.“
• „Wir wollen die Auswirkung einer ERP-Ablösung auf Prozesse und Schnittstellen abschätzen können.“
• „Wir wollen End-of-Life-Risiken sehen, bevor der Hersteller den Support einstellt.“

Jeder Anwendungsfall bestimmt, welche Daten überhaupt gebraucht werden. Das ist der wirksamste Aufwandsfilter der gesamten Einführung: Ohne Anwendungsfall gibt es keinen Grund, ein Attribut zu pflegen.

Schritt 2: Betriebsmodell definieren

Bevor Daten erhoben werden, muss geklärt sein, wer EAM betreibt. Ein tragfähiges Modell umfasst mindestens:

Der Sponsor ist kein formaler Zusatz. Er entscheidet die unvermeidlichen Konflikte zwischen Projekttermin und Zielarchitektur – und ohne diese Instanz gewinnt in der Praxis immer der Termin. Wie Prinzipien, Board und Review-Gates konkret ausgestaltet werden, beschreibt EA-Governance.

Schritt 3: Minimales Metamodell und Bewertungsraster

Das Metamodell legt fest, welche Objekttypen und Attribute gepflegt werden. Unser Startpunkt umfasst rund ein Dutzend Typen:

Anwendung, Anwendungsservice, Geschäftsfähigkeit, Geschäftsprozess, Datenobjekt, Schnittstelle, Technologie-Baustein, Organisationseinheit, Projekt, Anforderung, Prinzip, Risiko.

Je Anwendung genügen zu Beginn wenige Attribute: Verantwortliche Person, Fachbereich, Kosten pro Jahr, Support-/Lifecycle-Status, führende Datenobjekte, Kritikalität. Ergänzt wird ein Bewertungsraster – wir nutzen das TIME-Modell (Tolerate, Invest, Migrate, Eliminate) aus dem Applikationsportfolio-Management, bewertet über fachlichen Wert und technische Qualität.

Modelliert wird, wo Zusammenhänge zählen, in ArchiMate – bewusst grob und auf wenige Viewpoints beschränkt.

Faustregel: Jedes Attribut braucht einen Anwendungsfall und eine Quelle. Attribute ohne beides werden nie gepflegt.

Schritt 4: Ist-Aufnahme – zielgerichtet, nicht vollständig

Die Bestandsaufnahme erfolgt entlang der Anwendungsfälle aus Schritt 1, nicht als Selbstzweck. Bewährte Quellen: Vertrags- und Lizenzverwaltung, Kostenstellenauswertungen, Berechtigungs- und Anmeldedaten, Betriebsdokumentation sowie strukturierte Interviews mit den Domänenverantwortlichen.

Zwei Praxishinweise aus unseren IT-Landschaftsanalysen:

• 80 % Datenqualität reichen für die erste Entscheidung. Der Weg von 80 auf 95 % kostet mehr als die ersten 80 – und wird ohne laufende Nutzung nie stabil.
• Schatten-IT gehört in den Bestand. Lizenzabrechnungen und Kreditkartenbelege der Fachbereiche sind dafür die verlässlichste Quelle.

Schritt 5: Zielbild und Roadmap

Aus bewertetem Bestand und fachlicher Strategie entsteht das Zielbild je Domäne – auf grober Flughöhe, mit klar benannten Ablösungen, Konsolidierungen und Investitionen. Aus dem Delta zwischen Ist und Ziel folgt die Roadmap: sequenzierte Vorhaben, priorisiert nach Risiko, Wertbeitrag und Abhängigkeiten.

Methodisch stützen wir uns auf die ADM-Phasen B bis F aus TOGAF, zugeschnitten auf Größe und Reifegrad der Organisation. Das Ergebnis ist kein Dokument für die Ablage, sondern die Vorlage, gegen die künftig jeder Projektantrag geprüft wird.

Schritt 6: Verankern – der Schritt, der über Erfolg entscheidet

EAM wirkt genau dort, wo es an bestehende Prozesse gekoppelt ist. Drei Kopplungen sind unverzichtbar:

Die dritte Kopplung ist die am häufigsten vergessene – und die wichtigste für die Datenaktualität. Ein Bestand, der nur in Kampagnen gepflegt wird, verliert innerhalb von zwei Jahren seine Glaubwürdigkeit; danach kehrt niemand mehr zurück.

Zeitachse und Erfolgskennzahlen

Messen Sie Entscheidungswirkung, nicht Dokumentationsgrad:

• Anteil der Projektanträge mit Architekturbewertung vor Budgetfreigabe.
• Anzahl abgelöster oder konsolidierter Redundanzsysteme.
• Vermiedene Doppelanschaffungen (dokumentierte Fälle).
• Aktualität des Bestands: Anteil der Einträge mit Pflegedatum jünger als sechs Monate.
• Durchlaufzeit einer Architekturentscheidung.

Warum EAM-Einführungen scheitern

• Vollständigkeitsanspruch. Die Ist-Aufnahme dauert länger als die Aufmerksamkeit der Leitung.
• Fehlendes Mandat. Empfehlungen ohne Entscheidungsrecht verlieren gegen Projekttermine.
• Kein Pflegeanlass. Ohne Kopplung an Change und Beschaffung veralten die Daten.
• Toolzentrierung. Die Software wird eingeführt, die Praxis nicht.
• Architektur im Elfenbeinturm. Ohne Domänenverantwortliche als Mitwirkende fehlt die fachliche Substanz.
• Kein sichtbarer Frühnutzen. Ohne erkennbares Ergebnis in den ersten Monaten fehlt die Rückendeckung für den Rest.

Häufige Fragen zur EAM-Einführung

Wie führt man Enterprise Architecture Management ein? In sechs Schritten: Zielsetzung und Anwendungsfälle, Betriebsmodell, minimales Metamodell, zielgerichtete Ist-Aufnahme, Zielbild und Roadmap, Verankerung in bestehende Prozesse.

Wie lange dauert die Einführung von EAM? Erster nutzbarer Stand nach drei bis vier Monaten; ein tragfähiges Betriebsmodell mit gelebter Pflegeroutine nach 12 bis 18 Monaten.

Welche Rollen braucht ein EAM-Betriebsmodell? Lead-Architektur, Domänenverantwortliche, eine Entscheidungsinstanz und einen Sponsor auf Leitungsebene.

Welches Metamodell braucht man für den Start? Ein minimales mit rund einem Dutzend Objekttypen; Erweiterung nur bei nachgewiesenem Anwendungsfall.

Was ist der Unterschied zwischen EAM einführen und ein EA-Tool einführen? EAM einführen etabliert eine Managementpraxis; ein Tool skaliert diese Praxis, ersetzt sie aber nicht.

Wie misst man den Erfolg? Über Entscheidungswirkung: bewertete Projektanträge, abgelöste Redundanzsysteme, vermiedene Doppelanschaffungen, Datenaktualität, Entscheidungsdurchlaufzeit.

Warum scheitern EAM-Einführungen? Vollständigkeitsanspruch, fehlendes Mandat, fehlende Pflegeanlässe, Toolzentrierung.

Welche Rolle spielt TOGAF? TOGAF liefert den methodischen Kern (Preliminary Phase und ADM); die EAM-Einführung umfasst zusätzlich Betriebsmodell, Datenpflege, Prozesskopplung und Kompetenzaufbau.

Fazit

Eine EAM-Einführung ist ein Organisations-, kein Dokumentationsvorhaben. Der Unterschied zwischen einer Praxis, die nach zwei Jahren noch lebt, und einem verwaisten Repository liegt in drei Entscheidungen: klare Anwendungsfälle statt Vollständigkeit, ein Betriebsmodell mit Mandat statt guter Absichten, und die Kopplung an Projektfreigabe, Beschaffung und Change statt einer jährlichen Pflegekampagne. Unsere Erfahrung aus Portamus-Projekten: Wer in den ersten 120 Tagen einen sichtbaren Nutzen liefert, bekommt die Zeit für den Rest.

Sie möchten EAM einführen – oder eine steckengebliebene Initiative wieder in Bewegung bringen? Wir bringen Anwendungsfälle, Betriebsmodell und Roadmap in eine Form, die Ihre Organisation trägt. → Portamus EA-Programmentwicklung entdecken

Quellen

• The Open Group: TOGAF Standard, 10th Edition – Preliminary Phase, ADM (2022)
• The Open Group: ArchiMate 3.2 Specification (2022)