0
News
Neues aus IT-Management und Weiterbildung

ITIL CMDB Modellierung und Konzeption

Was befndet sich in einer CMDB?

Die CMDB ist nach dem Framework ITIL (IT Infrastructure Library) ein Repository oder eine Datenbank, die CIs (Configuration Items) und deren Relationen oder Beziehungen zueinander speichert und deren Informationen über den gesamten Lebenszyklus verwaltet.

Was ist oder kann ein CI (Konfigurationselement) sein? Die CIs definieren sich aus allen Service Assets oder Komponenten, die notwendigerweise gesteuert, verwaltet und kontrolliert werden müssen um einen IT Service bereitzustellen.

Es ist nicht pauschal festzulegen welche CIs zwingend in die CMDB mit aufgenommen werden müssen und welche nicht. Es muss für das Unterehmen per Richtlinie festgelegt werden, wie der Umfang und der Detaillierungsgrad der CMDB respektive der CIs sein soll.

Hier einige Beispiele für CIs (Liste ist nicht erschöpfend !):

  • IT-Service
  • Dokumente (SLA, OLA, Betriebshandbücher, IT Verträge, Lizenzen)
  • Prozesse
  • Rollen und Personen (Kunden, Anwender, Directory Service Accounts) 
  • Hardware und Software mit jeweiligen Installationsinstanzen
  • Umgebung (Raum, Gebäude, etc.)

Dazu gibt es noch die versionierte und revisionsgesicherte Detailansicht eines jeden CIs, dass durch den CI-Record representiert wird. Inhalt des CI-Record ist mindestens die Eindeutige ID und der Status, aber beliebig viele Detail-Informationen lassen sich im CI-Record unterbringen.

Welche Umfang und welcher Detaillierungsgrad für Ihre Anforderungen optimal sind erfahren Sie in unserem Workshop zur CMDB-Modellierung.

Was ist Sinn und Zweck – Mehrwert einer CMDB?

Der Mehrwert der CMDB wird durch die Relationen zwischen den CIs erzeugt. Welches CI mit welchen CI zusammenspielt, also eine Abhängigkeit hat, ist für die Planung von Veränderungen eine unabdingbare Voraussetzung. Auch das Bewerten von Incidents, Problems, etc kann mit Hilfe der Relation zwischen CIs optimiert ablaufen.

Generell sollte jedes Objekt der IT Service Management Prozesse eine Relation zu einem CI haben. Jeder Incident muss sich auf ein CI beziehen und so dokumentiert sein. Das Gleiche gilt selbstverständlich auch für Changes, Releases, Deployments, Known Erros und alle weiteren Prozess-Objekte.

Die CMDB dient hier folgendem Zweck:

  • Dokumentation aller Service-Assets die an der Serviceerbringung beteiligt sind.
  • Vorlage für Planung von Changes, Releases, Deployments (Rollouts) und des Service Design mit all seinen Prozessen
  • Nachvollziehbarkeit von Changes (Veränderungen) im Rahmen der IT Service Erbringung.
  • Bewertung von Auswirkungen bei Incidents, Problems.

Verwaltung und Organisation über den Lebenszyklus – aber wie?

Man kann über den Inhalt der CMDB rege Diskutieren, aber dass es eine CMDB im Rahmen des IT Service Managements geben muss ist Unbestritten. Dies macht das Projekt CMDB aber nicht leichter realisierbar.

Sehr häufig wird eine zu komplexer und von den Betroffenen nicht akzeptierbarer Ansatz für die CMDB gewählt! Die CMDB Konzeption und Modellierung sollte so einfach und sinnvoll wie möglich starten. Die beginnt mit der Identifizierung und Inventarisierung der einzelnen Datentöpfe, die alle notwendigen Informationen schon enthalten um daraus später eine oder mehrere CMDBs zu definieren. Es reicht erst mal aus diese einzelnen Datentöpfe (z. B. Datenblätter, System Management Datenbanken, WIKIs, Dokumente, Datenbanken, Netzpläne, etc) miteinander über ein zentrales Dokument in Beziehung zu setzen – auch für die normativen Anforderungen im Rahmen einer ISO/IEC 20000 Zertifizierung ausreichend.

Viele Organisationen setzen auf Technologien mit deren die Datentöpfe automatisch befüllt und gepflegt werden. Hier zum Einsatz kommen Discovery Tools, Inventory oder Audit Tools die bei dem Abgleich der Datentöpfe (der späteren CMDBs) mit der Realität helfen.

Durch diesen Abgleich ist es möglich unautorisierte oder nicht durch den Change Management Prozess verwaltete Veränderungen zu identifizieren um entsprechende Gegenmaßnahmen einzuleiten.

Dies setzt die folgende Richtlinie voraus:

„Alle Inhalte (CIs und Relationen) der CMDB unterstehen dem Schutz des Change Management Prozess und dürfen nicht ohne vorherige Prüfung und Autorisierung endgültig manipuliert werden.“

Eine oder mehrere CMDBs – CMS?

In der Vergangenheit hatte man immer nur von einer CMDB gesprochen, aktuell verfolgt man den Ansatz der föderierten CMDBs (federated CMDBs) die in einem CMS (Configuration Management System) gemeinschaftlich verwaltet werden. Jede föderierte CMDB ist für sich eigenständig und kann ein eigenes unabhängiges Datenmodell besitzen und wird über Schnittstellen oder Mappings zwischen den föderierten CMDBs referenziert.

Eine CMDB oder die föderierten CMDBs in einem CMS dürfen nie isoliert betrachtet werden, da durch die Verfügbarkeit der in der CMDB gespeicherten Informationen und deren Synergie mit den Prozessen der tatsächliche Mehrwert der CMDB entsteht.


Dies ist ein Auszug aus dem Inhalt des Workshop „ITIL CMDB Modellierung“

09.08.2012

+49 89 - 44 44 31 88 0