Warum CMDB-Projekte am Tool-Fokus scheitern

Die Configuration Management Database (CMDB) gehört seit den frühen ITIL-Versionen zum methodischen Fundament des IT-Service-Managements. Auf dem Papier klingt ihre Aufgabe überschaubar: Eine CMDB hält fest, welche Configuration Items existieren und wie sie miteinander zusammenhängen.

Im Alltag wird genau das schnell anspruchsvoll. IT-Landschaften durchlaufen kontinuierliche Veränderungen. Anwendungen werden erweitert, Plattformen ersetzt, Cloud-Ressourcen bereitgestellt und Services neu geschnitten. Gleichzeitig liegen relevante Informationen selten an einer Stelle und verteilen sich auf andere Tools und Systeme.

Demzufolge sind die benötigten Informationen zwar vorhanden, aber nicht verlässlich genug für Entscheidungen im Arbeitsalltag. Gerade bei Änderungen fehlt dann eine belastbare Übersicht darüber, welche Services oder Komponenten betroffen sein können.

Vor der Auswahl einer Lösung sollte deshalb geklärt sein, welchen Zweck die CMDB erfüllen soll. Erst wenn feststeht, ob sie Change Impact Assessments, ITOM, Security, Procurement oder andere Prozesse unterstützen soll, lässt sich entscheiden, wie sie aufgebaut und betrieben werden sollte. Dieser Beitrag bildet den Auftakt einer geplanten Blogreihe zu CMDB-Best Practices. Zunächst steht die Frage im Mittelpunkt, warum der konkrete Zweck einer CMDB vor der Tool-Auswahl geklärt werden sollte.

Unsere Erfahrung aus CMDB-Projekten zeigt, dass viele Vorhaben zu früh als reine Tool-Frage behandelt werden. Eine CMDB wird erst dann tragfähig, wenn ihr Zweck im Arbeitsalltag klar ist. Daraus ergeben sich fünf Grundsätze.

Aus unserer Projektpraxis kennen wir diese Situation nur zu gut. Sobald ein CMDB-Vorhaben startet, lautet die erste Frage häufig, welches Tool eingesetzt werden sollte. Reicht eine Open-Source-Lösung aus? Braucht es eine große Enterprise-Plattform? Oder ist die bestehende Office-Datei vielleicht doch ausreichend?

Diese Fragen sind zwar nachvollziehbar, lenken aber am Anfang von dem Wesentlichen ab. Bevor über eine Lösung gesprochen wird, muss klar sein, was mit der CMDB erreicht werden soll.

Typische Ziele können sein:

Je nach Ziel verändert sich der Aufbau der CMDB. Eine CMDB für Change Impact Assessments benötigt andere Beziehungen zwischen Configuration Items als eine CMDB, die vor allem Asset-Informationen nutzbar machen soll. Deshalb sollten die Ziele dokumentiert oder visualisiert werden, bevor Tool, Datenmodell und Schnittstellen festgelegt werden.

CMDB-Projekte starten in der Regel nicht bei null, da bereits relevante Informationen in anderen Systemen vorhanden sind. Dazu zählen ITSM-Tools, Monitoring-Systeme, das Asset-Management, Einkaufsdaten, Security-Systeme, Cloud-Plattformen und manuell gepflegte Listen.

Dementsprechend müssen vorhandene Informationen so aufbereitet werden, dass sie für die CMDB und die damit verbundenen Prozesse nutzbar sind.

Kernkonzepte hierbei sind Federation, Population und Schnittstellen. Bei der Population werden Daten aus anderen Systemen in die CMDB übernommen. Bei der Federation hingegen bleiben die Informationen in ihren Ursprungssystemen, können aber im CMDB-Kontext genutzt werden. Schnittstellen verbinden die relevanten Systeme und verhindern, dass Informationen isoliert bleiben. Diese Konzepte sollten bereits in einer frühen Phase betrachtet werden, bevor der Aufbau und die Tool-Auswahl konkretisiert werden. Andernfalls entsteht schnell eine CMDB, die Daten doppelt speichert oder wichtige Quellen nicht sauber einbindet.

Erst nach der Klärung von Bedarf und Datenquellen lässt sich die Frage nach dem geeigneten Tool deutlich besser beantworten. Es gibt nicht den einen richtigen Weg. Am Ende zählt, welche Lösung die zuvor definierten Ziele am besten unterstützt.

Grundsätzlich ist keine dieser Optionen richtig oder falsch. Je nach Situation kann eine eigene Lösung, eine bestehende Plattform, ein Managed Service oder ein einfaches Office-Tool die richtige Wahl sein. Die Erfüllung der Ziele aus den vorherigen Schritten ist ausschlaggebend für die Entscheidung. Die Tool-Auswahl sollte deshalb nicht nach dem Funktionsumfang, sondern nach der Passung getroffen werden. Alles, was nicht zur Zielerreichung beiträgt, erzeugt schnell Aufwand, bringt aber keinen klaren Nutzen.

Eine CMDB kann keine organisatorischen Unklarheiten lösen. Wenn nicht klar ist, wer welche Informationen pflegt und wofür sie genutzt werden, verliert sie schnell an Akzeptanz.

Deshalb müssen die beteiligten Bereiche verstehen, welche Rolle die CMDB in den jeweiligen Prozessen spielt. Change Manager benötigen andere Informationen als Asset Manager oder Security-Verantwortliche. Jede Rolle muss wissen, welchen Beitrag sie zur Datenqualität leistet.

Schulungen sind dafür wichtig, reichen aber nicht aus. Die Aufgaben müssen im Prozess verankert sein. Wer Configuration Items anlegt, Beziehungen prüft oder veraltete Daten korrigiert, muss klar geregelt sein.

CMDBs dürfen nicht zu einer zusätzlichen Pflegepflicht werden, deren Nutzen im Alltag unklar bleibt. Sie muss so betrieben werden, dass die enthaltenen Informationen für die definierten Ziele verlässlich genug sind.

Die Einführung einer Configuration Management Database schließt das Projekt nicht ab. Anforderungen ändern sich und die CMDB muss darauf reagieren können.

Dabei darf sie ihren Kern nicht aus den Augen verlieren: Die Configuration Items und ihre Beziehungen müssen nachvollziehbar bleiben. Alles Weitere sollte dem definierten Zweck dienen.

Wird die CMDB zu komplex, sinkt ihre Nutzbarkeit. Bleibt sie zu oberflächlich, hilft sie im Arbeitsalltag kaum weiter. Entscheidend ist, dass sie anpassbar bleibt, ohne ihren praktischen Nutzen zu verlieren.

Eine CMDB schafft Wert, wenn sie nicht als reines Tool-Projekt verstanden wird. Sie muss konkrete operative Entscheidungen im Tagesgeschäft unterstützen und dafür verlässliche Informationen bereitstellen.

Der wichtigste Schritt liegt deshalb vor der Tool-Auswahl. Zunächst muss klar sein, welchen Zweck die CMDB erfüllen soll. Anschließend lassen sich Aufbau und Betrieb sinnvoll bestimmen.

Eine gute CMDB macht Zusammenhänge nutzbar und sammelt nicht einfach nur Daten.

Ein geplanter Folgebeitrag wird sich mit Automatic Discovery beschäftigen. Im Mittelpunkt steht dabei die Frage, wann aus gefundenen Daten belastbare CMDB-Daten werden.