„Enterprise Architecture Management" – kurz EAM – ist einer dieser Begriffe, bei denen viele IT-Verantwortliche im Mittelstand innerlich abschalten. Er klingt nach Großkonzern, nach Beratern mit Tagessätzen, nach einem Elfenbeinturm, in dem Architekten Diagramme malen, die mit dem Alltag wenig zu tun haben.
Diese Reaktion ist verständlich. Sie ist aber auch ein Missverständnis. Hinter dem sperrigen Begriff steckt eine simple, nützliche Idee – und ihr braucht davon nur die 80 %, die im Tagesgeschäft wirklich etwas bringen.
Was hinter dem sperrigen Begriff steckt
Im Kern will EAM eine einzige, sehr bodenständige Frage beantworten: Welche Systeme haben wir, wofür nutzen wir sie, wer ist verantwortlich, und wie hängen sie zusammen?
Das ist kein Hexenwerk und keine akademische Disziplin – das ist die Grundlage dafür, eine IT überhaupt steuern zu können statt ihr nur hinterherzulaufen. Jedes IT-Team beantwortet diese Frage ständig, meist nur aus dem Gedächtnis einzelner Personen. EAM heißt erst mal nur: diese Antworten an einen Ort zu schreiben, an dem sie aktuell bleiben.
Warum EAM den Ruf des Elfenbeinturms hat
Der schlechte Ruf kommt nicht von der Idee, sondern von den Werkzeugen, die den Markt prägen. Plattformen wie LeanIX oder Ardoq und schwergewichtige Frameworks sind für Konzern-Architekten gebaut:
- vollständige Metamodelle, die erst monatelang konfiguriert werden
- Rollout-Projekte mit externer Beratung und eigenem EA-Team
- Mehrjahres-Roadmaps und Zeremonien, die ein dediziertes Team voraussetzen
Für ein IT-Team mit 30 bis 150 Anwendungen ist das schlicht ein paar Nummern zu groß. Es „overshootet" – es liefert eine Komplexität, die zum Problem nie gepasst hat. Kein Wunder, dass viele bei „EAM" abwinken: Sie lehnen nicht den Nutzen ab, sondern den Overhead.
Die nützlichen 80 % – das, was im Alltag wirklich zählt
Aus dem gesamten Methoden-Baukasten braucht der Mittelstand nur einen kleinen Teil – und genau dieser Teil bringt den Großteil des Nutzens:
- Ein aktuelles Applikationsinventar: welche Systeme laufen, wofür
- Verantwortlichkeiten je System: wer technisch, wer fachlich zuständig ist
- Kritikalität: wie schwer ein Ausfall das Geschäft trifft
- Abhängigkeiten und Dienstleister: was woran hängt, wer Zugriff hat
- optional eine grobe Zuordnung zu Geschäftsfähigkeiten – „welche Apps stützen welchen Geschäftsbereich", ohne ein vollständiges Modell
Und genauso wichtig ist, was ihr nicht braucht: keine vollständigen Metamodelle, keine Fünf-Jahres-Architektur-Roadmaps, keine Framework-Zeremonie, kein eigenes Architektur-Team. Das sind die akademischen 20 %, die den Aufwand explodieren lassen – und den Nutzen kaum erhöhen.
Warum 80 % reicht – und 100 % oft schadet
80 % korrekt und gepflegt schlägt 100 % vollständig und veraltet.
Ein überladenes Modell hat ein praktisches Problem: Niemand pflegt es. Es ist nach der Einführung beeindruckend und nach einem halben Jahr Fiktion. Das schlanke Inventar dagegen, das wenige, aber wichtige Felder führt, wird im Alltag genutzt – und bleibt deshalb aktuell. Vollständigkeit ist kein Selbstzweck. Brauchbarkeit ist es.
„Easy to use" heißt: euer Team macht es selbst
Der eigentliche Unterschied zwischen Elfenbeinturm und Werkzeug ist nicht der Funktionsumfang – es ist die Frage, wer es bedient. Wenn ihr für den Überblick über eure IT einen Berater oder einen Spezialisten braucht, habt ihr kein Werkzeug, sondern ein Projekt. Die nützlichen 80 % lassen sich self-serve umsetzen: in Stunden statt Monaten, vom eigenen Team, ohne Schulungsmarathon.
Das ist auch der Grund, warum dieser Überblick eine menschliche, bewusste Tätigkeit bleibt und kein reines Auslesen von Daten: Welche Systeme wie betrieben werden sollen, ist eine Entscheidung – kein Scan.
Fazit
Ihr müsst kein Enterprise-Architekt werden, um den Nutzen von Enterprise Architecture zu haben. Nehmt aus der Methode die 80 %, die im Alltag tragen – das Inventar, die Verantwortlichkeiten, die Kritikalität, die Abhängigkeiten – und lasst den Elfenbeinturm stehen. Genau das ist der Anspruch eines pragmatischen Werkzeugs für den Mittelstand.
Weiterlesen: IT-Dokumentation in 5 Schritten aufbauen · IST und SOLL: Warum automatisches Asset Management nicht reicht