ITSM und die CMDB: warum Konfigurationsdaten verrotten

Fast jedes ITSM-Team ist sich einig, dass eine CMDB eine gute Idee ist. Weit weniger haben eine, der sie vertrauen. Die Configuration Management Database ist der Teil von ITSM, der am ehesten stark startet und veraltet, bis die Menschen ihn prüfen, falsch finden und nicht mehr prüfen. Die Gründe sind konsistent, und sie sagen etwas über Service-Management-Architektur im Allgemeinen.

Was eine CMDB tun soll

Eine CMDB erfasst die Dinge in Ihrer IT-Umgebung und ihre Beziehungen. Server, Anwendungen, Services, Geräte und die Abhängigkeiten dazwischen. Gut gemacht, beantwortet sie Fragen, die sonst Ratespiel sind: Wenn dieser Server ausfällt, was bricht? Welchen Service berührt dieser Change?

Eine gute CMDB macht Incident-, Change- und Problem-Management von reaktiv zu informiert, und niemand bestreitet das Ziel.

Warum CMDBs verrotten

Das Problem ist die Pflege, und die Geschichte ist meist dieselbe.

Eine CMDB ist meist eine separate Datenbank in einer separaten ITSM-Plattform. Sie genau zu halten heißt, dass jemand sie aktualisiert, wann immer sich die Umgebung ändert. Aber die Umgebung ändert sich ständig, und die Aktualisierungen hängen davon ab, dass Menschen sich an die Anmeldung in einem System erinnern, in dem sie sonst nicht leben. Manche Changes werden erfasst, viele nicht.

Warum das Vertrauen zusammenbricht

Innerhalb eines Jahres sind CMDB und Realität auseinandergedriftet, und sobald sich ein paar Leute daran verbrennen, veralteten Daten zu vertrauen, bricht das Vertrauen zusammen. Danach ist es eine Datenbank, die niemand aktualisiert, weil niemand ihr vertraut, und der niemand vertraut, weil niemand sie aktualisiert.

Die Grundursache ist Distanz. Die CMDB lebt irgendwo, wo die Menschen nicht arbeiten, also ist ihre Pflege ein zusätzlicher, separater Akt.

Das Datensilo-Problem

Es gibt einen zweiten Preis. Eine klassische CMDB ist ein weiterer Speicher sensibler Betriebsdaten, getrennt von allem anderen gehalten. Das bedeutet mehr abzusichern und zu steuern und mehr mit den Systemen synchron zu halten, die die Wahrheit kennen, etwa Ihr Identity-Provider und Ihr Device-Management. Jede Synchronisation ist ein weiterer Ort, an dem Realität und Aufzeichnung auseinandergehen.

Die klassische CMDB kombiniert also die höchste Pflegelast im ITSM mit den Datensilo-Problemen einer separaten Plattform. Es überrascht nicht, dass sie der Teil ist, der zuerst verrottet.

Eine CMDB, wo die Daten schon liegen

Die Behebung folgt aus der Diagnose. Wenn das Problem Distanz und Duplizierung ist, ist die Antwort, Konfigurationsdaten dort zu halten, wo die Organisation ohnehin arbeitet und wo verwandte Daten ohnehin sitzen.

Läuft ITSM nativ in Microsoft 365, kann die CMDB in SharePoint leben statt in einer separaten Plattform. Das klingt nach einer kleinen Änderung, nimmt aber die Distanz weg. SharePoint liegt in Microsoft 365 unter den eigenen Richtlinien der Organisation, neben Dokumentation und Wissen, und ist über dasselbe Ökosystem mit Microsoft-Identity- und Gerätedaten verbunden.

Konfigurationsdaten hören auf, eine Insel zu sein

Konfigurationsdaten in SharePoint sitzen neben den Systemen, die wissen, wann sich etwas geändert hat, und genau das hält sie aktuell.

Was das im Alltag ändert

Der praktische Unterschied ist, dass die Pflege der CMDB aufhört, eine separate Pflicht zu sein. Aktualisierungen passieren näher dort, wo Changes auftreten, auf Daten, die der Rest der Umgebung sehen kann, unter einem Satz von Governance- und Audit-Kontrollen statt einer fragilen Synchronisation zwischen zwei Welten. Die Fragen, für die eine CMDB existiert, werden wieder beantwortbar, weil man den Daten darunter wieder vertraut.

Eine CMDB zahlt sich nur aus, wenn die Menschen ihr vertrauen, und Vertrauen kommt aus Genauigkeit. Genauigkeit braucht reibungsarme Pflege, und die entsteht, wenn die Daten dort liegen, wo Arbeit ohnehin passiert. Die Teams, deren CMDBs überleben, sind meist jene, die aufgehört haben, Konfigurationsdaten als separate Datenbank zu behandeln, die man besucht, und begonnen haben, sie als Teil der Umgebung zu behandeln, in der sie ohnehin leben. ITSM360 legt diese Daten genau aus diesem Grund in SharePoint.

Das Fazit

CMDBs verrotten, weil sie getrennt von den Systemen und Menschen leben, die sie aktuell halten. Distanz macht die Pflege zu einer zusätzlichen Pflicht, und sobald das Vertrauen in die Daten bricht, aktualisiert sie niemand mehr.

Konfigurationsdaten innerhalb von Microsoft 365, in SharePoint, zu halten, beseitigt diese Distanz. Die Daten sitzen neben Identity, Geräten und Dokumentation, unter derselben Governance, und genau das hält sie über die Zeit vertrauenswürdig. Mit Backend in a Box, auf Anfrage verfügbar, bleiben Ihre Servicedaten in Ihrem eigenen Tenant.