Warum EAM-Einführungen scheitern — nicht am Metamodell, an der Pflege
Die Werkzeuge sind gut, die Metamodelle durchdacht, die Einführungsprojekte gründlich — und achtzehn Monate später ist das Repository trotzdem veraltet und das Management-Vertrauen weg. Eine Fehleranalyse entlang des typischen Lebenszyklus einer EAM-Einführung und die eine Designentscheidung, die den Unterschied macht.
Es gibt ein Projektmuster, das sich in der Enterprise-Architektur mit bemerkenswerter Zuverlässigkeit wiederholt. Jahr eins: Werkzeugauswahl, Metamodell-Workshops, initiale Befüllung, stolze Präsentation der ersten Landkarte. Jahr zwei: Die Landkarte wird für den Strategietermin „noch einmal kurz aktualisiert". Jahr drei: Die Frage im Lenkungskreis, ob man das Werkzeug eigentlich noch braucht.
Das Bemerkenswerte daran: Gescheitert ist in dieser Geschichte fast nie die Software, und so gut wie nie das Metamodell. Gescheitert ist die Pflege — und zwar an vorhersagbaren Stellen.
Todesursache 1: Die Einmalbefüllung
Die initiale Datenerhebung ist der angenehmste Teil jeder Einführung: Es gibt ein Projektbudget, externe Unterstützung, einen Termin. Interviews werden geführt, Excel-Bestände importiert, die Landkarte füllt sich. Was dabei entsteht, ist eine Inventur — eine Momentaufnahme mit Verfallsdatum. Ab dem Tag nach der Befüllung beginnt die Landschaft, sich von ihrem Abbild zu entfernen: Systeme kommen, Verantwortliche wechseln, Verträge ändern sich.
Die Inventur ist nicht falsch — sie ist nur kein Betriebsmodell. Der Fehler liegt im Projektplan, der mit der Befüllung endet: Das eigentliche Produkt einer EAM-Einführung ist nicht der gefüllte Bestand, sondern der Mechanismus, der ihn gefüllt hält. Wo dieser Mechanismus fehlt, ist das Werkzeug ein teurer Ordner.
Todesursache 2: Der Architekt als Flaschenhals
Das klassische Betriebsmodell macht das Architekturteam zum Redaktionsbüro: Änderungen werden gemeldet (oder auch nicht), Architekten tragen nach. Das funktioniert bei fünfzig Anwendungen und stirbt bei fünfhundert — nicht weil die Architekten zu langsam wären, sondern weil sie nicht wissen können, was sich draußen ändert. Der Fachbereich weiß es. Der weiß aber oft nicht, dass es ein Repository gibt, und hätte auch wenig Grund, es zu füttern.
Skalierbar ist nur die umgekehrte Richtung: Die Angabe wird von dem gepflegt, der sie weiß — und das ist fast nie der Architekt. Der Systemverantwortliche weiß, ob sein System noch läuft; der Vertragsverantwortliche kennt die Kündigungsfrist; der Bereichsleiter weiß, wer zuständig ist. Die Aufgabe des Werkzeugs ist, diesen Menschen die Pflege so leicht zu machen, dass sie nebenbei geschieht: den eigenen kleinen Ausschnitt zeigen, konkret fragen, mit einem Klick bestätigen lassen. Wer stattdessen vierzig Pflichtfelder und eine Modellierungsschulung verlangt, hat sich entschieden — gegen die Daten.
Todesursache 3: Pflege ohne Gegenleistung
Die stillste Todesursache ist ökonomischer Natur. Pflege ist ein Tauschgeschäft: Menschen halten Daten aktuell, wenn sie selbst etwas davon haben. Im klassischen EAM fließt aber alles in eine Richtung — der Fachbereich liefert, die Auswertung sieht der Lenkungskreis. Wer liefert, bekommt: nichts. Solche Systeme laufen genau so lange, wie jemand mit Autorität nachhält, und keinen Quartalswechsel länger.
Die Gegenprobe kennt jeder aus dem Alltag: Kalender werden gepflegt, weil der Pflegende selbst hineinschaut. Ein Landschaftsbestand kippt in denselben Modus, sobald er dem Verantwortlichen etwas zurückgibt — seine eigenen Systeme auf einen Blick, seine auflaufenden Vertragsfristen, die Antwort auf „was hängt an meinem System?", bevor das nächste Projekt sie teuer recherchiert.
Die eine Designentscheidung
Alle drei Ursachen haben dieselbe Wurzel: Die Einführung wurde um das Modell herum geplant statt um den Pflegeweg. Die Reihenfolge gehört umgedreht. Erst: Wer bestätigt welche Angabe, wie oft, mit wie viel Aufwand, und was bekommt er dafür? Dann: Welches Modell trägt das? Ein bescheidenes Modell mit funktionierendem Kreislauf liefert nach einem Jahr einen Bestand, dem man glaubt. Ein brillantes Modell ohne Kreislauf liefert eine Momentaufnahme mit Konferenzraum-Halbwertszeit — und beim dritten veralteten Bericht ist nicht das Werkzeug verbrannt, sondern die Idee. Das ist der teuerste Schaden: Die zweite EAM-Einführung im selben Haus hat es doppelt so schwer wie die erste.
Häufige Fragen
Woran erkennt man ein scheiterndes EAM-Vorhaben früh?
Am Verhältnis von Lesen zu Schreiben. Ein gesundes Repository wird von vielen gelesen und von vielen — verteilt — aktualisiert. Ein kippendes wird von wenigen gelesen und nur noch vom Architekturteam geschrieben. Sobald Berichte für Termine „vorher kurz aktualisiert" werden müssen, ist der Kreislauf bereits gerissen; das Aktualisieren vor dem Termin ist das sicherste Frühwarnzeichen.
Ist ein besseres Metamodell die Lösung?
Selten. Metamodell-Diskussionen sind angenehm, weil sie im eigenen Team entschieden werden können — die Pflegefrage dagegen erfordert, andere Menschen zu Beteiligten zu machen. Die meisten gescheiterten Einführungen hatten ein völlig ausreichendes Metamodell und keinen funktionierenden Pflegeweg. Wer wählen muss, wählt den einfacheren Modellrahmen mit dem besseren Pflegeweg.
Warum funktioniert die jährliche Datensammel-Aktion nicht?
Weil sie Aufwand bündelt und Nutzen verzögert: Einmal im Jahr müssen alle liefern, und was geliefert wird, veraltet ab dem Folgetag wieder. Die Alternative ist der stetige Kreislauf — kleine, regelmäßige Bestätigungen durch die, die es wissen, mit sichtbarem Ergebnis. Zehn Minuten pro Quartal je Verantwortlichem schlagen die Drei-Wochen-Aktion im Herbst, in Datenqualität wie in Akzeptanz.
Was hat der Fachverantwortliche davon, zu pflegen?
Im klassischen Modell: nichts — er füttert ein Architektenwerkzeug, dessen Auswertungen er nie sieht. Das ist der Konstruktionsfehler. Tragfähig wird die Pflege, wenn der Pflegende selbst etwas zurückbekommt — seine eigene Systemübersicht, seine auflaufenden Fristen, Antworten auf seine Fragen. Pflege ist ein Tauschgeschäft; wo nichts zurückfließt, versiegt sie.
Der Pflegeweg ist das Produkt
blueprAInt ist um den Kreislauf herum gebaut, nicht um das Modell — die Antwort auf alle drei Todesursachen.
- Gegen die Einmalbefüllung: Kampagnen fragen die Fachverantwortlichen regelmäßig und konkret — der Bestand bleibt gefüllt, statt ab Tag 1 zu veralten. Der Bestätigungsgrad zeigt ehrlich, wo der Kreislauf greift.
- Gegen den Flaschenhals: Jeder pflegt nur seine eigenen Angaben, mit einem Klick, ohne Modellierungsschulung — die Architekten kuratieren, statt abzutippen. Vererbung erledigt den Rest.
- Gegen die Pflege ohne Gegenleistung: Wer pflegt, bekommt zurück — die eigene Systemübersicht, die eigenen auflaufenden Fristen, die Antwort auf „was hängt an meinem System?". Pflege wird zum Tauschgeschäft, das sich für beide Seiten lohnt.