Klassische EAM-Tools bündeln Datenhaltung (”Repository”), Benutzeroberfläche (Datenerfassung, Visualisierung) sowie funktionale Logik. Wir beobachten, dass diese Bündelung gerade auseinanderfällt. EAM-Tools werden headless: Oberfläche und Visualisierung wandern zum LLM, Datenhaltung und Funktionslogik bleibt im Tool.
EAM verliert dabei nicht an Bedeutung. Sie gewinnt sogar. Wer KI im Unternehmen einsetzen will, braucht strukturelles Wissen darüber, welche Systeme es gibt, wem sie gehören, welche Daten sie halten und wie sie zusammenhängen und strukturiert sind (siehe auch EAM mit KI oder KI mit EAM?). Sonst macht jeder Coding Agent was anderes.
Nicht nur EAM: Alle SaaS-Tools verlieren den Kopf
Das ist keine Eigenheit von EAM. Satya Nadella hat schon Ende 2024 beschrieben, was jetzt passiert: Business-Applikationen seien im Kern Datenbanken mit Geschäftslogik. Diese Logik wandere in die KI-Schicht. Die Hersteller reagieren: Salesforce hat mit «Headless 360» die eigene Oberfläche optional gemacht. EAM-Tools sind ein besonders klarer Fall, weil ihr Wert bisher stark an Visualisierung und Erfassungsmasken hing.
Stufe 1: Der Kopf fällt
Folgendes beobachen wir bei Kunden mit etablierten EAM-Tools: Sobald MCP Schnittstellen bereitstehen, brechen die Kunden aus dem “Korsett” der eingebauten Visualisierungen aus. Sie empfinden diese als limitiert und zu kompliziert. LLMs können doch heute “viel schönere” HTML-basierte Dashboards und Graphiken erzeugen.
Gleiches gilt für die Pflege von Inhalten. Die User Interfaces des EAM-Tools sind zu mühsam. Sobald MCP-Schnittstellen bereitsteht ist es viel einfacher in natürlicher Sprache Mutationen anzustossen oder zu automatisieren – auf Basis von Signalen aus dem Unternehmen und perspektivisch durch autonom laufende Agenten. Fragestellungen rund um Berechtigungsmodelle, Freigaben und Workflows löst das etablierte Tool weiterhin auf Basis der Identität, die der Agent oder das LLM mitgibt.
Die Ökonomie des Bündels
Gebündelt wurde bisher, weil es teuer war, Datenhaltung, Pflege und Visualisierung über Systemgrenzen hinweg zusammenzuhalten. MCP senkt genau diese Koordinationskosten: Über einen offenen Standard greift das LLM direkt auf die Daten im EAM-Tool zu. Gleichzeitig ist das LLM bei Visualisierung und Datenerfassung deutlich besser als eingebaute Masken und Vorlagen. Das ist die alte Einsicht von Adam Smith (1776): Spezialisierte Teile arbeiten produktiver als ein Alleskönner. Das LLM übernimmt den Kopf, das EAM-Tool bleibt der Rumpf.
Stufe 2: Eigenbau für erste Gehversuche
Ein Schweizer Versicherer ging sogar noch einen Schritt weiter. Ein EAM-Tool war noch nicht vorhanden und man wollte schnell weiterkommen. Also wurde leichterhand auch der “Rumpf” des EAM Tools mit KI-Coding erstellt:
Strukturierte Objekte wie Applikationen, Owner, Capabilities, Schnittstellen und Risiken liegen in einer relationalen Datenbank (basierend auf Seatable, also auch einfach menschenlesbar) mit referentieller Integrität. Narrative Artefakte wie Target Architecture, Architektur-Prinzipien und Architekturentscheide liegen als Markdown in Git.
Visualisierung auf Zuruf
Beim Versicherer erzeugt ein LLM Visualisierungen direkt aus den aktuellen Daten: Applikationslandschaft, Owner-Graph, Capability-Matrix, Risk Map, API Explorer. Eine neue Sicht ist eine Sache von Minuten. Sie entsteht dort, wo eine konkrete Frage gestellt wird. Neue Visualisierungen (z.B. ein Sankey-Diagramm oder eine Force-Directed Graph) sind jederzeit ergänzbar. Das ist viel einfacher als bei vielen kommerziellen EAM-Tools mit ihren teils beschränkten Vorlagen. Notwendige Erweiterungen des Metamodells gelingen im Handumdrehen.
Hier ein paar beispielhafte HTML Dashboards und Visualisierungen, erzeugt von Claude, wie wir sie mittlerweile alle kennen. Etwas geschwätzig, mit zu vielen redundanten und unnötigen Infos. Ein Human Interface Designer würde die Nase rümpfen. Dennoch: beeindruckend und brauchbar schon beim zweiten Durchlauf.
Für erste Gehversuche reicht das. Wer damit produktiv arbeiten will, muss aber selbst lösen, was ein etabliertes EAM-Tool mitbringt: Wer darf welche Daten ändern? Wer gibt eine Änderung frei? Was darf ein Agent ohne Freigabe tun? Beim Versicherer sind Berechtigungen und Freigaben noch nicht umgesetzt, das ist der nächste Schritt.
Was Headless EAM für EAM-Tools heisst
Der Wert eines EAM-Tools verschiebt sich zum Rumpf: Metamodell, offene API, Metadaten und die Daten selbst.. MCP-Zugriff auf alle Inhalte ist dabei ein Schlüsselfaktor. In unserem ITMC EAM-Tool-Assessment, das wir gemeinsam mit Kunden einsetzen, wird das Thema API, MCP und Schnittstellen deutlich wichtiger.
Bewertung von vier EAM-Tools mit dem ITMC EAM-Tool-Assessment (anonymisiert). Hervorgehoben sind Visualisierung und Datenpflege im Tool. Genau diese Kriterien verlieren mit LLM und Agenten an Gewicht.
ITMC Take-Away
Datenerfassung, Modellierung und Modellpflege werden durch KI deutlich erleichtert und teilweise automatisiert. Die User Interfaces und eingebauten Visualisierungen der EAM-Tools werden dadurch weniger wichtig. Der Wert eines EAM-Tools verschiebt sich zum Rumpf: Metamodell, offene API, Metadaten und die Daten selbst. Das führt zu aktuelleren, konsistenteren und umfassenderen Modellen, wie sie früher kaum möglich waren. Gartner spricht von einer «Living Architecture», die laufend nachgeführt wird (mehr dazu).
