Configuration Management Database Die Datenqualität ist entscheidend

Autor / Redakteur: Hans-Heinz Wisotzky / Gerald Viola

Ein professionelles IT-Service-Management führt zu standardisierten IT-Prozessen und unterstützt die Öffentliche Verwaltung bei den immer öfter anstehenden Umstrukturierungen und Fusionen. Eine wichtige Voraussetzung ist die einheitliche Datenbasis der IT-Komponenten. Die Configuration Management Database (CMDB) hat sich dabei als Herzstück vieler IT-Serviceprozesse etabliert. Doch ohne ein gut geplantes Datenmodell und regelmäßige Audits verpufft die positive Wirkung schnell.

Firmen zum Thema

( Archiv: Vogel Business Media )

Für IT-Service-Management müssen sowohl ein klares Bild der technologischen Realität in der Verwaltung vorliegen als auch eindeutige Prozesse implementiert werden. Für die Prozess-Seite empfiehlt sich die inzwischen etablierte IT Infrastructure Library (ITIL). Dahinter verbirgt sich eine Sammlung von Best Practices für verschiedene Disziplinen des IT-Service-Managements. ITIL hat sich als Standard für die entsprechenden Prozesse etabliert und bildet auch die Basis für die Norm ISO 20000. ITIL enthält Hilfestellungen für alle relevanten Prozesse, zum Beispiel beim Configuration Management oder beim Change Management. Eine aktuelle IT-Service-Management-Umfrage von Materna hat ergeben, dass 98 Prozent der Befragungsteilnehmer ITIL kennen. Derzeit geht der Trend insbesondere in Richtung Configuration Management: So planen 80 Prozent der Befragungsteilnehmer den Einsatz weiterer IT-Service-Management-Prozesse wie etwa Configuration Management.

Configuration Management befasst sich mit dem Soll-Zustand der IT-Infrastruktur und bildet auch in den einschlägigen Frameworks – wie zum Beispiel ITIL – eine wichtige Schnittstelle zu allen anderen IT-Serviceprozessen. Das Kernstück des Configuration Managements ist die Configuration Management Database (CMDB) als zentraler Datenpool für die Abbildung der IT-Infrastruktur. Sie bietet IT-Verantwortlichen eine Dokumentation dessen, was die IT verwaltet. Alle in ITIL beschriebenen IT-Serviceprozesse profitieren von der CMDB. In der CMDB sind die einzelnen „Configuration Items“ (CIs) abgelegt, die in der Behörde sowohl zur Erbringung oder zur Nutzung von IT-Services erforderlich sind, als auch deren Betriebsstatus und die Verknüpfung zu anderen CIs darstellen. CIs sind sämtliche Betriebsmittel und IT-Services wie Hardware, Software und andere Element der IT-Infrastruktur. Daher nimmt die CMDB eine Schlüsselposition ein, da sie im Gegensatz zu Werkzeugen des Asset Managements oder ähnlicher Disziplinen nicht einfach die verfügbaren Komponenten aufzeigt, sondern die Relationen zwischen CIs darstellt. Sie ist ein Repository, das im Idealfall jederzeit den aktuellen Soll-Zustand der IT-Infrastruktur widerspiegeln soll.

Für sich alleine betrachtet bietet eine CMDB aber noch keinen großen Mehrwert. Dieser entfaltet sich erst, wenn man sie als Informationspool für das IT-Service-Management versteht. Erst dadurch erhält die IT beispielsweise die Möglichkeit, anstehende Changes in ihrer Auswirkung vollständig abzuschätzen. Jeder Schritt im Rahmen eines Change Requests kann und sollte eng mit dem Configuration Management und der darunter liegenden CMDB verzahnt sein. Durch die in der CMDB abgebildeten Relationen der CIs können in jeder Change-Projektphase potenzielle Probleme oder Konflikte frühzeitig erkannt werden, lange bevor sie Auswirkungen auf die produktiven Systeme entfalten. Damit besitzt die IT ein probates Mittel, um die Servicequalität auf hohem Niveau zu halten.

Entscheidend für den Nutzen, den die IT-Serviceprozesse aus der CMDB ziehen können, ist die Datenqualität und Aktualität. Hier liegt die größte Herausforderung, weswegen bereits bei der Planung einer CMDB genaue Analysen unabdingbar sind. Denn, welche Detailtiefe die Datenbank besitzen soll und welche IT-Komponenten als CIs aufgenommen werden müssen, ist nicht standardisiert und sehr von der individuellen Situation im IT-Betrieb abhängig. „Viel hilft viel“ ist die falsche Devise; zu viele Informationen in der CMDB machen diese unübersichtlich und schmälern den Nutzwert.

Individuelles Modell

Der erste Schritt zur Einführung einer CMDB muss also sein, die IT-Service- und die Anwenderprozesse genau zu betrachten und auf dieser Basis die wichtigen IT-Komponenten zu identifizieren. Das kann je nach Verwaltung oder Serviceanforderung zu sehr unterschiedlichen Ergebnissen führen: Während zum Beispiel für eine Organisation mit vielen PC-Arbeitsplätzen die Peripherie wie Tastatur, Monitor oder Drucker sehr wichtig ist, kann diese beim Betrieb eines Rechenzentrums eine untergeordnete Rolle spielen.

Anhand der erkannten CIs erfolgt dann die Konzeption der CMDB. Die in der Verwaltung bereits bestehenden Informationen, zum Beispiel in einem

Asset-Management-System oder in anderen Datenquellen, lassen sich als Ausgangspunkt für die CMDB nutzen. Je besser die Datenqualität im Vorfeld ist, desto einfacher kann die CMDB mit den CIs gefüllt werden. Bei der Einführung einer CMDB empfiehlt es sich, wegen dieser hohen Komplexität, schrittweise vorzugehen. Zunächst sollten nur die wichtigsten IT-Serviceprozesse, die in der Analyse herausgearbeitet wurden, auf die CMDB aufsetzen. Stück für Stück können weitere Arbeitsabläufe hinzugefügt werden.

Oft unterschätzt wird die kontinuierliche Überwachung der Informationen in der CMDB. Im laufenden Betrieb benötigt die CMDB einiges an Pflege. Eigenmächtig von den Anwendern installierte Programme, veränderte PCs im Home-Office oder Außendienst-Notebooks sorgen dafür, dass sich die Schere zwischen Soll- und Ist-Zustand der IT immer weiter öffnet. Zudem werden nicht nur neue Elemente in die IT-Infrastruktur eingebracht. Bekannte CIs können ebenso sang- und klanglos wieder verschwinden.

Und nicht nur technologische Bausteine müssen auf ihre Existenz und korrekte Erfassung regelmäßig überprüft werden. Auch Change- und Release-Dokumentationen können sich ändern, etwa wenn ein Change noch im Gange ist. Bereits nach einigen Stunden kann eine CMDB veraltet sein, deswegen muss der Ist-Zustand durch regelmäßige Audits ermittelt und gegen den Soll-Zustand einer CMDB abgeglichen werden.

Für das Audit halten viele Lösungsanbieter geeignete Werkzeuge bereit. Auch wenn diese einige Aufgaben automatisieren können, ist oft manuelle Arbeit gefordert. Meist ist es schwierig zu entscheiden, welche im Feld vorgenommenen Änderungen als CIs in den Soll-Zustand übernommen werden und welche möglichst wieder aus der Welt zu schaffen sind.

Daher sind die Möglichkeiten zur Automatisierung sehr begrenzt und viele Entscheidungen müssen von einem IT-Mitarbeiter gefällt und durchgesetzt werden. Deswegen ist es unbedingt notwendig, dass alle Änderungen als CIs wieder in die CMDB einfließen. Nur so kann sichergestellt werden, dass die CMDB jederzeit den Soll-Zustand wiedergibt. Weicht der Ist-Zustand davon ab, liegt ein unautorisierter Change sehr nahe.

Für den Aufbau einer CMDB stehen prinzipiell zwei Wege zur Verfügung: Man kann aus den bereits vorhandenen Daten eine dedizierte Datenbank aufbauen. Alternativ lassen sich die vorhandenen Daten in einer verteilten Datenbank zusammenfassen. Ob diese „Federated“ CMDB der Königsweg ist, hängt stark von der individuellen Situation ab. Ihr Vorteil ist, dass sie relativ schnell in Betrieb gehen kann.

Fast alle CMDB-Anbieter verfügen über Werkzeuge, um die in der Verwaltung vorhandenen Daten automatisch zu konsolidieren und auf das Datenmodell der CMDB anzupassen. Es ist jedoch wichtig, dass die verschiedenen Datenquellen weiter gepflegt und gewartet werden. Im Gegensatz dazu bedeutet zwar der Aufbau eines neuen Datensilos für die CMDB einen größeren Aufwand bei der Einführung, bietet danach aber einige Vorteile: Die Datenquellen sind konsolidiert, was den Wartungsaufwand – und damit die Betriebskosten – reduzieren kann. Zudem gewinnt die Infrastruktur an Übersichtlichkeit und liefert Informationen für zukunftsweisende Planungen.

(ID:2007303)