Alle Welt spricht von der CMDB (Configuration Management Database) und dass man diese unbedingt haben muss. Aber wozu eigentlich und was ist wirklich in einer CMDB?

In diesem Artikel klären wir die Grundlagen, was eine CMDB eigentlich ist, welche Informationen darin gespeichert sind und was Sie daraus abrufen können bzw. wozu Sie die Informationen brauchen können. Am Ende werden wir Ihnen noch eine kleine Checkliste mitgeben, was Sie beachten sollten, wenn Sie eine CMDB aufbauen wollen.

„Wat is‘ ‚n Dampfmaschin … äh … CMDB?“

„Da stellen wir uns mal janz dumm … „

Zitat Wikipedia: „Eine Configuration Management Database (CMDB) ist eine Datenbank, welche dem Zugriff und der Verwaltung von Configuration Items dient. Als Configuration Item (CI) werden dabei im IT-Management alle Betriebsmittel der IT bezeichnet. Der Begriff Configuration ist dabei etwas irreführend. Darunter versteht man in diesem Zusammenhang den Bestand und die gegenseitigen Abhängigkeiten der verwalteten Objekte.“

Das klingt erstmal recht einfach, denn eine Datenbank ist nichts Neues und dass darin Objekte im weitesten Sinne verwaltet werden können, ist Standard.

Was ist dann an dieser Datenbank so besonders? Im Grunde nichts.

Eine CMDB ist eine Übersicht über alle IT-Betriebsmittel, die in einem Unternehmen vorhanden sind. Also zunächst mal eine Inventarisierung. Sie dient als Grundlage für Auswertungen und Nachverfolgungen.

Quo Vadis?

Weshalb haben dann doch einige Firmen so großen Respekt davor, das Thema CMDB anzugehen, wenn es im ersten Schritt doch nur eine Inventarisierung der Betriebsmittel ist? Warum hängt über dem Aufbau einer CMDB immer das Damoklesschwert eines ewigen Projektes, das nicht zu bewältigen ist?

Die meisten gescheiterten CMDB-Projekte sind nicht der CMDB Software oder dem Können der Mitarbeiter geschuldet, sondern dem Ziel, welchen Nutzen die CMDB bringen soll. Um ein CMDB Projekt gut voran zu bringen, müssen Sie sich im Klaren darüber werden, wozu Sie diese Daten benötigen.

Und das ist die wirklich schwierige Aufgabe!

DAS ZIEL oder wozu brauch ich das?

Eine CMDB benötigen Sie, damit Sie jederzeit nachvollziehen können, was bei Ihnen aktuell im Einsatz ist und wozu es benutzt wird. Auf diese Weise sind Sie immer auskunftsfähig und können auf Grund von aktuellen Daten auch Planungen machen und strategische Entscheidungen treffen. Welche Planungen Sie machen wollen, welche Daten Sie pflegen wollen und welche strategischen Entscheidungen Sie mit diesen Daten treffen wollen, das hängt von Ihnen ab.

Diese Ziele müssen Sie im Vorfeld, BEVOR Sie eine CMDB aufbauen, definieren.

Das Ziel, was Sie mit den Daten machen wollen, steht im Vordergrund. Das Tool, sprich die physische CMDB ist zweitrangig. Aus dem Ziel ergibt sich nahezu von allein, welche Daten Sie zwingend benötigen und welche eher nicht. Es geht also nicht um die Datenhaltung oder Datenerfassung, sondern um den Nutzen, den Sie aus den Daten ziehen wollen oder auch kurz um das „Configuration MANAGEMENT“.

Mit einer aktuellen CMDB sind Sie in der Lage, genau zu sagen, was und wieviel bei Ihnen im Einsatz ist, wozu es benutzt wird, was betroffen ist, wenn was „kaputt“ geht und wen Sie in diesem Fall informieren müssen.

In Vino Veritas

Wir machen mal ein anschauliches Beispiel: Stellen Sie sich vor, Sie sind Winzer und haben hunderte Weinfässer mit verschiedensten Weinen im Keller liegen. In einigen Fässern ist Sauvignon Blanc, in anderen Riesling, oder Chardonnay. Natürlich gibt es verschiedene Anbaugebiete und Jahrgänge. Das ist auf den Fässern vermerkt. Im Keller gibt es eine klare Ordnung, wo welche Fässer, also wo welche Weine, liegen. Auch könnten sie mehrere Weinlager in verschiedenen Orten haben. Sich das alles im Kopf zu merken, kann schwer werden. Deshalb könnten Sie diese Informationen in einer Datenbank verwalten. Das ist im Grunde eine CMDB.

Wenn Sie diese Informationen gut pflegen, können Sie auf Knopfdruck sagen, wo welcher Wein ist und aus welchem Jahrgang er stammt. Mit weiteren Informationen, die Sie in der CMDB speichern können, können Sie auch ermitteln, wie viel Sie noch im Keller haben, welcher Weinhändler wie viel von welchem Wein bekommen hat und in welchem Supermarkt Ihre Weine angeboten werden.

Jedes Fass ist ein CI mit Attributen

Classes, CIs und Attribute

Ist Ihnen klar, was Sie mit den Daten machen wollen, dann können Sie sich an den Aufbau der CMDB wagen.

In einer CMDB werden sog. CIs (IT-Betriebsmittel) verwaltet. Ein CI kann ein einzelner Laptop oder PC sein, es kann aber auch ein Router oder ein Server sein. Auch eine installierte Software kann ein CI sein. Zusätzlich werden die Beziehungen untereinander in der CMDB gespeichert, also z.B. welche Software auf dem Laptop installiert ist.

Alle CIs werden mit Attributen (nähere Beschreibung) eindeutig beschrieben. Als Attribute wären bei Hardware z.B. die Seriennummer, der Herstellername, das Baujahr etc. zu benennen. Bei Software kann die Versionsnummer oder das Build und Patchlevel entscheidend sein.

Jedes CI muss in der CMDB eineindeutig sein, d.h. es bekommt eine ID, die sich niemals ändert.

Alle Fässer werden in der Klasse „Fass“ zusammengefasst

So weit so gut. Aber auch Prozesse können (und sollten) in der CMDB als CI abgelegt werden. Das klingt erstmal etwas merkwürdig, wird aber schnell verständlich, wenn wir uns zum Beispiel einen Fertigungsprozess anschauen. Während der Fertigung werden Assets (Rechner, Server etc.) benötigt. Zu einem Prozess gehören also Assets, was wieder die Beziehung untereinander darstellt. Aus diesen kann nun abgelesen werden, welche Prozesse betroffen sind, falls ein Asset ausfällt.

Bleiben wir mal bei dem Bild mit dem Wein: Wenn Sie wissen wollen, wie viel 2006er Chardonnay aus der Pfalz noch in Ihrem Keller liegt, dann brauchen Sie Informationen darüber, wie viel Wein Sie irgendwann mal hatten und wie viel verkauft wurde. Für diese Information ist es nicht wichtig, wer den Wein gekauft hat oder welcher Händler mit wie viel Wein beliefert wurde.

Wenn Sie aber wissen wollen, wieviel Flaschen vom besagten Wein beispielsweise im Münchener Olympia-Einkaufszentrum noch zur Verfügung stehen, dann brauchen Sie viel mehr Informationen: z.B. darüber, welcher Ihrer Händler das Einkaufszentrum beliefert, wann die letzte Lieferung war und wie viele Flaschen geliefert wurden. Sie sehen schon: je nachdem, welche Auswertungen Sie haben wollen, brauchen Sie andere Attribute und andere CIs in der Datenbank.

Wäre es dann nicht viel einfacher, so viele Attribute wie möglich zu den CIs zu erfassen und auch so viele CIs wie möglich?

Ja, vielleicht. Aber dann könnten Sie sich sehr schnell verzetteln. Sie müssen bedenken, dass Sie jedes Attribut, jedes CI und jede Beziehung pflegen müssen, wenn sich etwas ändert.

Überlegen Sie also gut, für wen oder was Sie Daten erfassen und was diese Person oder die Auswertung mit den Informationen tun muss.

Ein einfacher Prozess in der CMDB

Halten wir fest, jedes Fass wäre in diesem Fall ein CI. Es hätte eine eindeutige Nummer, damit man das Fass jederzeit identifizieren kann. Es hätte Attribute wie z.B. das Material, aus dem das Fass hergestellt wurde (Holz, Kunststoff, Metall…), den Hersteller, das Baujahr etc. Auch die Flaschen wären CIs, die wieder Attribute haben wie z.B. das Fassungsvermögen, die Form (Bocksbeutel, Burgunderflasche etc.).

Zur besseren Übersicht gruppieren Sie nun Ihre CIs noch in Klassen. Hier wäre es im ersten Schritt leicht: Eine Klasse wäre „Fässer“, eine andere „Flaschen“.

Eine Abhängigkeit zwischen diesen wäre nun, welche Flaschen aus welchem Fass abgefüllt worden sind. Sollte es mal zu einer Reklamation kommen, könnten sie so auf einfachem Wege feststellen, aus welchem Fass der ungenießbare Wein kommt.

Aber auch der Wein selbst wäre ein CI. Hier brauchen Sie Attribute wie die Rebsorte, das Anbaugebiet, den Jahrgang, Angaben zur Note etc.

Jede Klasse hat Attribute, wie z.B. beim Fass die Holzart, Kunststoff etc. oder das Fassungsvolumen. Bei den Flaschen kann es sein, dass Sie die Form hinterlegen und natürlich auch das Fassungsvermögen oder die Art des Verschlusses (Schraubverschluss, Korken …)

Veränderung ist das Normale

Auch grundlegende Veränderungen müssen in der CMDB nachverfolgbar sein. So kann ein CI verschiedene Status haben. Zum Beispiel kann das CI in Wartung sein oder es wird aufgerüstet, um einem anderen Zweck zu dienen. In diesem Fall kann das CI sogar die Klasse wechseln. Im obigen Beispiel kann ein Fass z.B. gerade gereinigt werden und steht damit nicht zur Verfügung oder ein leeres Sherry Fass wird jetzt z.B. genutzt, um für die nächsten Jahre Whisky zu beherbergen. Dann wird aus dem Sherryfass ein Whiskyfass.

So können sie jederzeit nachvollziehen, welchen Weg so ein Fass nimmt. Beachten Sie, dass das Fass immer noch dasselbe ist und auch immer noch dieselbe ID hat. Es ändert sich nur der Zweck, statt Sherry nun Whisky. Die ID bleibt immer bestehen, bis das Fass ausgemustert wird und vielleicht als Deko oder Regenfass in einem Garten endet.

Wer darf ändern?

Bei aller Sammelwut und Aktualisierungswahn sollten Sie nie vergessen, wer die Daten in Ihrer CMDB erfassen oder ändern darf. Nichts wäre fataler, als wenn jeder Hinz und Kunz in der CMDB rumwurschtelt. Stellen Sie sich vor, ein Mitarbeiter bekommt den Auftrag, das Sherryfass zu leeren und für die Befüllung mit Whisky vorzubereiten. Wer trägt nun den Status und den neuen Verwendungszweck (Whisky) ein und wann? Der Auftraggeber in dem Moment, wo er den Auftrag vergibt? Der Mitarbeiter, wenn das Fass neu befüllt ist? Beide und „Ober schlägt Unter“? Bei Wein wäre es sicherlich der Zeitpunkt, wenn das Fass wieder mit Whisky befüllt ist.

Um diese Änderungen vorzunehmen, braucht es Verantwortliche, so dass nur verifizierte Informationen in die CMDB einfließen. Diese Aktualisierungen sollten möglichst über definierte Prozesse und, in der IT am aller besten, automatisiert einfließen.

Geschäftsprozesse fordern Übersichtlichkeit.

Die reine Inventarisierung all Ihrer Assets ist aber nur ein Aspekt der CMDB. Viel wichtiger werden seit geraumer Zeit die Geschäftsprozesse, die mit Ihren Assets durchgeführt werden. Schließlich kann es sehr wichtig werden, welche Prozesse betroffen sind, wenn Assets ausfallen. Dann wollen Sie schnellstens wissen, wie Sie das auffangen können, oder wen Sie benachrichtigen müssen.

Verlinkung von CIs

Bei unserem Beispiel wäre ein Geschäftsprozess die Abfüllung des Weins aus den Fässern in Flaschen und dann das Beliefern der Händler. Fällt die Abfüllanlage aus, müssen eventuell die Händler informiert werden, dass die Lieferung später kommt. Hierzu müssen Sie wissen, welcher Wein betroffen ist und welche Händler. Auch wäre zu überlegen, wie Sie diesen Vorfall auffangen können, z.B. mit noch vorhandenen Abfüllungen die Händler beliefern oder in einer anderen Abfüllanlage abfüllen lassen (sofern das möglich ist). Hierzu sind die Informationen zu den Fässern und Flaschen nur noch von untergeordneter Wichtigkeit. Jetzt geht es um das Business.

Je besser nun Ihre CMDB aufgebaut ist, desto leichter können Sie hier agieren und Entscheidungen treffen.

Prozessabbildung in der CMDB

Langsam beginnen

Um solche Prozesse im Detail abbilden zu können, müssen Sie zunächst mit der reinen Inventarisierung beginnen und so nach und die weiteren Abhängigkeiten in der CMDB verankern. Das bedeutet, die CMDB wächst mit Ihrer Erfahrung um mit dem Fortschreiten der Geschäftsprozesse. Würden Sie zu Beginn schon wissen wollen, wo Ihr Wein verbleibt, würden Sie sicherlich nicht ans Ziel kommen, denn dann würden Ihnen die grundliegenden Daten wahrscheinlich fehlen. Aus diesem Grund raten wir Ihnen, beginnen Sie mit kleinen Aufgaben (Inventarisierung mit wenigen Klassen) und tasten Sie sich so nach und nach an größere Prozesse heran.

Checkliste

  1. Definieren Sie Ihre Ziele
    Gehen Sie stets von dem Nutzen der Daten aus, den Sie aus den Daten ziehen wollen. Definieren Sie ganz klar, wozu Sie die Informationen benötigen.
  2. Verantwortlichkeiten
    Vergeben Sie Verantwortlichkeiten und bilden Sie ein Team, dass die CMDB aufbaut und betreut.
  3. Langsam beginnen
    Machen Sie kleine Schritte und fangen Sie mit etwas einfachem an.
  4. Aktuell halten
    Aktualisieren Sie Ihre CMDB kontinuierlich. Je aktueller die CMDB umso besser die Auswertungen und die daraus resultierenden Entscheidungen.
  5. Erweitern
    Erst wenn Sie Erfahrungen gesammelt haben, erweitern Sie die Verwendung der Daten und erweitern Sie damit auch die Funktionalität der CMDB.
  6. Verbesserungen
    Je mehr Sie in der CMDB speichern und je intensiver Sie die Daten nutzen, desto besser wird Ihr Service für Ihre Kundschaft

Noch Fragen?

Wenn Sie noch unsicher sind, wie sie nun anfangen sollen, eine CMDB aufzubauen, rufen Sie uns an. Wir können Ihnen jederzeit mit Rat und Tat zur Seite stehen.