Dos and Dont's im Configuration Management

Susanne Bandi ist Geschäftsführerin der DIS GmbH und Spezialistin für Configuration Management Ziel des ITIL-Change-Management-Prozesses ist es, Änderungen an der IT-Service-Landschaft entsprechend den geschäftlichen Anforderungen termingerecht, risikominimiert, kosteneffizient und kontrolliert durchzuführen. Das Configuration Management trägt zum Erreichen dieser Ziele bei, indem es aktuelle und genaue Informationen über die IT-Komponenten und deren Beziehungen im Configuration Management System (CMS) zur Verfügung stellt. Diese Informationen werden an mehreren Stationen im Änderungsprozess benötigt (siehe Grafik). Configuration Management beginnt mit dem Configuration-Management-Planning-Prozess. Dazu gehört: - Verantwortlichkeiten definieren und Kennzahlen festlegen - Eine solide CMS-Architektur und Konzeption (inkl. Metamodell) - Standardprozesse definieren (Beispiele siehe CoM Blog: www.dis.ch/blog/index). Dann allerdings stellen sich die entscheidenden Fragen, auf welche die ITIL-Literatur keine ausreichenden Antworten bietet: Welche IT-Komponenten sollen ins CMS übernommen und dort als sogenannte Configuration Items (CI) geführt werden? Was ist der benötigte Configuration Control Level? Bei der Umsetzung sind folgende unterschiedliche Ansätze mit jeweils verschiedenen Vor- und Nachteilen möglich.

Hier werden zuerst die logischen Komponenten (Business Service, IT Services, Produkte, Applikationen etc.) sowie ihre Beziehungen ins CMS integriert. In vielen Firmen sind solche Daten bereits in Inventar-systemen aufgeführt, sodass nur noch die Beziehungen neu erhoben werden müssen. Es empfiehlt sich, die bestehenden Informationen zu überprüfen und die Ownerships festlegen zu lassen, bevor diese ins CMS geladen werden. Beim Design des CMS und der Standardprozesse ist zu beachten, dass später noch viele physikalische Komponenten (Server, Applikationskomponenten z.B. Jar-Files etc.) ins CMS integriert werden sollen. Insbesondere über die Schnittstelle «logisch - physikalisch» muss man sich jetzt schon Gedanken machen. Wenn bereits Daten über physikalische IT-Objekte, etwa aus Discovery-Tools oder anderen ausgereiften Inventarsystemen wie dem Asset Management, mit akzeptabler Abdeckung und Datenqualität zur Verfügung stehen, können diese ansatzweise herangezogen werden. Dieser Ansatz unterstützt bestimmte Teilaspekte des Change-Prozesses (Forward Schedule of Change, Impact-Analyse). Die genauen Auswirkungen können zwar nicht im Detail bestimmt werden, aber zumindest weiss man, welches die Ansprechpartner sind. Für eine Konfigurationsüberprüfung vor dem Rollout hingegen fehlen die Informationen. Durch die in dieser Abstraktionsebene noch überschaubare Menge an Objekten können die Prozesse einfacher eingespielt und durchgesetzt werden.  

Bei diesem Ansatz wird mit den physikalischen Komponenten begonnen (Server, Betriebssystem, Middleware, Datenbankinstanzen etc.). Die Frage ist, wie tief Configuration Items und deren Beziehungen modelliert werden sollen - und ob ab einem bestimmten physikalischen Detaillierungsgrad auch Discovery-Daten mit dem vom Change-Management verwalteten Configuration Items verbunden werden sollen. Die Menge an CIs und Beziehungen sowie die daraus resultierenden Change Requests sollten Sie allerdings nicht unterschätzen. Eine Automatisierung kann hier die Prozesse erheblich beschleunigen. Um den vollen Nutzen aus dem CMS abzuschöpfen, müssen in einem nächsten Schritt logische Komponenten im CMS geführt werden. Das sollten Sie bereits bei der Architektur und beim Erstellen der Standardprozesse berücksichtigen, denn es kann unter anderem Einfluss auf die Bestimmung einer eindeutigen Objektidentifizierung haben. So sollte keine Eigenschaft gewählt werden, die nur bei physikalischen Komponenten existiert wie eine Seriennummer. Eine Verknüpfung mit existierenden anderen Inventaren, in denen heute bereits Services und Applikationen geführt werden, ist möglich.Dieser Ansatz unterstützt den technischen Teil des Change-Prozesses (technische Abhängigkeiten, Abstimmung), aber der Kundennutzen (Service-Sicht) wird vernachlässigt, was zu mangelnder Akzeptanz führen kann. Das Durchsetzen einer Configuration Control stellt vor allem wegen der enormen Menge an Daten ein erhebliches Risiko dar.

Hier wird pro Service jeweils der gesamte Konfigurationsbaum implementiert. Dazu muss zuerst der Konfigurationsbaum identifiziert werden, der als Erster zu integrieren ist. Ein abgestimmtes Vorgehen mit anderen ITIL-Prozessen (z.B. Service Level Management, Capacity Management, Financial Management) drängt sich auf, um Synergien zu nutzen. Beim periodischen Service Review beispielsweise wird der Konfigurationsbaum erhoben, überprüft und integriert. Auch hier stellt sich die Frage, wie detailliert die physikalischen CIs und Beziehungen zu modellieren sind und ob allenfalls Discovery-Daten mit den CIs verbunden werden sollen. Die Architektur des CMS muss von Anfang an darauf eingerichtet sein, dass später auch noch weitere Konfigurations-bäume eingefügt werden können. Dies zieht unter Umständen neue Anforderungen an die Metadaten nach sich, da sich die verschiedenen Konfigurationsbäume in der Struktur und Ausprägung möglicherweise unterscheiden. Dabei sind von Anfang an Mengen und Häufigkeiten zu berücksichtigen und Automatisierungsmöglichkeiten zu prüfen. Letztere beschleunigen und vereinfachen die Integration weiterer Konfigurationsbäume. Dieser Ansatz ist optimal. Sobald die ersten Konfigurationsbäume implementiert sind, lassen sich Aufwand und Ertrag durchgängig ausweisen. Dies wird auch die verbleibenden Service Owner und die Sponsoren vom Vorhaben überzeugen. Configuration Control und Automation sind ebenfalls hier im Auge zu behalten.  

Welches ist nun der richtige Weg? Das hängt natürlich auch von den Erwartungen und den spezifischen Bedürfnissen ab. Insgesamt verfolgt jedoch der Ansatz «Konfigurationsbaum pro Service» einen gesamtheitlichen und damit den erfolgversprechendsten Weg für den Aufbau und Ausbau Ihres Configuration Management Systems. Dies gilt vor allem, wenn das CMS zusammen mit einem der Service-Support-Prozesse eingeführt wird. Abgesehen von den bereits genannten Punkten sind für ein erfolgreiches Configuration Management aber noch vier weitere Aspekte unabdingbar. Erstens: das Einbinden des Configuration-Control-Prozesses in den Change-Management-Prozess. Zweitens: schnelle erste Resultate, beispielsweise Reports aus verschiedenen Quellen erstellen. Drittens: Automatisieren, wo immer möglich. Und viertens: eine Applikation, welche die vordefinierten Configuration-Management-Anforderungen erfüllt und sich mit den bereits eingesetzten ITIL-Prozess-Tools möglichst gut integriert.