Bildquelle: Bildquelle: Pexels / https://www.pexels.com/photo/civil-engineer-looking-at-blueprint-3862628/
CMDB-Daten kippen schnell ins Leere, wenn Discovery, Ownership und Service-Mapping getrennt laufen
Die CMDB hat in vielen IT-Organisationen einen schlechten Ruf, obwohl der Grundgedanke weiterhin richtig ist. Fast jedes Team wünscht sich einen Ort, an dem nicht nur Server, Anwendungen, Datenbanken, Cloud-Ressourcen und Schnittstellen erfasst sind, sondern auch ihre Beziehungen zueinander. Genau dort beginnt der Nutzen für Incident, Change, Risiko und Betrieb. In der Praxis bleibt davon aber oft nur ein technischer Bestand übrig, der zwar viele Objekte enthält, aber zu wenig Orientierung liefert, sobald eine Störung eskaliert oder ein Change wirklich Folgen hat.
Das Problem ist selten, dass eine CMDB grundsätzlich die falsche Idee wäre. Eher laufen drei Dinge organisatorisch nebeneinander her, die zusammengehören: Discovery sammelt technische Daten, Service-Mapping beschreibt Abhängigkeiten im laufenden Betrieb und Ownership plus Governance halten die Daten entscheidungsfähig. Sobald eines davon fehlt oder nur als Nachpflege verstanden wird, wächst die Menge der Einträge schneller als ihr operativer Wert.
Genau deshalb scheitern viele CMDB-Initiativen nicht am Tool, sondern am Betriebsmodell. Eine große Datenmenge ersetzt keine Verantwortung. Und eine automatisch gefüllte Tabelle ersetzt keine Sicht auf Services.
Grundlagen: Eine CMDB, also Configuration Management Database, verwaltet Konfigurationselemente der IT und vor allem deren Beziehungen untereinander. Anders als eine reine Asset-Liste soll sie nicht nur zeigen, was vorhanden ist, sondern auch, wie Komponenten zusammen einen Service tragen. Relevant wird das überall dort, wo Changes bewertet, Ausfälle eingegrenzt, Risiken priorisiert oder Verantwortlichkeiten sauber zugeordnet werden müssen.
Discovery füllt Bestände, aber noch keine Betriebsentscheidung
Automatisierte Discovery ist für eine moderne CMDB unverzichtbar. Ohne sie bleiben hybride Landschaften mit Cloud-Instanzen, virtuellen Maschinen, Containern, Netzwerkkomponenten und SaaS-Anbindungen zu dynamisch, um sie manuell sauber zu pflegen. Genau deshalb setzen viele Plattformen darauf, technische Informationen laufend einzusammeln und zu aktualisieren.
Der Trugschluss beginnt an der Stelle, an der Discovery mit fertiger CMDB gleichgesetzt wird. Discovery erkennt Objekte, Eigenschaften und teils auch technische Beziehungen. Sie entscheidet aber nicht für das Team, welche Konfigurationselemente betriebsrelevant sind, welche Einträge zusammengeführt werden müssen, welche Klassen wirklich gepflegt werden sollen und welche Informationen im Incident oder Change überhaupt belastbar sein müssen. Wer nur sammelt, produziert schnell eine große, aber operativ schwer lesbare Menge aus Dubletten, Altobjekten, generischen Klassen und halbgaren Beziehungen.
Das ist kein Randproblem. Schon TechTarget beschreibt die CMDB nicht nur als Ablage für Hardware und Software, sondern ausdrücklich als Struktur für Konfigurationselemente, Beziehungen, Wichtigkeit und Ownership. Genau darin steckt die operative Wahrheit: Ein automatisch erkannter Server ist noch kein brauchbares Betriebsobjekt, wenn niemand weiß, zu welchem Service er gehört, wer ihn verantwortet und welche Abhängigkeiten im Ernstfall daran hängen.
Discovery sollte deshalb nicht mit dem Versprechen verkauft werden, die CMDB „von selbst“ zu lösen. Sie ist der Datenzulieferer, nicht die Betriebslogik. Erst wenn Teams definieren, welche Klassen führend sind, welche Attribute Pflicht sind und welche Quellen einander ergänzen oder korrigieren dürfen, wird aus automatischer Erkennung ein belastbarer Bestand.
Ownership macht aus Konfigurationselementen verantwortete Objekte
In vielen CMDBs fehlt nicht zuerst Technik, sondern Zuständigkeit. Dann gibt es CIs mit Namen, IP-Adressen oder Cloud-Metadaten, aber keine klare Aussage darüber, wer fachlich oder technisch für ihre Richtigkeit einsteht. Genau dort kippt die CMDB vom Steuerungsinstrument zur Archivlandschaft. Daten werden zwar angezeigt, aber im Zweifel von niemandem verteidigt, korrigiert oder bewusst außer Betrieb genommen.
Ownership bedeutet dabei mehr als ein Support-Team in einem Feld. Für betriebsrelevante Services braucht es mindestens eine klare Kombination aus technischem Verantwortungsanker, Service-Verantwortung und definiertem Review-Rhythmus. Wer prüft, ob eine Datenbankinstanz noch produktiv ist? Wer bestätigt nach einer Migration, dass Beziehungen noch stimmen? Wer entscheidet, ob ein verwaister Eintrag gelöscht, zusammengeführt oder als historisch markiert werden muss? Ohne solche Antworten bleibt Datenqualität Zufall.
Gerade hier unterschätzen viele Organisationen den kulturellen Teil der CMDB. Solange Teams die Datenbank als fremdes Tool des Service Managements wahrnehmen, fühlen sich Plattform, Netzwerk, Workplace, Cloud oder Anwendungsteams nicht wirklich zuständig. Ownership muss deshalb an bestehende Betriebsrealitäten andocken: an Service Owner, Plattformverantwortliche, technische Domänen und vorhandene Change- oder Architekturfreigaben.
Pragmatisch reicht oft schon ein kleiner Regelkern: geschäftskritische Services und ihre tragenden CIs bekommen eindeutige Owner, Pflichtattribute und ein festes Prüfereignis bei Change, Migration, Offboarding oder Architekturumbau. Das ist weniger glamourös als ein neues Discovery-Modul, bringt aber meist schneller belastbare Wirkung.
Service-Mapping trennt Inventar von echter Betriebssicht
Der eigentliche Wert einer CMDB entsteht erst dort, wo technische Einträge zu Service-Zusammenhängen verdichtet werden. Genau das beschreibt auch ServiceNow in einer Community-Einordnung sehr klar: Discovery und Service Mapping befüllen und erweitern die CMDB, Event Management arbeitet anschließend mit diesen Daten, und Governance hält das Ganze tragfähig. Diese Kette ist wichtig, weil sie den häufigsten Denkfehler auflöst: Eine CMDB ist nicht gut, wenn sie viele Objekte hat. Sie ist gut, wenn sie Auswirkungen sichtbar macht.
Ohne Service-Mapping weiß ein Team vielleicht, dass ein Host existiert und auf ihm eine Anwendung läuft. Es weiß aber nicht sicher genug, welche Datenbank dazugehört, welche Identitätsabhängigkeit im Hintergrund mitläuft, welche Schnittstelle zum Drittanbieter führt und welche Geschäftsleistung im Störungsfall tatsächlich betroffen ist. Genau deshalb reichen Bestandslisten für moderne Betriebsentscheidungen nicht mehr aus.
Für Incident-Management ist das unmittelbar relevant. Wenn Monitoring ein Problem meldet, braucht der Betrieb keine bloße Objektliste, sondern eine schnelle Antwort auf die Frage, welcher Service und welche abhängigen Komponenten im Blast Radius liegen. Für Change-Management gilt dasselbe: Das Risiko eines Changes erschließt sich selten aus dem einzelnen Server, sondern aus der Servicekette drum herum. Und auch Problem Management oder Root Cause Analysis werden deutlich präziser, wenn Beziehungen nicht nur technisch vorhanden, sondern servicebezogen modelliert sind.
Service-Mapping muss dabei nicht mit totaler Modellperfektion starten. Oft ist es klüger, zunächst die wichtigsten geschäftskritischen Services sauber durchzudeklinieren: Kernanwendung, Datenbank, Authentifizierung, Netzpfad, Monitoring, Batch oder Middleware, relevante Drittkomponente. Schon diese fokussierte Sicht liefert im Alltag mehr Wert als tausend unverbundene Infrastruktur-Objekte.
Governance ist keine Aufräumaktion vor Audits
Wenn CMDB-Governance nur als spätere Datenbereinigung verstanden wird, kommt sie zu spät. Gute Governance legt schon vorher fest, welche Modellgrenzen gelten, welche Klassen wirklich genutzt werden, welche Attribute verpflichtend sind, wie Dubletten behandelt werden und wann eine neue Objektklasse überhaupt angelegt werden darf. Sie schützt die CMDB damit vor genau dem Effekt, der viele Initiativen entwertet: unkontrolliertes Wachstum ohne gemeinsame Semantik.
Auch die ServiceNow-Diskussion zu Governance-Modellen weist in diese Richtung, wenn sie auf ein CMDB Data Quality Playbook und ein schrittweises Governance-Modell verweist. Der entscheidende Gedanke dahinter ist richtig: Datenqualität entsteht nicht durch gute Absicht, sondern durch Rollen, Regeln, Kontrollen und nachvollziehbare Qualitätsmetriken.
Für den Alltag heißt das zum Beispiel: Welche CIs dürfen ohne Owner nicht produktiv bleiben? Ab welchem Alter gelten Discovery-Funde als ungeprüft? Wie wird mit verwaisten Cloud-Ressourcen umgegangen? Welche Service-Beziehungen müssen bei geschäftskritischen Anwendungen zwingend vorhanden sein? Und wer darf Datenquellen priorisieren, wenn mehrere Systeme unterschiedliche Wahrheiten liefern?
Wichtig ist außerdem, Governance klein genug zu halten, um wirksam zu bleiben. Ein riesiges Board mit seltenen Sitzungen bremst eher. Deutlich hilfreicher ist ein schlanker Steuerungskern mit klaren Qualitätsregeln, festen Eskalationswegen und wenigen Kennzahlen wie Owner-Abdeckung, Dublettenquote, Mapping-Abdeckung kritischer Services oder Alter ungeprüfter CIs.
Wie ein pragmatischer Neustart aussehen kann
Wer eine schwache CMDB nicht komplett neu bauen will, sollte nicht bei der Vollständigkeit beginnen, sondern bei der Entscheidungsrelevanz. Ein guter Startpunkt sind die wichtigsten zehn bis zwanzig Services, bei denen Incidents, Changes oder Provider-Abhängigkeiten regelmäßig operative Folgen haben. Für genau diese Services werden Discovery-Daten, Ownership und Service-Mapping bewusst zusammengezogen.
Praktisch heißt das: erstens die führenden CI-Klassen definieren, zweitens pro Service klare Owner benennen, drittens Pflichtattribute und Qualitätsregeln festlegen, viertens die Kernabhängigkeiten sichtbar modellieren und fünftens CMDB-Daten in Incident- und Change-Abläufe zurückspiegeln. Wenn ein Change-Template oder ein Major Incident die Servicebeziehungen nicht nutzt, bleibt der Nutzen theoretisch. Wenn die Daten dagegen im Alltag abgefragt, bestätigt und bei Abweichungen korrigiert werden, verbessert sich die Qualität fast automatisch.
Genauso wichtig ist ein ehrlicher Schnitt bei unnötiger Modellierung. Nicht jede technische Kleinigkeit muss denselben Reifegrad haben. Die CMDB gewinnt, wenn sie kritische Services und ihre tragenden Beziehungen zuverlässig beschreibt. Sie verliert, wenn sie versucht, ausnahmslos jedes Objekt mit derselben Pflegeintensität zu erfassen und damit am Ende nichts mehr wirklich gut weiß.
Fazit
Eine CMDB scheitert selten an fehlender Technik. Sie scheitert häufiger daran, dass Discovery, Ownership und Service-Mapping organisatorisch getrennt bleiben. Dann entstehen viele Daten, aber zu wenig Betriebssicht. Erst wenn automatisch erkannte Objekte einer verantworteten Service-Logik folgen und Governance die Qualität schützt, wird aus der CMDB wieder das, was sie eigentlich sein soll: ein Werkzeug für bessere Entscheidungen unter Change, Ausfall und Risiko.
Für IT-Leitungen ist das die entscheidende Verschiebung. Nicht die größte Datenmenge gewinnt, sondern die belastbarste Beziehung zwischen Bestand, Verantwortung und Servicewirkung.
