Was bedeutet CMDB?

Eigenschaften einer CMDB

Wir wissen also, wofür eine CMDB da ist, welche Rolle sie beim Konfigurationsmanagement spielt, welchen Bezug sie zum Asset-Management hat und wie sie sich davon unterscheidet. Doch wie sieht die CMDB-Funktion in der Praxis aus?

Die wesentlichen funktionalen Merkmale einer CMDB sind:

Nahtlose Dashboards mit CI-Metriken und Analysen, die es einfach machen, den Zustand von CIs, deren Beziehungen, die Auswirkungen von Änderungen, Muster, die zu Vorfällen oder Problemen führen, sowie den Aufwand (Geld und Ressourcen) für den Aufbau und die Verwaltung jedes Service innerhalb eines Unternehmens zu verfolgen.

Compliance-Funktionen, mit denen du und Prüfer detaillierte Aufzeichnungen und transparente Einblicke nicht nur in den aktuellen Zustand von CIs, sondern auch in deren bisherige Änderungen, Prüfungen, gegenseitige Kontrollen, Vorfälle usw. erhalten.

Erstellung von CIs und die rechtzeitige Aktualisierung ihrer Daten, die über drei verschiedene Methoden unterstützt wird: manuelle Eingabe, Integrationen (API-gesteuert, SCCM) und Erkennungstools, die automatisierte Scans aller IP-Adressen im Netzwerk eines Unternehmens durchführen, um Software- und Hardwareinformationen zu sammeln und den Bestand jedes physischen und virtuellen Geräts im Unternehmen effektiv erfassen.

Unterstützung für föderierte Datensätze, einschließlich Normalisierung und Abstimmung von CIs und deren Daten.

IT-Servicezuordnung (in der Regel eine grafische Darstellung von Beziehungen und Abhängigkeiten).

Zugriffskontrollen, mit denen du bei Bedarf verschiedenen Personen oder Teams unterschiedliche Zugriffsebenen zuteilen und Änderungen bei auftretenden Fragen oder Vorfällen zu ihrem Ursprung zurückverfolgen kannst.

Vorteile einer CMDB

Die Hauptprobleme, die mit einer CMDB angegangen werden, sind isolierte Daten und veraltete Informationen. Vor der Implementierung einer CMDB sind die Daten der meisten Unternehmen in verschiedenen Systemen mit verschiedenen Besitzern verstreut. Das macht es schwierig, einen Überblick über alle CIs und ihre Abhängigkeiten zu erhalten, und noch schwieriger zu verstehen, welche Informationen aktuell sind und welche nicht.

Dadurch wird verhindert, dass Teams bei Entscheidungen wichtigen Kontext einbeziehen können. Und dies wiederum wirkt sich auf die Risikobewertung und Berichterstellung aus, beeinträchtigt die Entscheidungsfindung, verlangsamt die Problemlösung und bedeutet letztendlich finanzielle Verluste und Imageschäden für das Unternehmen.

Nehmen wir einmal an, dass die Daten von CI A in einer Abteilung untergebracht sind und die von CI B in einer anderen. CI B ist von CI A abhängig, damit es richtig funktioniert. Wenn aber die Abteilung von CI A beschließt, die Konfigurationselemente aus Wartungsgründen offline zu nehmen, hat sie keinen Einblick in die Auswirkungen auf CI B.

Im besten Fall kann dies bei mehreren Teams für Verwirrung sorgen. Im schlimmsten Fall kann es zu einem größeren Vorfall kommen. Um dieses Szenario zu vermeiden, ist lediglich eine gut funktionierende CMDB erforderlich.

Forrester identifiziert drei Anwendungsfälle, in denen eine CMDB heutzutage eine wichtige Rolle spielt:

Planung

Technologiemanager benötigen CMDB-Daten, um allgemein auf der Ebene der Unternehmensarchitektur und des Portfoliomanagements als auch detailliert auf der Ebene des Asset- und Kapazitätsmanagements zu planen.

Buchhaltung

Die IT-Finanzabteilung muss auf Aufzeichnungen zu Anwendungen oder Servicecodes zugreifen können, um Abrechnungen zuzuweisen und die Unternehmensfinanzen ordnungsgemäß zu verwalten.

Betrieb

Eine CMDB verbessert eine Reihe von wichtigen ITSM-Praktiken, darunter das Änderungs-, Vorfall- und Problemmanagement.

Beim Änderungsmanagement kann eine CMDB die Risikobewertung verbessern, indem sie voraussieht, welche Benutzer, Systeme und andere CIs betroffen sein könnten. In regulierten Branchen kann sie auch die Einhaltung von Vorschriften unterstützen, Teams bei der Verwaltung von Kontrollen helfen und einen klaren Audit-Trail vorgeben.

Beim Vorfallmanagement kann eine CMDB beim Identifizieren von Änderungen helfen, die zu einem Vorfall geführt haben, und zu einer schnelleren Lösung beitragen. Aufzeichnungen zu Vorfällen lassen sich mit den relevanten CIs verknüpfen. Teams können so Vorfälle im Zeitverlauf zusammen mit den Assets, auf die sie sich auswirken, verfolgen.

Beim Problemmanagement kann eine CMDB bei der Ursachenanalyse helfen und Teams schneller zum Kern eines Problems führen. Sie kann auch ein proaktives Problemmanagement unterstützen und Teams dabei helfen, Assets zu identifizieren, die ein Upgrade benötigen, um Servicekosten zu senken und ungeplante Ausfälle zu reduzieren.

Letztendlich sollte eine CMDB die Komplexität reduzieren, Fehler verhindern, die Sicherheit erhöhen und dafür sorgen, dass ITSM-Praktiken wie das Änderungs- und Vorfallmanagement reibungslos ablaufen.

Die Herausforderungen von CMDBs

Branchenstatistiken zeigen, dass nur 25 % der Unternehmen einen bedeutsamen Nutzen aus ihren CMDB-Investitionen ziehen. Aufgrund dieser derart niedrigen Erfolgsquote hat die Technologie einen ziemlich zweifelhaften Ruf.

Die gute Nachricht ist, dass die Ursachen für das Scheitern vermeidbar sind und sich in der Regel in sechs vorhersehbare Kategorien einteilen lassen:

Unternehmenskultur

In jedem Unternehmen lässt sich anhand der Kultur und dem Engagement der Teams am besten ermitteln, ob neue Technologien und Prozesse erfolgreich sind. In einer aktuellen Studie des Harvard Business Review gaben 93 % der Führungskräfte an, dass die größte Herausforderung bei der datengesteuerten digitalen Transformation Menschen und Prozesse sind. Dasselbe gilt für CMDB-Projekte.

Relevanz

CMDBs werden oft als zentrale Informationsquelle bezeichnet. Das führt manchmal dazu, dass Unternehmen versuchen, alle ihre Daten in eine Datenbank zu zwängen, ohne über die Anwendungsfälle nachzudenken, die für ihre Anforderungen relevant sind.

Wie bei jedem Daten-Repository sollte eine CMDB fokussierte, nützliche Daten enthalten, die interne Prozesse wie das Änderungsmanagement unterstützen. Sorge dafür, dass deine CMDB einen klar definierten Nutzen und einen Besitzer hat. Sie sollte zudem die Möglichkeit bieten, Daten zu aktualisieren, um alle Änderungen abzubilden.

Zentralisierung

Wenn wir eine CMDB als einen zentralen Ort zur Anzeige von Asset-Daten bezeichnen, bedeutet das nicht, dass sich alle Asset-Daten ausschließlich in der CMDB befinden müssen. Dieser verbreitete Irrglaube kann für Teams einen hohen Aufwand verursachen, wenn sie versuchen, alle ihre Daten in diese zentrale Informationsquelle zu verschieben. Die Best Practice besteht darin, aus Daten von anderen Tools einen Verbund zu erstellen, damit zur Bearbeitung jedes Anwendungsfalls das am besten geeignete Tool verwendet wird.

Es ist beispielsweise sinnvoller, Finanzdaten in einem ITFM-Tool (IT Financial Management) und Softwarelizenzinformationen in einem SAM-Tool (Software Asset Management) zu speichern. Die Daten können dann in deine CMDB importiert und gespiegelt werden, auch wenn dies nicht der primäre Speicherplatz ist.

Genauigkeit

Viele Unternehmen haben Schwierigkeiten, eine korrekte CMDB zu erstellen und zu pflegen. Die häufigsten Probleme bestehen darin, dass Erkennungstools zu selten ausgeführt werden, Automatisierungsregeln fehlen oder nicht auf manuelle Eingaben verzichtet werden kann. Eine geeignete Lösung für diese Herausforderungen ist eine ereignisgesteuerte Erkennung, die die traditionelle Bottom-Up-Erkennung ergänzt.

Für alle diejenigen, die mit diesen Begriffen nicht vertraut sind: Bei einer Bottom-Up-Erkennung werden Assets von der Infrastruktur bis hin zu kundenorientierten CIs zugeordnet. Eine ereignisgesteuerte Erkennung findet statt, wenn z. B. ein Ereignis innerhalb eines Systems oder ein Problem eintritt, das zur Kommunikation zwischen den Systemen führt. Basierend auf diesem Ereignis ordnet das System dann die zugehörigen CIs und deren Verbindungen zu.

Übrigens ist nicht jedes CI auffindbar. Vielleicht möchte dein Team ja Monitore in der CMDB zuordnen. Weil Monitore von automatisierten Systemen nicht erkannt werden, müssen sie manuell über eine Kalkulationstabelle (oder eine ähnliche Methode) eingegeben werden.

Um eine hohe Genauigkeit zu erzielen und ein anschauliches Bild von deinen Assets und ihren Verbindungen zu erhalten, musst du das Potenzial der Bottom-Up-Erkennung und der ereignisgesteuerten Erkennung nutzen.

Prozess

In einigen Unternehmen ist man der Auffassung, dass CMDBs zur Modellierung älterer Infrastrukturen und Software dienen und nicht für den neuen Stack an Cloud- und softwaredefinierten Infrastrukturen sowie die darauf gehosteten modernen Workflows geeignet sind.

Tatsächlich sollten wir uns hier nicht mit der Wortbedeutung aufhalten, sondern uns mit dem Nutzen befassen, den die Nachverfolgung unserer CIs (alte wie neue) in einem Tool bringt, das uns einen guten Überblick über unsere technischen Ökosysteme liefert.

Tools

Die Auswahl des richtigen Tools ist enorm wichtig, wenn du die oben genannten traurigen Fehlerstatistiken vermeiden möchtest. Einige CMDB-Tools sind nichts weiter als Asset-Repositorys, also Datenstrukturen, die auf ältere physische Infrastruktur- und Erkennungstools festgelegt sind, die langsam auf Änderungen reagieren. Um erfolgreich mit einer CMDB zu arbeiten, brauchst du eine, die neue Arten von Assets berücksichtigt und sich schnell an Änderungen anpassen kann.

Wähle aus, was in deiner CMDB verwaltet werden soll

Es gibt keine allgemeingültige Vorgehensweise, wie du CIs in deiner CMDB verwalten solltest. In welchem Maß und Umfang die CMDB eingerichtet werden soll, sollte sich nach den Anwendungsfällen und Zielen des jeweiligen Unternehmens richten. Normalerweise ist es sinnvoll, auf oberster Ebene zu beginnen und die Services korrekt einzurichten, und dann bei Bedarf breiter oder tiefer zu gehen, damit du deine Unternehmensziele erreichen kannst.

CIs können im Übrigen grob als technische oder nichttechnische Einheiten gruppiert werden.

Zu den technischen Einheiten gehören Unternehmensservices, technische Services, Anwendungen, Software, Datenbanken, Container, virtuelle Maschinen, Betriebssysteme, Hardware, Netzwerke, Ports usw.

Nichttechnische Einheiten können auch in deiner CMDB modelliert werden, wenn du sie von anderen Assets in deiner IT-Servicezuordnung entweder als abhängig oder als betroffen darstellen möchtest. Zu den nichttechnischen Einheiten können Benutzer, Kunden, Unternehmen, Standorte, Serviceverträge, Dokumente usw. gehören.

Zu guter Letzt sollten bei der Entwicklung eines CMDB-Modells Cloud-Services berücksichtigt werden. Die SaaS-Angebote (z. B. Google Apps, Dropbox, Salesforce usw.) und IaaS-Angebote (z. B. DigitalOcean, Linode, Rackspace, Amazon Web Services usw.) können beide bei Bedarf als CIs dargestellt werden.