„Ordnung ist die Verbindung des Vielen nach einer Regel“ (Teil 3)

Nachdem ich in den ersten beiden Teilen den Nutzen (Teil 1) sowie den Aufbau (Teil 2) einer gut strukturierten CMDB thematisiert habe, gehe ich in diesem Teil auf die Pflege einer Configuration Management Database (CMDB) ein, denn ein CMDB-Projekt endet keineswegs mit der Inbetriebnahme. Die fortwährende Pflege ist sogar essenziell wichtig. Nur wenn Configuration Items (CIs) und deren Relationen aktuell sind und das Metamodell sich an stetig ändernde Rahmenbedingungen anpasst, kann die CMDB ihr tatsächliches Potenzial ausschöpfen und zu einem wertvollen, verlässlichen Werkzeug werden.

Die Pflege einer CMDB kann mit zunehmender Größe schnell zu einem unlösbaren Problem werden. Die CMDB stellt eine Projektion der geschäftsrelevanten Objekte und deren Beziehungen innerhalb der Organisation dar. Mit der zu erwartenden zunehmenden Dynamisierung der Geschäftsmodelle wird von der CMDB immer mehr ein „Echtzeit-Abbild“ erwartet. Diese Arbeit ist ab einem bestimmten Zeitpunkt kaum noch manuell möglich und sollte daher automatisiert werden.

Bei der Automatisierung ist darauf zu achten, dass nicht nur CIs und Attribute, sondern auch deren Relationen automatisch erfasst werden können. Bei der Dynamik heutiger Techniken und der erwarteten IoT-Welle ist eine intelligente, standardisierende Discovery Engine unverzichtbar. Sie muss in der Lage sein, verschiedenste technische Objekte sicher zu identifizieren, deren Status und Konfiguration auszulesen und dem Anwender auf einer normalisierten Basis leicht verständlich zugänglich zu machen.

Der Status von CIs wird üblicherweise nicht in CMDBs gepflegt, ist aber als Attribut sehr hilfreich, wenn es darum geht, die CMDB als Fundament für darüberliegende Prozesse zu nutzen. Ein einfaches Beispiel soll dies verdeutlichen: Wenn ein Drucker ein wichtiger technischer Bestandteil eines Geschäftsprozesses ist, weil er Lieferscheine druckt, ohne die die LKWs nicht starten können, so ist es wünschenswert, nicht nur die Konfiguration der Hardware und Relationen wie verantwortliche Personen usw., sondern auch den aktuellen „Gesundheitszustand“ des Druckers zu kennen. Dabei möchte ich als Betreiber eines Geschäftsprozesses gar nicht genau wissen, ob das Gerät ein Problem mit der Netzwerkanbindung oder zu wenig Toner hat. Es geht pragmatisch nur darum, ob das Gerät seine Arbeit verrichtet. Es kann also von dieser Perspektive aus nur den Status „Grün“ oder „Rot“ besitzen. Für den technischen Betreiber des Services „Drucker“ ist es hingegen sehr wohl wichtig, an was der Drucker aktuell krankt und deshalb seine Arbeit nicht leisten kann. D. h., der Gesundheitszustand eines Druckers kann sich aus verschiedenen Komponenten zusammensetzen, die ihrerseits wiederum einen Status aufzeigen. So kann der Service „Lieferschein-Drucker“ aus unterschiedlichen Perspektiven auch verschiedene Status haben: z. B. für den Prozess-Owner „Grün“, weil der Service funktioniert, und für den Service-Owner „Gelb“, weil der primäre Drucker ausgefallen und bereits der redundante Drucker in Betrieb ist. Die hierzu notwendigen Korrelationen sollten ebenfalls automatisiert erfolgen. (Stichwort: Künstliche Intelligenz! Mehr dazu in meinem nächsten Blog-Beitrag.)

Neben der intelligenten Discovery-Funktion muss die CMDB über ausreichend Schnittstellen und Methoden verfügen, um Daten aus Drittsystemen jederzeit sauber abgleichen zu können. Aber auch diese Daten sollten die Normalisierungsalgorithmen durchlaufen, sodass in der CMDB immer ein einheitliches Abbild der heterogenen Realität erzeugt werden kann.

Natürlich ist es wünschenswert, beim Betrieb eines solch zentralen Systems möglichst wenige Schnittstellen pflegen zu müssen. Dem wird am besten entsprochen, indem man: (a) Software einsetzt, die möglichst viele der benötigten Informationen selbst einsammelt, und/oder (b) die Schnittstellen so gestaltet, dass sie sich nach Möglichkeit zwischen relativ „entwicklungsträgen“ Instanzen befinden. Beispielsweise ist eine Schnittstelle zwischen zwei Datenbanken gegenüber einer Schnittstelle zwischen einer externen Discovery Engine und einer Datenbank zu bevorzugen, da sich Datenbankstrukturen in der Regel seltener ändern und somit Schnittstellen seltener angepasst werden müssen.

Es steht zu befürchten, dass es eine „EWMS“-Software („Eierlegende Woll-Milch-Sau“), die uns all diese Anforderungen in einer Lösung realisiert und im Betrieb mehr Arbeit abnimmt als Schnittstellen erzeugen, nicht geben wird . Also muss mit diesem Thema möglichst pragmatisch und intelligent umgegangen werden.

Unter diesen Gesichtspunkten ist eine gut strukturierte CMDB nicht nur ein Werkzeug, um die geschäftsrelevante Realität abzubilden, sondern auch eine Art Universal-Übersetzer, der aus einer komplizierten, unübersichtlichen, vielsprachigen Welt eine einfach zu verstehende Basis für Anwender und Management liefert.

Meiner Erfahrung nach begegnet man heute noch oft dem Fall, dass im Zusammenhang mit einem CMDB-Einführungsprojekt und einem leicht ironischen Unterton der Spruch fällt: „Der Weg ist das Ziel“. Wird jedoch die CMDB als das gesehen, was sie ist, nämlich ein Ordnungswerkzeug, das für die IT und das gesamte Unternehmen im Dienste der Geschäftsprozesse steht, und wird sie nach den obigen Gesichtspunkten eingeführt und betrieben, so wird die Anzahl erfolgreicher Projekte gewiss zunehmen. Dann wird ein anderer Slogan solche Projekte begleiten, der wahrscheinlich auch Immanuel Kant gefallen hätte: „Nicht der Weg ist das Ziel, sondern das Ziel bestimmt den Weg!“

 

Autor: Kürsad Gögen, Portfolio Manager

Kontakt: Kuersad.Goegen@dot4.de

Schreibe einen Kommentar

Your email address will not be published. Required fields are marked *