Leseprobe
Inhaltsverzeichnis
Abbildungsverzeichnis
Abkürzungsverzeichnis
1 Problemstellung und Zielsetzung
2 Definition, Bestandteile und Funktionsweise einer CMDB
2.1 Grundlagen und Bestandteile einer CMDB
2.2 Vorgehensweise und beispielhafter Aufbau einer CMDB
3 Lokalisierung des Werkzeuges CMDB im ITIL Prozess
3.1 CMDB als Teil eines Configuration Management Systems
3.2 Rolle des Service Asset and Configuration Management im Unternehmen und deren Verankerung im ITIL Prozess
4 Vor- und Nachteile von CMDB Systemen
4.1 Vorteile von CMDB Systemen
4.2 Nachteile von CMDB Systemen
5 Ausblick und Schlussbetrachtung
5.1 Ausblick
5.2 Fazit
Literaturverzeichnis
Abbildungsverzeichnis
Abb. 1 Detaillierungsgrad einer CMDB
Abb. 2 CI Attributstruktur
Abb. 3 CI Objekthierarchie
Abb. 4 CI Lifecycle
Abb. 5 Prinzip eines CMS Systems
Abb. 6 Lokalisierung des Werkzeuges CMDB im ITIL Prozess
Abb. 7 ITSSM Magic Quadrant von Gartner
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Problemstellung und Zielsetzung
In der heutigen Zeit streben immer mehr Unternehmen danach, ihre IT-Prozesse nach Best Practice Standards auszurichten. Eine der bekanntesten und am meisten eingesetzten IT-Infrastruktur Prozessframeworks ist die IT Infrastructure Library Version 3 (ITIL V3). Die zentrale Informations- und Datenbasis für die Dokumentation von ITInfrastruktur bildet nach ITIL die Configuration Management Database (CMDB). Sie liefert ein logisches Modell der IT-Infrastruktur, mit deren Hilfe sich alle Configuration Items (CIs) identifizieren, verwalten und verifizieren lassen.1
Diese Auffassung und Notwendigkeit im Unternehmenskontext wurde erst in den ver- gangenen 15 Jahren, durch verschiedene Änderungen des Prozessframeworks ITIL, geprägt. Im Jahr 2000 ergab die Eingabe von „CMDB“ in Suchmaschinen wie Google keine geeigneten Treffer. Es wurde auf der ersten Ergebnisseite noch nicht einmal er- klärt, was eine CMDB ist. Eine Erklärung fand man erst auf späteren Unterseiten. Dar- über hinaus wurde zum damaligen Zeitpunkt kein einziger Link angeboten, der zu ei- nem kaufbaren Produkt führte. Heute sieht nicht nur das Suchergebnis anders aus, son- dern es gibt tatsächlich funktionierende Lösungen. Nahezu alle großen, technisch füh- renden und innovativen Hersteller haben die „integrierte CMDB” im Sinne der ITIL V3 in ihr Produktportfolio aufgenommen.2
Ein weiterer Grund, der die Einführung und Nutzung von CMDB Systemen in Unternehmen begünstigt hat, ist, dass die meisten IT-Prozessausfälle auf Konfigurationsänderungen in der IT-Infrastruktur zurückzuführen sind. Durch die steigende Komplexität der IT ergibt sich die notwendige Anforderung, Transparenz und Flexibilität in der Anwendungs- und Infrastrukturlandschaft und eine Durchgängigkeit aller IT-Prozesse zu gewährleisten. Eine CMDB stellt hierbei eine aktuelle Sicht auf alle im Unternehmen befindlichen IT-Komponenten und Service Assets sowie die Abhängigkeiten und Wechselwirkungen der einzelnen Komponenten dar.3 Anhand dieser eindeutigen Verknüpfungen in einer CMDB kann man, im Rahmen einer Schwachstellenanalyse, bei Problemen sofort den single point of failure lokalisieren.4
Die vorliegende Arbeit - „CMDB Systeme als Grundlage zur Dokumentation von IT- Landschaften“ - erläutert zunächst den Aufbau und die Funktionsweise einer CMDB. Im weiteren Verlauf wird dargelegt, dass eine CMDB als Bestandteil eines Configurati- on Management Systems (CMS) fungiert. In diesem Kontext ist zu klären, wie das Werkzeug CMDB im gesamten ITIL Prozess verankert ist. Im 4. Kapitel werden die Vor- und Nachteile von CMDB Systemen aufgezeigt. Im Rahmen der Schlussbetrach- tung werden neben dem Ausblick Prognosen von bekannten Marktforschungsinstituten zum Thema CMDB Systeme vorgestellt. Die Arbeit wird mit einer kritischen Reflektion der Thematik abgeschlossen. Ferner soll den Fragen nachgegangen werden, welchen Mehrwert Unternehmen mit der Einführung von CMDB Systemen erzielen und welches Kostensenkungspotential von der Implementierung solcher Systeme ausgeht.
2 Definition, Bestandteile und Funktionsweise einer CMDB
2.1 Grundlagen und Bestandteile einer CMDB
Die CMDB ist laut ITIL eine Datenbank, die ein logisches Modell der gesamten ITInfrastruktur und der Services aller vorhandenen Prozesse bereitstellt. Ein elementares Ziel ist es, in einem Unternehmen zu gewährleisten, dass man stets einen gesicherten und einen aktuellen Zugriff auf die Daten aller IT-Assets und IT-Konfigurationen sowie den damit verbundenen IT-Services bekommt. Die CMDB ist im Bereich des Configuration Managements verankert. Da in einer solchen Datenbank vielfältige und unterschiedliche Informationen zu den IT-Objekten gesammelt, gepflegt und für andere Prozesse zur Verfügung gestellt werden, ist die CMDB eine der wichtigsten Daten- und Informationsquellen im Bereich des IT-Service Managements.5
Die CMDB ist ein zentrales Speichermedium für alle Geräte, Software und Personen, die in der IT-Umgebung eine Rolle spielen. Diese Objekte werden als CIs bezeichnet. Im Gegensatz zum Asset-Management, in dem nur IT-Assets (Vermögenswerte) erfasst werden, stehen in einer CMDB die Abhängigkeiten der CIs im Vordergrund.6
Die CIs, die für das IT-Service Management essentiell sind, werden in der CMDB ge- speichert und stellen daher einen wesentlichen Bestandteil einer solchen Datenbank dar.7 „Ein CI ist eine in sich geschlossene Konfigurationseinheit, die einen signifikanten Bestandteil der IT-Infrastruktur und IT-Organisation abbildet und dem Managen und der Steuerung der Bereitstellung von IT-Services dient.“8 CIs werden anhand von Attributen näher beschrieben. Generell gilt, dass ein CI als Datensatz, der aus individuellen Eigenschaften besteht und Verlinkungen zu anderen Datensätzen und Dokumenten aufweist, angesehen werden kann.9 Die Verknüpfung der einzelnen CIs untereinander wird auch als CI Relation bezeichnet. CIs können sowohl Hardware- und Softwarekomponenten, aber auch Vertrags- und Betriebsdokumente beinhalten.10
Neben der Erfassung von CIs werden in einer CMDB sogenannte Baselines abgebildet, welche einen bestimmten Konfigurationszustand kennzeichnen. Bedeutungsvoll hierbei ist, dass unterschiedliche Baselines zueinander vergleichbar sein sollen.11 Unter einer Configuration Baseline versteht man die Erfassung der Struktur und der Details eines Produkts oder Systems zu einem spezifischen Zeitpunkt. Hierbei werden etablierte Kon- figurationswerte eines Produkts oder Systems festgehalten, um die Wiederherstellung der soeben genannten Komponenten gewährleisten zu können. Wenn ein Change oder Release fehlschlägt, kann mithilfe einer Configuration Management Baseline eine be- kannte Konfiguration einer IT-Infrastruktur wieder hergestellt werden.12
2.2 Vorgehensweise und beispielhafter Aufbau einer CMDB
Da eine gut durchdachte Struktur einer CMDB als wesentlicher Erfolgsfaktor angesehen werden kann, ist es vor der Einführung einer CMDB unabdingbar, eine entsprechende Anforderungsanalyse im Unternehmen durchzuführen. Im Rahmen dieser Anforde- rungsanalyse wird ermittelt, welche grundlegenden Bestandteile in einer CMDB abge- bildet werden sollen und wie sich beispielsweise die CIs zusammensetzen.13
In diesem Kontext wird bei der Einführung einer CMDB ein entsprechender Detaillie- rungsgrad festgelegt. Anhand des Detaillierungsgrades wird geregelt, welche Informati- onen zu den einzelnen CIs verfügbar sein und welche Namen sowie Attribute abgedeckt werden sollen.14 Unabdingbar ist, darauf zu achten, die CMDB nicht zu detailliert zu gestalten. Denn mit zunehmender Detailtiefe kann eine CMDB schnell überladen wir- ken und die wesentlichen Informationen gehen verloren. Man sollte ein „gesundes“ Mit- telmaß finden, um keine Informationsdefizite entstehen zu lassen.15 Die nachfolgende Grafik zeigt exemplarisch eine Grundstruktur eines CMDB- Detaillierungsgrades.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 1 Detaillierungsgrad einer CMDB16
Die elementare Bedeutung des Detaillierungsgrades ergibt sich aus der Tatsache, dass er als Orientierung für die spätere CI Attributstruktur dient.17 Attribute werden verwendet, um relevante Informationen für die zugehörige Art von CIs zu speichern.18 Die nachfolgende Grafik zeigt exemplarisch die CI Attributstruktur und verdeutlicht die Beziehungen zwischen den einzelnen CIs.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2 CI Attributstruktur19
Es wurde bereits beschrieben, dass einzelne CIs in Beziehung zueinander gesetzt wer- den können. Zum Beispiel kann eine Netzwerkarte (CI 1) ein Teil einer Arbeitsstation (CI 2) sein.20 Durch diese Art von Verknüpfung, die man auch Relation nennt, kann das Datenmodell einer CMDB eine gegliederte objekthierarchische Struktur annehmen.21 Mit Hilfe dieses objektorientierten Ansatzes kann gewährleistet werden, dass durch die Mechanismen, Vererbung und Polymorphie ein hohes Maß an Transparenz und Flexibi- lität erreicht wird. Des Weiteren kann eine Modellierungssprache wie UML (Unified Modeling Language) zur Definition und Pflege des Datenmodells verwendet werden.22 Die nachfolgende Abbildung illustriert den Aufbau der CI-Objekthierarchie.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3 CI Objekthierarchie23
Um die Aktualität einer CMDB zu gewährleisten, müssen die Attribute eines CIs konti- nuierlich gepflegt werden. Da ein CI systemseitig eine eindeutige Referenznummer (ID) besitzt, kann es jederzeit identifiziert werden. Durch die Verknüpfung der einzelnen CIs handelt es sich bei einer CMDB nicht um eine reine Aufstellung eines Mengengerüsts aller eingesetzten IT-Komponenten im Unternehmen, wie es beispielweise beim Asset Management der Fall ist. Vielmehr ermöglichen die Verknüpfungen der CIs, dass man als Unternehmen eine fundierte Folgen- und Schwachstellenanalyse vornehmen kann.24
Bei der Konzeption eines CMDB Datenmodells ist darauf zu achten, dass jeder CI eine begrenzte Lebensdauer hat. Man spricht in diesem Kontext vom CI Lifecycle. Dieser CI Lifecycle spielt bei der Implementierung von CMDB Systemen im Unternehmen eine wesentliche Rolle.25 Im Zuge eines „Status Codes“ wird erfasst, in welcher Phase des Lebenszyklus sich ein einzelner CI befindet. Die konkrete Ausgestaltung dieses Status hängt im Detail von der Ausprägung der IT-Infrastruktur ab, welche man im Unternehmen erfassen möchte.26 Es bietet sich dabei an, die historischen Daten der einzelnen Änderungen zu archivieren und zu dokumentieren. Hierdurch werden Entscheidungen aus Unternehmenssicht rückblickend besser nachvollziehbar sein.27 Die nachfolgende Grafik zeigt exemplarisch einen solchen CI Lebenszyklus.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4 CI Lifecycle28
Eine der wichtigsten Voraussetzungen vor der Einführung ist, dass alle beteiligten Per- sonen das gleiche Verständnis über den funktionellen Umfang von CMDB Systemen aufbringen müssen. Die klare Definition, was eine CMDB können muss und welche Informationen darin dargestellt werden sollen, ist hierbei unabdingbar. Denn nur so ist gewährleistet, dass eine CMDB das erfüllt, was die Verantwortlichen von einer solchen Datenbank verlangen.29
Nachdem man die entsprechende Akzeptanz im Unternehmen erreicht hat, ist es essen- tiell, sich mit dem Planungsprozess für die Implementierung zu beschäftigen. In diesem Kontext müssen Fragen zur generellen Vorgehensweise geklärt werden.30 Ebenso sind in dieser Phase Fragestellungen hinsichtlich der Steuerung, d.h. wie gelangen die Daten in die CMDB, von großer Bedeutung.31 Denn auch die genausten Daten haben wenig Nutzen, wenn sie keinen Zugang zur CMDB finden. Daher sollten CMDB Systeme über mehrere wesentliche Merkmale verfügen. Die CMDB muss eine Schnittstelle zur An- wendungsprogrammierung (Application Programming Interface - API) oder zu anderen Verfahren anbieten, damit Programme diese Daten anzeigen und ändern können. Es ist essentiell, dass der Import von Massendaten möglich ist, damit beispielsweise Dis- covery Anwendungen die Datenbank schnell füllen können. Außerdem sollte eine CMDB mit verschiedenen Betriebssystemen und Datenbankanbietern kompatibel sein, um zu gewährleisten, dass eine CMDB in ihrer Umgebung flexibel ist.32 Neben der soeben beschriebenen Planungs- und Steuerungsphase soll mithilfe von Konfigurations- verifizierung und Audits sichergestellt werden, dass alle Prozesse vollständige und kor- rekte Daten zur Verfügung stellen.33
Bei CMDB Implementierungsprojekten ist weiterhin von großer Bedeutung, vorab klare Verantwortungen zu definieren und festzulegen, welche Aufgabenbereiche einzelne Prozessbeteiligte übernehmen.34 In der Praxis hat sich dabei die folgende Rollenvertei- lung bewährt:
- Process Owner - überwacht das Erreichen der definierten Prozessziele und entwickelt diese weiter.
- Process Manager - ist verantwortlich für die Qualität und Effizienz der Prozesse. Fungiert als Eskalationsinstanz und führt Kommunikations- und Schulungsmaßnahmen durch.
- Configuration Manager - steuert die CI Owner und ist verantwortlich für die Qualität der Daten.
- Configuration Librarian - bestimmt, kontrolliert und strukturiert die entsprechenden CIs.
- Configuration Item Owner - ist für die Aktualität und Richtigkeit der entsprechenden CIs verantwortlich.35
[...]
1 Vgl. BMC Software (2012).
2 Vgl. ITSM Partner Consulting GmbH (2013).
3 Vgl. Matrix Technology AG (2012).
4 Vgl. Olbrich, A. (2008) S. 72.
5 Vgl. Olbrich, A. (2008) S. 72.
6 Vgl. Micro Nova AG (2013).
7 Vgl. Gillmeister, M. (2009) S. 5.
8 Bause, M./ Kresse, M. (2011), S. 142.
9 Vgl. Olbrich, A. (2008) S. 72.
10 Vgl. Bause, M./ Kresse, M. (2011), S. 142.
11 Vgl. Kurz, P. (2013).
12 Vgl. Matrix Technology AG (2012).
13 Vgl. Gillmeister, M. (2009) S. 8.
14 Vgl. van Bon, J. et al. (2008) S. 107.
15 Vgl. Olbrich, A. (2008) S. 72.
16 Vgl. in Anlehnung an: ebd.
17 Vgl. Olbrich, A. (2008) S. 72f.
18 Vgl. van Bon, J. et al. (2008) S. 109.
19 Vgl. in Anlehnung an: Olbrich, A. S. 73.
20 Vgl. Kurz, P. (2013).
21 Vgl. Olbrich, A. (2008) S. 73.
22 Vgl. Matrix Technology AG (2012).
23 Vgl. in Anlehnung an: Olbrich, A. S. 74.
24 Vgl. Olbrich, A. (2008) S. 74f.
25 Vgl. Matrix Technology AG (2012).
26 Vgl. van Bon, J. (2008) S. 112.
27 Vgl. Matrix Technology AG (2012).
28 Vgl. in Anlehnung an: ebd.
29 Vgl. Hahn, S. (2012).
30 Vgl. Eggerstedt, T. (2013).
31 Vgl. Hahn, S. (2012).
32 Vgl. BMC Software (2012).
33 Vgl. Hahn, S. (2012).
34 Vgl. Eggerstedt, T. (2013).
35 Vgl. Matrix Technology AG (2012).