Eine CMDB beginnt nicht mit Daten, sondern mit Entscheidungen

Bei einem mittelständischen Unternehmen war die CMDB gepflegt. Trotzdem hatte sie kaum Einfluss auf betriebliche Entscheidungen – insbesondere dann nicht, wenn es schnell gehen musste. Die Daten waren vorhanden, aber der Incident- und Change-Ablauf verlangte nicht, sie zu konsultieren. Unter Zeitdruck griff das Team deshalb auf Erfahrungswissen, Rückfragen und Zuruf zurück.

Dieses Muster zeigt das eigentliche CMDB-Problem: Eine Datenbank kann aktuell sein und trotzdem an der Arbeit vorbeilaufen. Ihr Nutzen entsteht nicht dadurch, dass viele Configuration Items erfasst wurden. Er entsteht dann, wenn ein Team mit ihrer Hilfe schneller erkennt, welche Services betroffen sind, welche Folgen ein Change haben kann oder wer eine Entscheidung treffen muss.

Meine Grundregel lautet deshalb: Eine CMDB beginnt nicht mit Daten, sondern mit den Entscheidungen, die sie verbessern soll.

Eine Inventarliste ist nicht automatisch eine CMDB

Eine Inventarliste beantwortet vor allem Fragen wie: Welche Geräte und Anwendungen besitzen wir? Wo befinden sie sich? Welchen Status haben sie? Wer ist zugeordnet? Für kleine und überschaubare IT-Umgebungen kann genau das die angemessene Lösung sein.

Service Configuration Management geht weiter. PeopleCert beschreibt den Zweck der ITIL-Praktik darin, verlässliche Informationen über die Konfiguration von Services, die sie stützenden Configuration Items und deren Beziehungen verfügbar zu machen. Die Beziehung zwischen den Objekten ist damit keine dekorative Ergänzung. Sie liefert den Kontext für betriebliche Entscheidungen.

In diesem Beitrag bezeichne ich als CMDB ein Modell, das ausgewählte Configuration Items und ihre für den Betrieb relevanten Beziehungen abbildet. Es muss weder jedes technische Detail enthalten noch zwingend in einem Produkt mit der Aufschrift „CMDB“ liegen. Entscheidend ist, ob die Informationen verlässlich in Incident, Change, Problem Management, Planung oder Nachweisführung verwendet werden können.

Die Abgrenzung lässt sich praktisch prüfen:

Frage	Inventarliste kann genügen	Beziehungen werden erforderlich
Welche Server und Clients betreiben wir?	ja	nicht zwingend
Welcher Service fällt bei Ausfall dieses Servers aus?	nein	Service- und Abhängigkeitsbezug
Wer ist für eine Anwendung zuständig?	mit Owner-Feld	bei geteilter fachlicher und technischer Verantwortung
Welche Folgen kann ein Change an der Datenbank haben?	nein	Anwendungs-, Service- und Infrastrukturbezug
Welche kritischen Systeme verlieren demnächst Support?	mit Vertrags- und Lifecycle-Daten	bei Abhängigkeiten und gemeinsamer Planung

Wer diese weiterführenden Fragen im Alltag nicht beantworten muss, sollte keine CMDB aus Prestigegründen einführen. Eine ehrliche, gepflegte Inventarliste ist besser als ein komplexes Beziehungsmodell, dem niemand vertraut.

Zuerst den Entscheidungszweck festlegen

Vor der Auswahl von CI-Typen, Attributen oder Discovery-Werkzeugen sollte die IT-Leitung festlegen, welche Entscheidungen besser werden sollen. Für mittelständische IT-Organisationen sehe ich vor allem fünf sinnvolle Ausgangspunkte:

Entscheidungszweck	Dafür benötigte Information
Incident-Impact einschätzen	betroffener IT-Service, Kritikalität, abhängige Anwendungen und zuständige Rollen
Change-Risiko bewerten	technische und fachliche Abhängigkeiten, Umgebung, Servicebezug und Owner
Ursachen eingrenzen	Beziehungen zwischen Service, Anwendung, Datenbank, Identitätsdienst, Netzwerk und Plattform
Lifecycle planen	Status, Produktlebenszyklus, Vertrag, Supportende und verantwortliche Rolle
Kosten und Nachweise vorbereiten	Zuordnung kritischer Systeme zu Services, Verträgen, Lizenzen und Verantwortlichen

Nicht jedes Unternehmen benötigt alle fünf Zwecke gleichzeitig. Ein guter Pilot wählt ein oder zwei Entscheidungen, bei denen fehlender Überblick heute erkennbar Zeit, Risiko oder Geld kostet. Erst daraus folgt, welche Daten wirklich gebraucht werden.

Diese Reihenfolge verhindert eine verbreitete Fehlsteuerung: Das Team sammelt zunächst alles, was technisch erfassbar ist, und sucht anschließend nach einem Nutzen für die entstandene Datenmenge. Richtig herum lautet die Frage: Welche Information fehlt uns bei einer konkreten Entscheidung – und welche Beziehung macht sie sichtbar?

Die wichtigsten Services rückwärts modellieren

Ich empfehle für den Einstieg, nicht sämtliche Infrastruktur von unten nach oben zu erfassen. Beginnen Sie mit den fünf wichtigsten IT-Services und modellieren Sie rückwärts, was für deren Betrieb tatsächlich relevant ist. Die Zahl fünf ist eine pragmatische Startgröße, keine Normvorgabe.

Für jeden ausgewählten Service werden nacheinander diese Fragen beantwortet:

1. Welches Geschäftsergebnis unterstützt der Service?
2. Wer trägt die Service- und Betriebsverantwortung?
3. Welche geschäftskritischen Anwendungen sind erforderlich?
4. Auf welchen Plattformen, Servern, Datenbanken, Identitäts- und Netzwerkdiensten beruhen sie?
5. Welche Verträge, Lizenzen oder Supportzusagen sind für den Betrieb wesentlich?
6. Welche dieser Beziehungen benötigt das Team bei einem Incident oder Change tatsächlich?

Am Beispiel „Warenwirtschaft verfügbar“ führt der Weg vom IT-Service zur ERP-Anwendung, von dort zur Datenbank und zur Plattform, anschließend zu Identitätsdienst, Netzwerk und gegebenenfalls einem externen Supportvertrag. Ein Druckertreiber, der keinen relevanten Einfluss auf diesen Service besitzt, muss nicht nur deshalb zum Configuration Item werden, weil Discovery ihn gefunden hat.

Der pragmatische ITSM-Einstieg für den Mittelstand beginnt ebenfalls beim geschäftlich verständlichen Service. Eine CMDB setzt diese Perspektive fort: Sie zeigt nicht bloß, was die IT besitzt, sondern wovon das Leistungsversprechen abhängt.

Ein schlankes Startmodell für Configuration Items

Das folgende Modell ist meine Empfehlung für einen mittelständischen Einstieg. Es ist kein offiziell vorgeschriebener Mindestumfang von ITIL, ISO oder BSI.

CI-Typen

• Hardware: betriebsrelevante Server, Clients und Netzwerkkomponenten – nicht jeder Adapter und jedes technisch erkennbare Detail,
• Software und Anwendungen: insbesondere ERP, E-Mail, Fachverfahren und andere geschäftskritische Anwendungen,
• IT-Services: die verständlichen Leistungen aus dem Service-Katalog,
• Standort- und Netzbasis: Standorte sowie wichtige Netzsegmente, sofern sie für Auswirkung und Abhängigkeit relevant sind,
• Verträge und Lizenzen: zumindest für kritische Systeme, einschließlich wesentlicher Support-, Wartungs- und Ablaufdaten.

Pflichtattribute

Attribut	Zweck
Eindeutige ID und Name	verwechslungsfreie Zuordnung
Typ oder Kategorie	einheitliche Einordnung und Pflege
Status	beispielsweise geplant, aktiv oder außer Betrieb
Owner	verantwortliche Person oder besser eine belastbare Rolle
Standort und Umgebung	physischer/logischer Ort sowie Produktion oder Test
Kritikalität	abgestufte Einordnung, etwa hoch, mittel oder niedrig

Diese Felder sind nur dann sinnvoll, wenn ihre Bedeutung eindeutig ist. „Owner“ kann fachliche, technische, finanzielle oder Pflegeverantwortung meinen. Das Datenmodell sollte die benötigte Verantwortung deshalb benennen, statt mehrere Erwartungen in einem unklaren Feld zu vermischen.

Zwingende Beziehungen

Für den empfohlenen Einstieg sind fünf Beziehungstypen besonders nützlich:

• läuft auf: Anwendung → Server → gegebenenfalls Virtualisierung oder Storage,
• unterstützt oder ist Teil von: Configuration Item → IT-Service,
• hängt ab von: Service oder Anwendung → Datenbank, Netzwerk, Identitätsdienst oder andere notwendige Infrastruktur,
• wird verantwortet durch: Configuration Item → Person oder Rolle,
• wird vertraglich abgedeckt durch: kritisches Configuration Item → Wartungs- oder Supportvertrag.

Die genaue Richtung und Benennung hängt vom eingesetzten Datenmodell ab. Wichtiger als das Werkzeugvokabular ist eine einheitliche Aussage. Wer bei „hängt ab von“ einmal die technische Abhängigkeit und ein anderes Mal die umgekehrte Auswirkungsrichtung einträgt, erzeugt ein Modell, das im Störungsfall missverständlich wird.

Lieber wenige Configuration Items mit belastbaren Beziehungen als tausende Objekte ohne Service- und Verantwortungsbezug. Für Impact- und Change-Entscheidungen sind die Beziehungen der entscheidende Unterschied zur reinen Bestandsführung.

Pflege muss Teil der Arbeit sein

Eine CMDB veraltet, wenn Pflege als zusätzliche Dokumentationsaufgabe neben dem Betrieb organisiert wird. Aktualisierung muss an die Abläufe gekoppelt sein, in denen sich Configuration Items oder ihre Bedeutung verändern.

Der passende Auslöser ist nicht nur ein technischer Umbau. Pflegebedarf entsteht auch, wenn

• ein Configuration Item neu hinzukommt, geändert oder außer Betrieb genommen wird,
• eine relevante Beziehung entsteht oder entfällt,
• eine verantwortliche Rolle wechselt,
• sich Kritikalität, Umgebung oder Servicezuordnung ändert,
• ein Vertrag oder Supportstatus für den Betrieb relevant wird.

Das BSI ordnet Konfigurationsmanagement ebenfalls über den gesamten Weg von Identifikation und Bestandsführung bis zu Aktualisierung und Außerbetriebnahme ein. Die Umsetzungshinweise verbinden die Pflege unter anderem mit Störungen, Problemen und Änderungen. Auch NIST SP 800-53, Control CM-8, koppelt die Aktualisierung des Systembestands ausdrücklich an Installation, Entfernung und Systemänderungen.

In meinem Rollenmodell verantwortet ein Configuration Manager das Modell, die Qualitätsregeln und den vereinbarten Pflegeprozess. Die jeweiligen CI-Owner verantworten die Inhalte in ihrem Bereich. In einer kleinen IT kann die IT-Leitung die Rolle des Configuration Managers übernehmen. Sie sollte deshalb aber nicht sämtliche Inhalte allein pflegen.

Das ist dieselbe organisatorische Trennung, die auch für andere Betriebsentscheidungen gilt: Eine Rolle kann Regeln setzen, ohne jede einzelne Information selbst zu besitzen. Der Beitrag „Verantwortlichkeiten als Voraussetzung für skalierbaren IT-Betrieb“ zeigt, wie Aufgabe, Ergebnisverantwortung, Entscheidungsrecht und technische Berechtigung auseinandergehalten werden.

Discovery erfasst Fakten, aber keine Bedeutung

Automatische Erkennung ist wertvoll, wenn sich technische Zustände häufig ändern und maschinell eindeutig auslesen lassen. Sie kann den manuellen Aufwand senken und Abweichungen sichtbar machen. Sie erzeugt jedoch noch kein brauchbares Service- und Entscheidungsmodell.

Discovery ist stark bei	Menschen und Prozesse bleiben nötig für
erreichbaren Geräten, IP-Adressen und technischen Komponenten	Zuordnung zu einem geschäftlichen IT-Service
installierter Software, Versionen und Patchständen	Zweck und geschäftliche Kritikalität
Host-, VM-, Instanz- und Containerbeziehungen	fachliche und betriebliche Verantwortung
technisch erkennbaren Netz- und Storage-Zuordnungen	Verträge, Kosten, Supportumfang und Ablaufdaten
häufig veränderlichen technischen Zuständen	sinnvolle Auswahl und Bündelung der relevanten Objekte

Die Trennlinie lautet: Discovery erfasst technische Fakten; Bedeutung wird organisatorisch zugewiesen.

Ein Discovery-Werkzeug kann erkennen, dass eine virtuelle Maschine auf einem bestimmten Host läuft. Es weiß nicht automatisch, ob darauf die geschäftskritische Warenwirtschaft betrieben wird, welche Ausfallwirkung das Unternehmen akzeptiert oder wer über einen riskanten Change entscheiden darf.

NIST sieht automatisierte Mechanismen als mögliche Unterstützung für aktuelle Komponentenbestände. Zugleich lässt NIST die für Nachverfolgung und Rechenschaft notwendige Granularität durch die jeweilige Organisation bestimmen. Genau diese Kombination ist sinnvoll: technische Fakten automatisieren, Umfang und geschäftliche Bedeutung bewusst festlegen.

Die Qualität von Discovery sollte deshalb nicht an der Zahl erkannter Objekte gemessen werden. Für den Betriebsnutzen ist aussagekräftiger, welcher Anteil der relevanten Configuration Items einem Service, einer verantwortlichen Rolle und einem definierten Pflegeprozess zugeordnet ist.

Wann eine Inventarliste die bessere Lösung ist

Eine CMDB ist kein Reifeabzeichen. Für eine kleine IT-Abteilung kann eine gepflegte Inventarliste ausreichen, wenn

• nur wenige geschäftskritische Services und Abhängigkeiten bestehen,
• Änderungen selten und ihre Auswirkungen für das Team überschaubar sind,
• der Inventarzweck vor allem bei Bestand, Lifecycle und Zuständigkeit liegt,
• keine weitergehenden Nachweise oder wiederkehrenden Impact-Analysen benötigt werden,
• und die Informationen auch bei Vertretung verlässlich verfügbar bleiben.

Sobald Störungen, Changes, mehrere Standorte, Dienstleister oder komplexe Plattformen regelmäßig Abhängigkeitsfragen erzeugen, reicht die flache Liste häufig nicht mehr. Dann sollte das Unternehmen nicht sofort alles modellieren, sondern die für diese Entscheidungen fehlenden Beziehungen ergänzen.

Informationssicherheit und Audit-Anforderungen können den Bedarf an nachvollziehbaren Konfigurationsinformationen erhöhen. Daraus folgt jedoch keine pauschale Aussage, jedes nach ISO/IEC 27001 arbeitende Unternehmen müsse ein bestimmtes CMDB-Produkt einführen. ISO/IEC 27001 beschreibt ein risikobasiertes Informationssicherheits-Managementsystem. Umfang und technische Umsetzung müssen aus Kontext, Risiken und den tatsächlich anwendbaren Anforderungen abgeleitet werden.

„Keine ISO-27001-Relevanz“ ist umgekehrt kein ausreichender Grund gegen Beziehungen. Wenn ein Team bei einem Produktionsausfall nicht weiß, welche Services und Fachbereiche betroffen sind, besteht der betriebliche Bedarf unabhängig von einer Zertifizierung.

Der Nutzen zeigt sich am Konsultationsgrad

Vollständigkeit ist zunächst ein Kostenmerkmal. Sie sagt, wie viel erfasst wurde, aber nicht, ob dadurch eine Entscheidung besser geworden ist. Eine schlanke CMDB lohnt sich, wenn das Team sie in den vorgesehenen Situationen tatsächlich konsultiert und die Information hilft.

Mögliche Nutzensignale sind:

• Die betroffenen Services und verantwortlichen Rollen werden bei einem Incident schneller erkannt.
• Die Vorbereitung eines Changes benötigt weniger Rückfragen zu Abhängigkeiten.
• Ungeplante Nebenwirkungen nach Changes gehen zurück.
• Die Zeit zur Eingrenzung von Ursache und Abhängigkeit sinkt.
• Sicherheits-, Lizenz- und Auditnachweise lassen sich mit weniger Suchaufwand vorbereiten.
• Lifecycle- und Vertragsinformationen unterstützen Beschaffung und Budgetplanung.
• Betriebswissen hängt weniger stark von einzelnen Schlüsselpersonen ab.

Bei Kennzahlen ist Zurückhaltung wichtig. Eine sinkende Mean Time to Restore kann mit besseren Konfigurationsinformationen zusammenhängen, aber ebenso mit Alarmierung, Diagnosekompetenz, Ersatzteilen oder externem Support. Aussagekräftiger ist, den Anteil der Wiederherstellungszeit zu betrachten, der für das Ermitteln betroffener Services, Zuständigkeiten und Abhängigkeiten benötigt wurde.

Die einfachste Gegenprobe sollte nach jedem größeren Incident und Change erfolgen:

1. Wurde die CMDB für die vorgesehene Entscheidung konsultiert?
2. Waren die benötigten Informationen vorhanden und vertrauenswürdig?
3. Hat die Nutzung die Entscheidung beschleunigt oder verbessert?
4. Welche Information fehlte – und wird sie künftig wirklich gebraucht?

Wenn die Antwort wiederholt „nein“ lautet, ist nicht automatisch mehr Datenpflege die Lösung. Möglicherweise wurde der falsche Zweck gewählt, das Modell ist zu breit, der Arbeitsablauf umgeht die CMDB oder die relevanten Beziehungen fehlen.

Der richtige nächste Schritt ist klein und überprüfbar

Wählen Sie einen realen Entscheidungszweck, beispielsweise die Impact-Analyse bei Störungen. Modellieren Sie dafür die wichtigsten Services rückwärts bis zu den relevanten Anwendungen und Infrastrukturabhängigkeiten. Ordnen Sie Owner zu und legen Sie fest, welcher betriebliche Vorgang welche Information aktualisiert.

Nutzen Sie dieses Modell anschließend bei echten Incidents und Changes. Erst wenn es dort hilft, erweitern Sie den Umfang. So wächst die CMDB entlang nachgewiesener Entscheidungen statt entlang technisch möglicher Datenfelder.

Eine gute CMDB muss nicht vollständig wirken. Sie muss in dem Moment verlässlich sein, in dem jemand unter Zeitdruck eine folgenreiche Entscheidung trifft.