Was ist eine CMDB?

Eine CMDB ist eine Datei bzw. Datenbank, in der technische Informationen des Informationssystems gespeichert werden, z. B. Listen von Servern, Datenbanken, Anwendungen und Softwarepaketen, aber auch Business-Elemente wie Prozesse oder Verträge. In der Begriffswelt einer CMDB heißen diese Elemente „Configuration Items“ (CI).

Eine gut gepflegte CMDB unterstützt die Planung der IT-Strategie, die Steuerung und das dazugehörige Projektmanagement.

Was bringt mir das konkret?

Bevor wir ins Detail gehen, hier einige typische Use Cases:

Impact-Analyse durchführen: Wenn Updates oder Deployments auf einem Server-Cluster geplant sind, hilft die CMDB dabei, betroffene Anwendungen/Services zu identifizieren und Verantwortliche zu informieren.
Scope für Penetrationstests definieren: Ein Pentest ist relevanter, wenn die exponierten IT-Assets sauber im Scope sind (Pentest/Vulnerability Audit).
Nachweise für Compliance liefern: Eine CMDB liefert dokumentierte Evidenz für Prozesse und Anforderungen (ISO 27001, SOC 2). Das ist nützlich bei internen/externen Audits oder Prüfungen.

Und sonst?

Eine CMDB bringt weitere Vorteile:

Integration mit ITSM: Im Betrieb ist es zentral, Incidents/Changes mit betroffenen IS-Elementen zu verknüpfen. Dafür muss das Service Desk sauber qualifizieren. Daher sind CMDBs oft in ITSM-/Ticketing-Tools integriert.
Überblick über das IS: Detaillierte und vollständige Informationen ermöglichen bessere Entscheidungen: Lifecycle einer Anwendung, Upgrade-Planung, Impact eines Ausfalls, Lizenzinventar – eine CMDB unterstützt effektive Entscheidungen.

Es gibt keine guten oder schlechten CMDBs …

Doch: Eine robuste, operative CMDB folgt mindestens drei Grundprinzipien:

Umfassende Informationen: Eine CMDB ist ein großes Repository mit aktuellen Details zu jedem CI (Status, Historie, Dokumentation, Interaktionen).
Beziehungswissen: Sie speichert nicht nur Objekte, sondern modelliert Beziehungen und Abhängigkeiten – entscheidend, um Auswirkungen von Changes zu verstehen.
Unterstützung anderer ITSM-Prozesse: Eine erfolgreiche CMDB ist kein Inselsystem. Sie liefert Basisdaten für Incident-, Problem- und Change-Management.

Wer ist für den Inhalt verantwortlich?

Die CMDB ist ein zentraler Punkt für IS-Dokumentation. Entsprechend sind mehrere Rollen an Pflege und Qualität beteiligt:

CIO / IT-Leitung: Nutzt die CMDB für Überblick, strategische und operative Entscheidungen sowie Risikomanagement bei Changes.
Operations / Support: Eng angebunden an Incident-, Problem- und Change-Management. Häufig besteht eine Kopplung zwischen Ticketing und CMDB, um betroffene Elemente zu identifizieren.
Architekt: Verantwortlich für Genauigkeit und Aktualität der CMDB. Viele Entscheidungen und Prozesse hängen davon ab.

Klingt zu gut, um wahr zu sein?

Eine CMDB stiftet viel Wert – dennoch haben nicht alle Unternehmen eine. Warum?

Zu wenig Automatisierung: Historisch werden CMDBs manuell befüllt (oft bis heute). Auch wenn Discovery-Funktionen existieren, bleibt der Aufwand für Aufbau und Pflege hoch.
Technische Komplexität: Begriffswelt und Beziehungsmodell sind komplex. Beiträge durch Nicht-Experten sind schwer. Zusätzlich bedeutet Softwarebetrieb (Suite oder Open Source) Wartung und oft externe Beratung.
Mangel an Agilität: CMDB-Dokumentation kollidiert mit Self-Documentation-Mechanismen (Agile, Infrastructure-as-Code). IaC ist bereits eine Form von Dokumentation und kann die CMDB duplizieren.

Continuous Deployment führt zu häufigen Architekturänderungen – die CMDB hat Mühe, Schritt zu halten.

Fehlende Langfrist-Sicht: Configuration Management dokumentiert vor allem den Ist-Zustand. Häufig fehlt eine zeitliche Perspektive, um Roadmaps oder einen Masterplan (SDSI) zu gestalten.

Der Vergleich: CMDB vs …

Es gibt Alternativen – teils aus anderen Perspektiven (Finanzen) oder mit höherer Flughöhe (Enterprise Architecture).

ITAM

IT Asset Management (ITAM) und CMDB werden oft verwechselt, sind aber unterschiedlich. ITAM fokussiert den finanziellen Lifecycle von IT-Assets. Eine CMDB fokussiert Infrastrukturkomponenten und deren Beziehungen – für eine holistische operative Sicht.

Enterprise Architecture (EAM)

Enterprise Asset/Architecture Management (EAM) ist breiter angelegt und umfasst Assets einer gesamten Organisation mit Fokus auf Service Delivery und Lebensdauer. Eine CMDB ist dagegen spezifisch auf ITSM ausgerichtet und bietet detaillierte, interaktive Views auf Infrastruktur und Beziehungen.

Fazit

→ Die Entscheidung für eine CMDB sollte auf einem klaren Verständnis des Nutzens und der Passung zu den Zielen der Organisation beruhen.

→ Trotz Herausforderungen kann eine gut implementierte und gepflegte CMDB ITSM erheblich verbessern, Entscheidungen beschleunigen, Prozesse optimieren und Risiken reduzieren.