IT-Teams haben heute mehr Werkzeuge denn je, um ihre Infrastruktur zu beobachten. Monitoring-Systeme, CMDB-Integrationen, Cloud-Discovery – sie alle erzeugen automatisch Inventare: Welche Server laufen, welche Container existieren, welche Services erreichbar sind. Das ist wertvoll, es rechnet sich schnell, und es gehört in jede professionelle IT-Umgebung. In dieses Werkzeug solltet ihr investieren.

Aber all diese Werkzeuge beantworten genau eine Frage: Was ist? Sie sagen euch nicht, was sein soll.

Die Grenze der automatischen Discovery

Ein System, das automatisch Assets erkennt und Übersichten generiert, liefert euch ein Abbild der Realität – so, wie sie gerade ist. Das ist operativ unverzichtbar: Es zeigt, ob ein Service läuft, ob eine Komponente neu aufgetaucht ist oder ob etwas unerwartet verschwunden ist. Für Incident Response und Kapazitätsplanung ist das Gold wert.

Was es euch nicht sagen kann: ob dieser Service auf dieser Infrastruktur laufen soll. Ob die hinterlegte verantwortliche Person noch die richtige ist. Ob die Kritikalität der Applikation korrekt eingestuft ist. Ob die Entscheidung, diese App in der Cloud zu betreiben, bewusst getroffen wurde – oder sich einfach so ergeben hat.

Das ist keine technische Lücke, die das nächste Release schließt. Es ist eine konzeptionelle Grenze: Automatisierung beschreibt das IST. Das SOLL ist das Ergebnis menschlicher Entscheidungen.

Das normative EAM-Modell als Gegengewicht

Enterprise Architecture Management stellt in seiner normativen Dimension genau die Fragen, die kein Scanner beantwortet: Wie soll unsere IT-Landschaft aussehen? Welche Applikationen sollen welche Unternehmensfähigkeiten erfüllen? Wo soll eine Applikation betrieben werden – und warum? Wer trägt die Verantwortung?

Diese Fragen lassen sich nicht automatisch beantworten, weil ihre Antworten von menschlichem Urteil abhängen: von Prioritäten, Risikobewertungen, strategischen Entscheidungen und Unternehmenskultur. Eine Discovery-Lösung erkennt, dass eine Applikation auf einem bestimmten Server läuft. Ob das so gewollt ist, muss ein Mensch entscheiden und dokumentieren. Das ist keine Schwäche des normativen Ansatzes – es ist sein Kern.

Zwei Werkzeuge, zwei Fragen – und warum beide nötig sind

Automatisches Asset Management Normatives EAM (z. B. Leitstand)
Kernfrage Was ist gerade vorhanden? Was soll wie betrieben werden?
Datenquelle Automatische Discovery, Monitoring Menschliche Entscheidungen und Dokumentation
Aktualität Echtzeit Gepflegt, wenn sich Entscheidungen ändern
ROI Schnell, operativ messbar Mittel- bis langfristig, strategisch
Typischer Nutzen Incident Response, Kapazitätsplanung Governance, Compliance, Verantwortlichkeit

Beide Ansätze sind keine Konkurrenten – sie ergänzen sich. Das Monitoring sagt euch, was gerade los ist. Das EAM-Modell sagt euch, ob das dem entspricht, was beschlossen wurde.

Warum der SOLL-Teil manuell sein muss

Es klingt zunächst wie ein Nachteil: Der normative Teil eines EAM-Modells lässt sich nicht vollständig automatisieren. Tatsächlich ist genau das richtig – denn die Fragen, die dort gestellt werden, sind echte menschliche Entscheidungen:

  • Wer ist verantwortlich? Keine technische Eigenschaft eines Servers, sondern eine organisatorische Zuweisung.
  • Wie kritisch ist die Applikation? Das hängt vom Geschäftskontext ab, nicht vom CPU-Verbrauch.
  • Auf welcher Infrastruktur soll die App laufen? Eine strategische und manchmal regulatorische Entscheidung.
  • Welche Unternehmensfähigkeiten erfüllt die Applikation? Das erfordert Verständnis des Geschäftsmodells.

Genau dafür ist Leitstand gebaut: ein Werkzeug, das diese menschlichen Entscheidungen strukturiert erfasst, sichtbar macht und aktuell hält – ohne den Aufwand eines Konzern-EAM-Systems. Es ist der Ort, an dem das SOLL dokumentiert wird: bewusst, nachvollziehbar, pflegbar.

Das Zusammenspiel in der Praxis

Reifes IT-Management nutzt beide Werkzeuge komplementär. Das Monitoring zeigt, wenn die Realität vom Plan abweicht – aber nur, wenn der Plan überhaupt irgendwo festgehalten ist. Ohne ein normatives Modell gibt es keinen Maßstab, an dem sich das IST messen ließe.

Automatisches Asset Management ist die Grundlage für operative Kontrolle. Das normative EAM-Modell ist die Grundlage für Steuerung. Und der Unterschied zwischen einem IT-Team, das reagiert, und einem, das steuert, liegt genau hier: im bewusst gepflegten SOLL.

Passend dazu: NIS2 Applikationsliste – was rein muss und das Leitstand-Handbuch.