Szenen aus dem IT-Alltag: Eine IT-Komponente ist defekt. Sofort beginnt die Suche: Gibt es eine Gewährleistung? Bestehen Wartungsverträge? Muss ein Reparaturauftrag geschrieben werden? Schlimmstenfalls muss für die Reparatur des Geräts eine Rechnung beglichen werden, obwohl der Defekt noch im Garantierahmen liegt - und das nur, weil weder Auftraggeber noch Servicetechniker diesen Umstand kannten. Ein anderes, ebenfalls häufig anzutreffendes Beispiel: Ein Server soll versetzt werden, der IT-Mitarbeiter plant den Umzug auf Basis der ihm lokal vorliegenden Excel-Informationen. In der Praxis stellt sich dann heraus, dass der Rechner nicht an dem Platz steht, wo er erwartet wurde - ein Kollege hat ihn aus einem anderen Anlass bereits umgestellt. Wieder beginnt die Suche, der Ablauf ist gestört, unnötige Kosten entstehen.

Keine lokale Datenpflege

Lange Zeit haben IT-Abteilungen versucht, durch die lokale Pflege von Listen die für sie relevanten Informationen vorzuhalten. Doch dann musste man feststellen, dass sich diese Daten nur schwer bis gar nicht untereinander synchronisieren lassen und häufig veralten. Die Erwartungen waren daher groß, als vor einigen Jahren zwei Themen in den IT-Abteilungen Einzug hielten. Zunächst ging es um das IT-Change-Management, das vielfach im Helpdesk-Bereich angesiedelt wurde, weshalb bis heute sowohl Tools als auch Prozesse dieser Disziplin meist Ticket-basierend arbeiten und ähnlich wie eine E-Mail aufgebaut sind. Das hat zur Folge, dass die dort eingetragenen Daten nicht in der strukturierten Form vorliegen, die nötig wäre, um sie auch in Werkzeugen zur IT-Automation zu verwenden.

Ort für Servicebeschreibung

Einige Zeit später kam das Business-Service-Management (BSM) zur Visualisierung und Überwachung von Geschäftsprozessen auf. Die Serviceausrichtung sollte dazu führen, dass IT-Assets diesen Abläufen zugeordnet werden, um etwa beurteilen zu können, welche der IT-Komponenten im Unternehmen geschäftskritisch sind. Auf diesem Weg, so das Versprechen der Hersteller, sei eine exaktere Risikokalkulation und eine bessere Steuerung der IT-Investitionen möglich.

Doch eine Frage haben alle Anbieter lange Zeit nicht befriedigend beantwortet: Wo soll die Beschreibung der Services überhaupt stattfinden? Es wurde deutlich, dass ein im BSM-Werkzeug dokumentierter Service sehr viel Arbeit verursacht, wenn über einen davon losgelösten Change-Prozess Veränderungen stattfinden, die später manuell in den Service eingepflegt werden müssen.

Die Antwort auf das Problem kam mit der IT Infrastructure Library (Itil), deren Spezifikationen sich auf Kernprozesse wie Configuration- und Change-Management konzentrieren. Itil fordert ein zentrales Repository in Form einer Datenbank, in der alle IT-Komponenten und deren Zusammenhänge beziehungsweise Abhängigkeiten beschrieben sind, so dass sich daraus die-jenigen Daten extrahieren lassen, die man zum Beispiel für eine Servicemodellierung benötigt. Herzstück soll die Configuration Management Database sein. Unterstrichen wird diese Position durch Analysen von Forrester Research, die für die BSM-Einführung bis zum Jahr 2010 der CMDB eine zentrale Rolle zuordnen. Das Repository führe dazu, dass die Gestaltung von IT-Services, die im Jahr 2005 noch überwiegend "chaotisch" erfolgte, nach und nach die Zustände "reaktiv", "stabil", "proaktiv" bis schließlich "vorausschauend" (predictive) durchlaufen werde.

Dieser Zeitrahmen ist weniger dem Umstand geschuldet, dass Anwenderunternehmen sich nur zögerlich mit der Technik beschäftigen. Vielmehr mangelt es noch an der Reife der angebotenen Produkte. Die großen System-Management-Spezialisten wie BMC, Computer Associates, Hewlett-Packard und IBM haben zwar alle eine CMDB im Portfolio, doch diese Lösungen sind derzeit noch überwiegend technikorientiert. Das kommt nicht von ungefähr, handelt es sich doch um klassische Monitoring-Lieferanten, deren Scanner eine IT-Infrastruktur überwachen und die CMDB mit den ermittelten technischen Informationen füttern. Will man jedoch den Planungsprozess eines IT-Service sowie dessen Lebenszyklus (Changes) im Griff haben, sind weit mehr Informationen in der CMDB zu hinterlegen. Neben den technischen Daten eines PC oder Servers, deren Software und Netzanbindung gehören dazu auch die Angaben zum Standort, zu den Benutzern und Vertragsdaten wie Lizenzen, Garantien, Service-Level-Agreements oder Wartungsabkommen. Derartige Informationen lassen sich bislang nicht ohne weiteres automatisiert in die CMDB einlesen.

Ein von Anwendern oft eingeschlagener Weg ist deshalb, für die Initialisierung einer CMDB ein bereits verfügbares Repository für IT-Asset-Management (ITAM) heranzuziehen. Davon raten Experten wie Gartner ab. Der Fokus solcher Lösungen liege auf dem Lizenz-, Finanz- und Vertrags-Management von IT-Assets, was eine andere Bestandspflege und Bestandsdauer zur Folge habe, als sie für eine CMDB nötig wäre. Ein typisches Problem sei zum Beispiel, dass eine im Unternehmen eingesetzte Komponente nicht mehr im ITAM-Repository auftaucht, weil sie bereits buchhalterisch abgeschrieben ist.

Es besteht also noch reichlich Aufklärungsbedarf darüber, was eine CMDB leisten soll, welche Architekturansätze es gibt und wie sich derzeit der Markt darstellt. Eine Gelegenheit dazu bot kürzlich das Aachener Beratungshaus Comconsult Kommunikationstechnik GmbH im Rahmen eines "CMDB Infotags". Demnach sollte eine CMDB fünf Kernfunktionen beherrschen:

• Als "Federation" wird die Fähigkeit bezeichnet, Daten aus beliebig vielen Quellen einzusammeln. Schnittstellen zu Fremdsystemen sorgen dafür, dass die Scanner zum Beispiel Vertragsdaten aus SAP-Applikationen oder Netzdaten aus Cisco Works lesen können.

  CMDB-Infotag

  Das Interesse an dem Ende vergangenen Jahres von Comconsult abgehaltenen CMDB-Infotag hat die Berater veranlasst, diese kostenlose Veranstaltung zu wiederholen. Das nächste Treffen am 17. März 2008 findet erneut in Aachen statt. Auf der Agenda stehen der Aufbau und die Funktionen einer CMDB sowie ein Marktüberblick mit einer detaillierten Darstellung der hier genannten Produkte. Anmeldungen werden unter der Mail-Adresse solutions@comconsult.de angenommen.

• Die Funktion "Reconciliation" kommt dann zum Einsatz, wenn eine IT-Komponente in mehreren Quellen auftaucht, dort aber jeweils mit unterschiedlichen technischen Angaben dokumentiert ist. Hier gilt es, die genauere Information regelgestützt zu ermitteln.

• Unter "Mapping" versteht man das Abbilden eines gesammelten Ist-Datenbestands auf einen Soll-Datenbestand mit Hilfe von Validierungsregeln.

• Bei der mit dem Mapping eng verknüpften "Visualisierung" spielt eine wesentliche Rolle, wie sich komplexe Zusammenhänge überhaupt darstellen lassen. Weit reichende Abhängigkeiten einer IT-Komponente können schnell zu einem mehrdimensionalen Beziehungsnetz führen.

• Schließlich geht es noch um die "Synchronisation" neuer Datenbestände mit den diversen Quellen.

Gefragt ist Prozessansatz

Solche Funktionen sind nötig, so Ralf Horstmann, Senior Berater bei Comconsult, wenn es um mehr als einen "dummen" Pool für eingelesene technische Informationen geht. Eine CMDB sollte darüber hinaus als Instrument für Planungs-, Analyse- und Pflegeprozesse fungieren, um weitere Mehrwerte zu schaffen. Einfaches Beispiel dafür ist der Umzug eines Mitarbeiters in ein anderes Büro. Allein mit Scanner-Verfahren hat man zwar die Angaben zur Desktop-Ausstattung des Kollegen, nicht aber zum Standort des PC und den Infrastrukturvoraussetzungen der neuen Lokation. Verfügt man innerhalb der CMDB auch über solche nichttechnischen Informationen, lässt sich dort der komplette Umzug planen. Wie unangenehm sich Informationsdefizite auswirken können, weiß Horstmann von einem anderen Beispiel zu berichten, als ein Unternehmen sein abgeschriebenes Host-System inklusive Speicherplattenturm weiterverkaufte, nicht beachtend, dass Teile der Anlage noch in einem Leasingvertrag standen und dann teuer nachgekauft werden mussten.

Die heute verfügbaren CMDB-Produkte erfüllen solche Anforderungen an eine Prozessorientierung nicht oder nur eingeschränkt. Comconsult spricht von vier Architekturausrichtungen, in die sich die Lösungen einstufen lassen (siehe Kasten "Hersteller und ihre CMDB-Strategien"). Der einfachste ist dabei der "vir-tuelle" CMDB-Ansatz. Hier macht man sich zunächst keine Gedanken, wie ein Pflegeprozess aussehen soll, sondern konsumiert die Daten, die in anderen Werkzeugen anfallen. Der Fokus liegt also auf einer möglichst schnellen und flexiblen Integration der Quellen. Die CMDB-Engine ist in der Lage, aufgrund von definierten Merkmalen ein Mapping über die verschiedenen Datenquellen zu fahren, um Verknüpfungen zu erstellen. Eine zentrale Datenhaltung ist dabei nicht erforderlich, die Zusammenführung kann bei Bedarf online erfolgen. Anders ausgedrückt: Da die Datenhaltung im jeweiligen Quellsystem stattfindet, fungiert die CMDB eher als eine Art Link-Sammlung, deshalb die Bezeichnung "virtuell".

Architekturkonzepte

Fortschrittlicher ist der "föderier-te" CMDB-Ansatz, der mit einem zentralen Speicher arbeitet. Hier findet die Datenhaltung sowohl im jeweiligen Quellsystem als auch in der "Federated CMDB" statt. Es gibt eine gewisse Datennormierung und -standardisierung, aber noch keine spezifischen Pflegeprozesse innerhalb der CMDB. Im Unterschied zur virtuellen Architektur werden über Exportmechanismen die Daten aus den diversen Quellen bezogen und in der CMDB gesammelt.

Der "zentralisierte" CMDB-Ansatz umfasst die Datenhaltung im jeweiligen Quellsystem sowie in mehreren Schichten einer CMDB. Man kann Daten einlesen und mit dem zentralen Datenbestand abgleichen. Hinzu kommt, dass es im Rahmen von Pflegeprozessen möglich ist, eine ausgeprägte Standardisierung der Informationen vorzunehmen sowie diese mit Zusatzangaben etwa aus dem nichttechnischen Bereich zu vervollständigen.

Der als "advanced" bezeichnete CMDB-Ansatz bedeutet schließlich, dass zusätzlich zu den Pflegeprozessen alle Daten regelgestützt untersucht sowie fehlerhafte Datenbestände erkannt und korrigiert werden. Auf diesem so konsolidierten Data Repository arbeiten dann Applikationen wie ein Change-Management oder eine Vertrags- und Lizenzverwaltung.