Keine CMDB ohne Business Case

Innerhalb der heute meist vorherrschenden IT-Silos wie Netzwerk, Server, Host oder Clients gibt es eine Vielzahl von Datenbeständen. Will man diese vernetzen, Abhängigkeiten aufzeigen und in Richtung Business-Sicht gehen, führt kein Weg an der Nutzung einer CMDB vorbei. Das Referenzwerk ITIL (IT Infrastructure Library) hat die CMDB als Querschnittswerkzeug bereits seit vielen Jahren im Gepäck. Dennoch tun sich viele Unternehmen bis heute schwer, autonome Strukturen zugunsten von interdisziplinärem IT-Wissen aufzubrechen.
Organisation und Technik einfangen
Die Herausforderungen bei der CMDB-Einführung sind gleichermaßen organisatorischer wie technischer Natur. Mit der Einführung einer CMDB entsteht in einem vorher nicht gekannten Ausmaß der Zwang zum Konsens, zum Aushandeln gemeinsamer Ziele und zu Abmachungen zwischen den Abteilungen. Hinzu kommen technische Hürden wie etwa die automatisierte Erkennung von Abhängigkeiten.
In der Praxis hat es sich als nützlich erwiesen, eine CMDB aus einer Keimzelle heraus wachsen zu lassen. Diese Keimzelle kann etwa ein IT-Standort oder ein Technikbereich wie Server oder Netzwerk sein. Ein anderer erprobter Ansatz ist das Entstehen mehrerer solcher Keimzellen, die man dann über eine Metaebene zur „Federated CMDB“ zusammenführt. Der Sinn leuchtet ein: CMDB-Projekte sind sehr komplex und in der Regel langwierig – ein Unternehmen mit einfachen IT-Strukturen kommt gar nicht erst in die Verlegenheit, sich mit Configuration-Management auseinandersetzen zu müssen. Stellt man sich aber dieser vielschichtigen Herausforderung mit dem Anspruch, alle Bereiche simultan einzubeziehen, vergeht oft soviel Zeit, bis erste Erfolge sichtbar sind, dass das Projekt an Fahrt verliert und einschläft.
Dies lässt erkennen, wie sorgfältig die Einführung einer CMDB zu planen ist. Am Beginn steht daher die Frage: Wem nutzt die per CMDB bereitgestellte Information? Erst danach geht es daran festzulegen, wo die Daten herkommen, wer sie für welche Zwecke nutzt und wie detailliert sie sein müssen. Das entstehende Datenmodell ist sinnvollerweise keine Eigenentwicklung, sondern orientiert sich am Marktstandard, da auch die meisten verfügbaren Tools dies tun. Am weitesten verbreitet ist das Common Information Model (CIM) der DMTF (Distributed Management Task Force), der über 200 IT-Unternehmen angehören.
Das Datenmodell ermitteln
Einer der schwierigen Aspekte bei der Einführung einer CMDB ist es, sich auf ein zu verwendendes Datenmodell und die zugehörige Attributliste zu einigen, gerade weil die Informationen abteilungsübergreifend bereitgestellt und genutzt werden. Kommt dann noch die Business- oder Prozesssicht ins Spiel, müssen die Attribute zusätzlich zwischen IT und Fachbereichen verhandelt werden. Dies ist keine Kleinigkeit, da oft nicht einmal die verschiedenen IT-Abteilungen dieselbe Sprache sprechen.
Die Datenbestände in den vorhandenen Systemen haben bereits feste Strukturen und Formate, auch eine Reihe von Attributen sind dort bereits definiert. Diese gilt es nun in das neue System zu überführen und zu normieren (Reconciliation). Mapping-Tabellen helfen zu bestimmen, welches Attribut aus dem Quellsystem welchem Attribut in der CMDB entsprechen soll. In der Regel haben die verschiedenen Abteilungen bereits unterschiedliche Sichten auf die Systeme oder CIs (Configuration Items), die es nun ebenfalls zu vereinheitlichen gilt.
Sind unterschiedliche Datenquellen vorhanden, die ein gemeinsames Feld befüllen sollen, lässt sich nur noch regelbasiert entscheiden, welches die führende Datenquelle sein soll. Organisatorische und technischen Anforderungen gehen also auch hier Hand in Hand.
Bei den eigentlichen Objekten der CMDB, den CIs, ist das Problem ähnlich gelagert: Wo ist die Definitionsgrenze? Ein PC ist ein CI, ein Server, ein Switch und eine Applikation ebenfalls. Schwieriger ist es schon bei Server-Bausteinen wie Prozessoren, Festplatten oder Netzteilen. Rechenzentren betrachten diese oft als eigenständige CIs: Sie sind komplett austauschbar und liefern zudem für die Betriebsüberwachung wesentliche Informationen wie Prozessorlast, Plattenplatz und Wärmeabgabe.
CI-Definition
Feste Vorgaben gibt es also nicht. Jedes Unternehmen muss auf Basis der eigenen Anforderungen festlegen, was ein CI ausmacht und was eben nur eine CI-Komponente ist. Grundsätzlich gilt, dass die Qualität einer CMDB nicht mit der in ihr gespeicherten Datenmenge steigt, sondern mit dem Nutzungsgrad gespeicherter Information. Daher ist der häufig anzutreffende Ansatz, alles in die CMDB aufzunehmen, was per Discovery identifizierbar ist, falsch.
Ein geringer Detaillierungsgrad mit flachen Datenstrukturen und wenig Vererbungen zwischen den CI-Klassen bringt weitere Vorteile mit sich: Aktualisierungen haben eine kürzere Laufzeit, können daher öfter durchgeführt werden und verursachen weniger Fehler beim Datenimport. Außerdem ist der spätere Aufbau grafischer Beziehungsgeflechte wesentlich performanter. Kurz: Eine CMDB ist dann optimal, wenn man bei der Beschreibung der CIs und Services nichts mehr weglassen kann.
Hat man sich auf die Detailtiefe geeinigt, gilt es, die Datenlieferanten zur vollständigen und zeitnahen Bereitstellung zu verpflichten. Ist ein Datenlieferant jedoch für die CMDB gleichzeitig einziger Nutzer der bereitgestellten Informationen, haben diese dort nichts verloren. Es ist wichtig, sich die CMDB als Datendrehscheibe für alle Nutzer und Prozesse vorzustellen, wobei jeder Lieferant die CI-Informationen anreichert und eine andere Sicht auf die Daten nutzt.
Schnittstellen einbauen
Als integratives Werkzeug benötigt die CMDB Update-Schnittstellen zur Discovery, zu externen Administrations- und Monitoring-Tools sowie zu prozessunterstützenden Werkzeugen, die CI-Informationen verändern oder ergänzen. Hier reicht es nicht, mit Copy and Paste oder mit manuellen Ex- und Importen zu arbeiten. Der Datenabgleich sollte regelbasiert und zuverlässig immer zu den gleichen Zeiten ablaufen. Nur aktuelle, vollständige und richtige Daten erhalten das Vertrauen in die Inhalte der CMDB aufrecht.
Ob Discovery-Mechanismen für die Befüllung der CMDB nötig sind, hängt von der Größe des Unternehmens und der Datenhaltung ab. Manche Attribute lassen sich noch manuell erfassen oder über Werkzeuge wie Microsoft SMS auslesen. Eine vollständige Discovery geht jedoch darüber hinaus und erkennt auch Abhängigkeiten zwischen CIs. Dieser Fähigkeit sind jedoch dort Grenzen gesetzt, wo Unternehmen viele selbst entwickelte Anwendungen einsetzen, die von marktüblichen Discovery Patterns nicht erkannt werden.
Zwar sind moderne Discovery-Werkzeuge lernfähig, jedoch muss der „Trainingsaufwand“ in Relation zum Nutzen stehen. Wo Discovery nicht das probate Mittel ist, bleibt nur der Weg über prozessgesteuerte Änderungen. Beispielsweise kann der softwaregestützte Change-Prozess gleichzeitig mit der erfolgreichen Umsetzung von Changes die CI-Updates übernehmen. Selbstverständlich sind diese CMDB-Änderungen über Prozesse in regelmäßigen Abständen über Audits und Stichproben zu verifizieren.
Die Befüllung der ersten CMDB-Keimzelle, beispielsweise physische Server, sollte bereits einen sichtbaren Nutzen generieren. Diese Anfangserfolge geben dem CMDB-Projekt die notwendige Dynamik, um sukzessive weitere CI-Typen aufzunehmen: virtuelle Server, Anwendungen, Netzwerkkomponenten, schließlich auch IT-gestützte Business-Services. Idealerweise orientiert man sich dabei am OSI-Schichtenmodell und nimmt immer benachbarte CI-Typen hinzu, da mit diesen in der Regel auch die Beziehungen bestehen.
In den letzten Jahren hat leistungsfähigere CMDB-Technik die Verbreitung so genannter „ Federated CMDBs“ begünstigt. Im Gegensatz zur klassischen Datenreplikation verbleiben hier viele CI-Informationen auf ihre Quellsysteme verteilt. Zum Zugriffszeitpunkt wird dann aus den aktuellen Daten die Gesamtsicht auf das CI und seine Relationen aufgebaut. Für den Nutzer ist der unterschiedliche Datenursprung nicht erkennbar.
Diese Federation bietet sich überall dort an, wo Sichten auf stark volatile Daten (zum Beispiel aus dem Monitoring) im CI- oder Service-Zusammenhang erforderlich sind. Das kann der Auslastungsgrad eines SAN-Laufwerks sein, die Prozessorlast eines Anwendungs-Servers oder die aktuelle Datendurchsatzrate in einem LAN-Segment.
Der Nachteil föderierter Systeme ist, dass sich die (Hoch-)Verfügbarkeitsanforderung dann nicht mehr nur auf eine CMDB, sondern auf alle vorgelagerten Datenbanken bezieht, was zum Aufbau sehr kostspieliger Strukturen führen kann.
Zwischen der CMDB und dem Change-Management existiert eine sehr enge Verbindung. Unternehmen, die nicht beides gleichzeitig einführen können oder wollen, müssen eine Reihenfolge bestimmen. Dabei gilt: Keine CMDB ohne Change-Management, wohl aber ist Change-Management ohne eine CMDB möglich. Man kann das Change-Management auch als Pflegeprozess für die CMDB betrachten, da sich durch Changes die in der CMDB gespeicherten Konfigurationsinformationen ändern. Die Dokumentation dieser Änderungen in einer CMDB ist also sinnvoll, aber nicht zwingend. Ist aber eine CMDB vorhanden, müssen Änderungen auf jeden Fall einem Change-Management-Prozess unterworfen sein. Nur so lassen sich beispielsweise unautorisierte Changes auf-decken.
CMDB-Zugriff
Die Sicht auf die Infrastruktur und der CMDB-Zugriff müssen direkt aus dem Change-Management heraus erfolgen können, ohne dafür das Tool zu wechseln. Der Change-Planer muss unmittelbar erkennen, welche Auswirkungen die geplante Änderung auf verbundene CIs, SLAs oder parallel angesetzte Changes hat.
Jeder Change hat potenziell Auswirkungen auf Verfügbarkeiten, Kapazitäten, Produktionsmengen in der IT, aber auch auf Geschäftsprozesse, die sich auf die IT stützen. Alle Auswirkungen bergen Risiken, die nur bei sorgfältiger Planung und Kenntnis aller Zusammenhänge beherrschbar sind. Wenn eine CMDB von so zentraler Bedeutung ist, warum gibt es dann keinen Marktstandard? Die Antwort: Es gibt einen – oder zumindest Ansätze dafür. Die DMTF hat zum Thema Federation eine eigene Arbeitsgruppe ins Leben gerufen, in der sich große CMDB-Hersteller mühevoll, aber erfolgreich auf einen Standard (CMDBf) geeinigt haben. Da aber in vielen Punkten unterschiedliche Technik für CMDB-Funktionen zum Einsatz kommt, sieht jeder Hersteller sein eigenes Produkt als Standard.
Hinzu kommen Weiterentwicklungen der zugrundeliegenden Theorie: So spricht ITILv3 nicht mehr von einer CMDB, sondern verwendet bewusst den Begriff CMS (Configuration Management System).
Aber ob CMDB oder CMS: Die Krux bei beiden ist, dass sie sehr komplexe Gebilde ohne standardisierten Aufbau sind. Daher empfiehlt sich die Zusammenarbeit mit erfahrenen externen Beratern, die bereits entsprechende Projekte durchgeführt haben und die Fallstricke kennen. So lassen sich kostspielige Kardinalfehler wie das unnötige Aufblähen der CMDB wegen zu groß gewählter Detailtiefe von Anfang an vermeiden.

Zehn goldene Regeln für CMDB-Projekte

• Daten auf Prozessnutzen prüfen
• Kritischer Erfolgsfaktor Vollständigkeit
• Kritischer Erfolgsfaktor Aktualität
• CMDB-Datenlieferanten ermitteln und verpflichten
• CMDB-Datenkonsumenten ermitteln und Vertrauen aufbauen
• Datenmodell an Standard anlehnen
• Datenmodellierung in mehreren Stufe aufbauen
• Einführung erst als „Meta-Directory“
• Vertrauen bei den Anwendern schaffen
• Externen Berater als erfahrenen Vermittler zwischen den Silos nutzen

Martin Hagenauer ist Senior Consultant bei Materna in Dortmund.