Eine CMDB, die keiner nutzt, ist keine CMDB

Neulich in einem Workshop fragte mich ein IT-Leiter, warum seine CMDB nach zwei Jahren Projektlaufzeit immer noch niemand benutzt. Die Daten seien doch da. Discovery läuft, über 40.000 CIs, alles grün.

Meine Gegenfrage: Wer hat in den letzten vier Wochen eine Entscheidung auf Basis dieser Daten getroffen?

Schweigen.

Diese Szene habe ich in Variationen schon oft erlebt, und sie ist kein Einzelfall, sondern ein Muster. CMDB-Projekte werden als Befüllungsprojekte aufgesetzt. Der Projektplan dreht sich um Discovery-Rollout, CI-Klassen und Datenquellen. Erfolg wird in der Anzahl der CIs gemessen, in Abdeckungsquoten, in grünen Statusberichten. Und am Ende steht ein technisch beeindruckender Datenfriedhof, der gepflegt werden will, aber niemandem fehlt, wenn er veraltet.

Woran man den Datenfriedhof früh erkennt

Es gibt ein paar Warnsignale, die zuverlässig anzeigen, dass ein CMDB-Vorhaben in diese Richtung läuft. Das erste habe ich oben schon genannt: Im Lenkungskreis wird über CI-Zahlen berichtet statt über Anwendungsfälle. Wenn die wichtigste Folie des Monats "82 Prozent Discovery-Abdeckung" zeigt, fragt niemand mehr, wofür die Daten eigentlich gebraucht werden.

Das zweite Signal: Es gibt keine Beschwerden über Datenqualität. Das klingt paradox, ist aber logisch. Wo niemand mit den Daten arbeitet, fällt auch niemandem auf, dass sie falsch sind. Eine gesunde CMDB produziert ständig kleine Beschwerden, weil echte Nutzer an echten Lücken hängen bleiben. Stille ist kein Qualitätsmerkmal, Stille ist ein Alarmsignal.

Und das dritte: Die Pflegeprozesse existieren nur auf dem Papier. Es gibt ein Dokument, das beschreibt, wer welche Attribute aktualisiert. Aber kein Mensch kann sagen, wann das zuletzt passiert ist, und es merkt auch keiner, wenn es nicht passiert.

Der eigentliche Hebel: Fragen statt Daten

Eine CMDB hat genau dann einen Wert, wenn sie Fragen beantwortet, die sich jemand wirklich stellt. Nicht hypothetische Fragen aus dem Architektur-Workshop, sondern Fragen, die im Alltag auftauchen und deren Beantwortung heute mühsam ist. Zum Beispiel:

• Welche Services sind betroffen, wenn dieser Server ausfällt?
• Auf welchen Systemen läuft noch Windows Server 2012, und wem gehören sie?
• Wen muss ich informieren, bevor ich dieses Wartungsfenster plane?
• Welche Systeme hängen an diesem Zertifikat, das nächste Woche abläuft?

Hinter jeder dieser Fragen steht eine Person mit einem Problem: der Incident Manager, der beim Major Incident wertvolle Minuten mit Telefonketten verliert. Der Change Manager, der Freigaben auf Verdacht erteilt, weil niemand die Auswirkungen kennt. Das Security-Team, das bei jeder Schwachstelle erst tagelang recherchiert, welche Systeme betroffen sind.

Wenn du ein CMDB-Vorhaben planst, dreh deshalb die Reihenfolge um. Erst mit genau diesen Leuten sprechen und ihre drei dringendsten Fragen einsammeln. Dann ableiten, welche CI-Klassen, Attribute und Beziehungen nötig sind, um diese Fragen zu beantworten. Und nur diese befüllen und pflegen. Alles andere kommt später oder nie.

Was sich dadurch ändert

Das klingt banal, verändert aber die Dynamik des ganzen Vorhabens. Plötzlich gibt es Abnehmer. Der Incident Manager merkt sofort, wenn die Beziehungen zwischen Servern und Services nicht stimmen, weil seine Impact-Liste beim nächsten Vorfall Lücken hat. Er beschwert sich, und genau diese Beschwerde ist Gold wert: Sie zeigt, dass jemand die Daten braucht, und sie erzeugt Druck, die Lücke zu schließen.

Datenqualität entsteht nicht durch Disziplin, sondern durch Nutzung. Kein Pflegeprozess der Welt hält Daten aktuell, an denen niemand hängt. Umgekehrt halten sich Daten, auf die täglich jemand schaut, fast von allein, weil Fehler auffallen und korrigiert werden.

Dazu gehört auch, den Nutzen sichtbar zu machen. Wenn die ersten Impact-Analysen im Change-Prozess auftauchen und eine Freigabe-Runde dadurch von Raten auf Wissen umstellt, spricht sich das herum. Die nächste Abteilung kommt dann von selbst mit ihren Fragen. So wächst eine CMDB organisch entlang des Bedarfs, statt auf Vorrat in die Breite.

Und die Technik?

Die spielt natürlich eine Rolle, aber eine dienende. Discovery, Service Mapping, Integrationen mit anderen Quellen: alles wichtig, alles lösbar, und zu den typischen Stolpersteinen schreibe ich sicher noch einmal gesondert. Nur die Reihenfolge muss stimmen. Die Technik füllt die Daten ein, die der Anwendungsfall verlangt. Nicht umgekehrt.

Wenn ich heute eine einzige Kennzahl für die Gesundheit einer CMDB wählen müsste, wäre es nicht die Anzahl der CIs und nicht die Abdeckung. Es wäre die Zahl der Abfragen durch echte Menschen und Prozesse pro Woche. An ihr lässt sich ablesen, ob die CMDB ein Werkzeug ist oder ein Denkmal.