Configuration Management – die ungelöste Baustelle des CIOs

Es ist eines der Grundübel heutiger IT Organisationen: sobald etwas vorgefallen ist weiss keiner „was Sache ist“,  „wer zuständig ist“, „ob jemand etwas gemacht hat“. Sehr viel Zeit und Energie muss aufgebracht werden, um überhaupt einmal Klarheit zur Situation zu erhalten. Wenn sich der Nebel dann irgendeinmal anfängt zu lichten, ist der Weg zur Lösung überraschend schnell geklärt. Zwischenzeitlich nagt der Kunde wohl an den Nägeln und bangt, ob er von seiner IT nicht im Stich gelassen wird.

Unglaublich – aber leider täglich gelebte Realität in den meisten IT Organisationen die ich kenne. Dabei spielt die Grösse oder Branche einer IT Organisation überhaupt keine Rolle. Auch professionelle Service Provider kämpfen mit dem gleichen Phänomen:  die über eigenständige Plattformen, Datenanken, Servern und Applikationen zusammengezimmerten Anwendungen – oder neudeutsch „Services“  – führen aus Komponenten-Sicht ein völliges Eigenleben mit einem mehr oder weniger abgestimmten Produktelebenszyklus. Was einmal als Ganzes aus dem Projekt in den Betrieb „entlassen“ wurde, versinkt in ein grosses schwarzes Loch, welches niemand mehr in seiner Komplexität zu durchschauen vermag.  Die Einzelkomponenten gehen in die Verantwortung von einzelnen Produktespezialisten über – und schon nach kurzer Zeit beginnen sich die Zellen des Services zu verselbstständigen und zu verändern: neue Releases, neue HW Architekturen, neue Netze, neue Patchlevel – was auch immer der Grund dazu ist.

Das ist gelebte Praxis – damit muss eine professionelle IT Organisation umgehen können. Verwerflich aber ist, dass über das ganze Geschehen keine Aufzeichnungen oder auch nur rudimentäre Dokumentationen vorliegen und die gesamte Nachvollziehbarkeit auf Basis von Erinnerungen beteiligter Spezialisten beruht.. Änderungen werden nicht koordiniert durchgeführt – oftmals nicht einmal  ordentlich beantragt und bewilligt.  Das Resultat überrascht nicht: eine empirische Studie hat gezeigt, dass über 70% von auftretenden Störungen ihre Ursache in solchen Systemanpassungen haben.

Die Situation geht in der Regel noch glimpflich aus, da die einzelnen Spezialisten als wahre Helden der Organisation sich unermüdlich und zu allen Unzeiten an die Reparatur wagen. Und wenn es dann geschafft wurde, klopft man sich gegenseitig auf die Schulter – anstelle sich zu fragen, wie so etwas künftig in den Griff zu bekommen ist.

Wenn man bedenkt, wie gross die strategische und auch operative Abhängigkeit der Geschäftsabläufe vom Funktionieren der IT Systeme ist, dann kann man als Aussenstehender nur den Kopf schütteln.  Ein „Saustall“ wäre wohl einer der oft bezeichneten Vorwürfe solcher Zustände, wenn man sich als CEO der Situation bewusst wäre. Das ist er sich aber leider nicht – und daher wird auch wenig dagegen unternommen. Man stelle sich aber einmal vor, ein Flugzeug oder eine Seilbahn würde so betrieben und gewartet – Kein Mensch würde einen Fuss in das Gefährt stellen und kaum einer hätte mehr das Vertrauen in den Betreiber. Der Betrieb würde wohl über kurz oder lang eingestellt werden müssen.

Die Situation ist auch für einen CIO schon lange nicht mehr haltbar. Nicht nur dass keine Klarheit der IT Assets und deren Zustand vorliegt – die fehlende Transparenz verunmöglicht es dem IT Leiter die Kosten eines gesamten Services tatsachengetreu auf die Benutzer auszuweisen. Die Qualität der Services kann nicht gemessen werden, weil niemand genau weiss, welche Komponenten wie zum Gelingen des Services beiträgt.  Auch rechtlich befindet sich der IT Leiter immer mehr im Graubereich, weil die notwendigen Lizenzen im  Betrieb, für den Test oder die Backup-Lösung nicht klar nachgewiesen werden können. Und immer mehr kommen Compliance-Anforderungen von gesetzlicher Seite hinzu, welche die Nachweispflicht von korrekten Geschäftsabläufen auch in IT Systemen verlangen. Sorgfaltspflichten, welche ein IT Leiter im Tagesrhythmus verletzt – verletzen muss, weil er die Situation nicht beherrschen vermag.

ITIL® empfiehlt  hierzu die Einrichtung eines Configuration Management Systems (CMS) und einen dazugehörigen Service Asset & Configuration Management Prozess. Es ist das eigentliche Rückgrat des Service Management Systems. Um effizient und effektiv meine Services betreiben zu können, ist der Service Provider auf verlässliche Daten angewiesen, welche die Basis für Entscheidungen bilden. Ohne diese Daten und deren Verlässlichkeit werden oft falsche oder zumindest nicht optimale Entscheidungen gefällt, was in aller Regel zu Verzögerungen und Mehrkosten führen wird. Schlimmer noch als keine Daten sind falsche Daten! Wenn die Daten fehlen braucht es die eingangs beschriebene Zeit und Energie, um sich ein einigermassen klares Bild machen zu können. Bei falschen Daten ist es verheerender: bis der Fehler entdeckt wird, kann bereits sehr viel Zeit und Geld verschwendet worden sein. Effizienz und Effektivität fällt wie ein Kartenhaus in sich zusammen, wenn diese Datengrundlage dazu fehlt.

Die Notwendigkeit einer CMDB ist mittlerweile auch auf CIO-Stufe erkannt worden. Nur – was das kosten- und aufwandmässig genau bedeutet vermag ihm niemand so richtig zu erklären. Die Spannweite reicht von einer einfachen Inventar-Datenbank bis hin zu einem komplexen Datawarehouse-Projekt. Sponsoren für solche Vorhaben lassen sich praktisch keine finden. Wer will schon für etwas zahlen, dass er als klare Voraussetzung eines professionellen Betriebs hält.

Um es vorweg zu nehmen: die perfekte Lösung gibt es nicht. Viele Configuration Management Projekte sind aufgrund der Erkenntnis der unbedingten Notwendigkeit einer CMDB gestartet worden. Wenn man heute die Verantwortlichen in den Organisationen nach dem erzielten Erfolg frägt, erhält man oft ernüchternde Antworten. Projekte sind entweder versandet oder irgendwie als abgeschlossen deklariert worden. Die gewünschte Transparenz ist in den seltensten Fällen erreicht worden. Und dabei liegt es nicht an den mehr oder weniger aufwendig evaluierten Tools oder den gut gemeinten Metadatenmodellen.  Nein – in aller Regel fehlt es am Willen des IT Managements, die teure Investition richtig einzusetzen. Wer „A“ sagt, muss auch zu „B“ bereit sein. Wenn viel Geld für eine CMDB bereitgestellt wird, dann ist es eine Sorgfaltspflicht des IT Leiters dafür zu sorgen, dass die Investition sich auch rechnet – und nicht zu einer Datenmüllhalde verkommt, bei der sich keiner seiner Mitarbeiter im Tagesgeschäft darauf verlassen kann. Die Pflege der Daten ist absolute Pflicht, welche nicht weg diskutiert werden kann. Wer das tut, handelt fahrlässig.

Folgende 5 Tipps sollen helfen, eine pragmatische Vorgehensweise für die erfolgreiche Implementierung eines Configuration Management Systems zu ermöglichen. Dem Management muss jedoch von Anbeginn des Unterfangens klar sein, dass Configuration Management viel Geld und Durchsetzungskraft benötigt. Die Freiheiten des isolierten „Werkelns“ müssen bei allen Beteiligten rigoros eingeschränkt werden. Wem der Wille fehlt, sich bei seiner IT Belegschaft hierzu durchzusetzen, dem rate ich zur Aufgabe des Projektes. Er wird sonst nur hohe Kosten verursachen und das Vorhaben nie erfolgreich beenden.

1. Orientierung am erwarteten Nutzen Eine CMDB ist nie Selbstzweck. Nur weil es notwendig ist, muss man den Aufwand noch lange nicht  tätigen. Es muss vielmehr klar verstanden werden, welchen nachweislichen Nutzen erwartet wird. Wo ist die Transparenz wichtig und wie sind diese verschiedenen Anforderungen zu priorisieren.Eine CMDB selbst bringt noch keinen Nutzen. Niemand ist grundsätzlich bereit, Geld für die blosse Verwaltung von Daten bereitzustellen. Wenn man CMDB-Betreiber nach dem Zweck des Configuration Managments fragt, ist das aber oft genau die Argumentation. Erst wenn ich erkenne, dass ich in anderen Prozessen schneller bin (z.B. Incident Mgmt) oder dass ich aufgrund der verlässlichen Information sicherer entscheiden kann (z.bsp. bei Beurteilungen von Change-Anträgen) dann verstehe ich den wahren Wert einer CMDB.

   Es ist aber ein Irrglaube, mit der Beschaffung eines neuen CMDB-Systems viele andere bereits etablierte und im Betrieb verankerte Systeme ablösen zu können. Was theoretisch als Begründung für solch ein Projekt oftmals herhalten muss, zeigt sich in der Praxis vielfach als unmögliches Unterfangen. Der Aufwand, ein etabliertes Tool mit der Brechstange herauslösen zu wollen, zeigt sich oftmals als Utopie. Zu stark sind die Werkzeuge im Betrieb verankert. Und zu gross ist der Widerstand sich von einem Tool zu trennen, welches durch die Spezialisten mit viel Engagement über die Jahre auf- und ausgebaut wurde. Ein neues Tool wird in aller Regel nie den detaillierten Funktionalitätsgrad bestehender Lösungen erfüllen können.

   Der Nutzen liegt also nicht in der Einsparung von anderen Tools, sondern muss in der Effizienz und Wirksamkeit der von den Configuration Management Daten abhängigen Service Management Prozesse begründet werden. Dort, und nur dort wo der grösste Nutzen erwartet wird, soll begonnen werden.

2. Think big – start small: Oft geht man zu euphorisch bei der Planung des Projektes vor. Verständlich, wenn die Notwendigkeit einer CMDB endlich erkannt worden ist. Man ist schnell versucht, alles bis ins letzte Detail abbilden zu wollen. Sämtliche ungelösten Probleme der IT aus den letzten Jahren sollen nun in diesem CMDB-Projekt adresiert werden. Architekten neigen dazu, riesige Metamodelle zu designen, welche oftmals sehr beeindruckend wirken – aber in der Praxis kaum umgesetzt werden können.Solch ein Ansatz ist oftmals zum Scheitern verurteilt. Die Ansprüche sind nicht zu bändigen und führen oft in eine rein akademische Übung. Die Tool-Industrie vermag leider die wirren Vorstellungen der Kunden nicht adäquat abzudecken. Lösungen entpuppen sich oft als reine Kompromisse, welche niemand so richtig zu befriedigen vermag. Und dann gibt es noch die, welche meinen, die ideale Lösung selber entwickeln zukönnen…

   Besser ist der Aufbau einer CMDB in kleinen, verdaubaren und zumutbaren Schritten. Das Bild einer vollständigen Sicht auf die Daten und die Integration anderer Prozesse soll dabei nicht verloren gehen und bei der Wahl der Datenablage berücksichtigt werden. Redundanz und Schnittstellen führen vielfach zu Ineffizienz und zu komplizierten Abläufen. Daher ist die Integration der Daten im Betrieb, im Support Bereich, im Change Umfeld oder bei der Planung und Umsetzung von neuen oder geänderten Services als viel wichtiger zu bewerten, als eine bestimmte Funktionalität aus der Sicht eines einzelnen Prozesses.

3. Befüllen versus Kontrolle – Richtig priorisieren:Wie vorgängig bereits erwähnt, muss durch das IT Management die Kontrolle der nun in der CMDB erfassten Daten sichergestellt werden. Dieser Anspruch kann sich beim Aufbau einer CMDB zu einer Deadlock-Situation entwickeln – zumindest zu Beginn. Das Identifizieren der Daten und das Laden in die CMDB ist eine erste Herausforderung, welche nicht von Anbeginn reibungslos gelingen will. Scanning-Werkzeuge, Migration von Datenbeständen und Design des CMDB-Metamodells sind ein iterativer Prozess, welcher sehr pragmatisch angegangen werden soll.Eine funktionierende CMDB hat den Anspruch aktuelle und korrekte Daten bereitzustellen. Das sind zwei wesentlich zu unterscheidende Merkmale. Aktuell ist nicht immer auch korrekt. Wenn beispielsweise eine illegal installierte Software durch das Scanning in die CMDB geladen wird, dann sind die Daten zwar aktuell – aber noch lange nicht korrekt. Denn diese illegale Software kann durch die Aufnahme in die CMDB nicht so einfach legalisiert werden und  support-berechtigt werden.Es ist zu empfehlen, am Anfang die erste Priorität auf die Aktualität zu legen. Für die IT Organisation ist bereits sehr viel gewonnen, wenn durch periodisches Scanning aktuelle Daten zur Verfügung gestellt werden können. Zudem kann die CMDB verhältnismässig schnell befüllt werden.

   Damit die Daten aber auch korrekt sind, bedingt eine enge Verzahnung mit dem Change Management Prozess. Letztlich muss jede in der IT eingesetzte Komponente nachvollziehbar beschafft, installiert, gewartet und produktiv gesetzt worden sein. Es muss zu jedem Zeitpunkt erklärbar sein, wer etwas beantragt, bewilligt und umgesetzt hat,  und wie der jeweils aktuelle Zustand ist. Der sogenannte Lebenslauf der Komponente muss dokumentarisch nachgewiesen werden können. Nur so kann der verlangte Nachweis zur Korrektheit sichergestellt werden.

   Dieser Nachweis muss mit einem strikt geführten Change Management Prozess sichergestellt werden. Eine jede Änderung wird ordentlich beantragt, beurteilt, autorisiert, implementiert und produktiv gesetzt. Diese Information muss unmittelbar mit den betroffenen IT Komponenten verknüpft werden. Ein gut integriertes Configuration & Change Management stellt damit ein zeitnahes Dokumentieren der Veränderungen automatisch sicher.

4. Rigoroses Durchsetzen der Change Kontrolle: Kaum sind die Daten in der CMDB geladen, sind diese bereits veraltet.  Veränderungen an der Infrastruktur und den Applikationen gehören zum Tagesgeschäft. Gerade hier ist die enge Verzahnung mit dem Change Management Prozess eine wesentliche Voraussetzung, um Transparenz und Nachvollziehbarkeit sicherzustellen.Wenn eine IT Organisation nicht mit einem formellen Change Prozess vertraut ist, darf der Widerstand nicht unterschätzt werden. IT Spezialisten verspüren wenig Lust, ihre Change Vorhaben zu erklären. Ein regelrechtes Unverständnis kommt auf, da sich manch einer in seiner Kompetenz beeinträchtigt fühlt. Dabei geht es gar nicht um das Hinterfragen der fachlichen Kompetenz. Es geht rein um die Koordination der Aktivitäten, der Risikominderung und der Legitimierung der Änderung. Ein guter Change Management Prozess verhindert durch Vereinfachung von operativen und routine-mässigen Änderungen die Bürokratie, in dem vorautorisierte, im Ablauf klar spezifizierte Standard-Changes bereitgestellt werden, welche vereinfacht angewendet werden können.Das IT Management ist hier direkt gefordert. Die Investitionen in eine CMDB steht hier unmittelbar auf dem Spiel – und damit die erhoffte Transparenz. „Wildes“ Ändern darf unter keinen Umständen mehr toleriert werden.  Ein jeder IT Mitarbeiter muss klar verstehen, dass er mit unkontrollierten Änderungen aktiv dem Unternehmen einen Schaden zufügt. Nicht nur dass er die Investition in die CMDB zunichtemacht, viel mehr entsteht der Schaden bei allen anderen IT Mitarbeitern, welche in ihrer Arbeit durch solche Aktionen behindert und in die Irre geleitet werden. Wer sich dieser Anforderung aktiv widersetzt, sollte Zugriffs- und Zutrittsverbot zu IT Komponenten erhalten. Konsequentes Durchsetzen dieser Forderung ist eine absolute Notwendigkeit.
5. Vertrauen ist gut, Kontrolle ist besser: Fehler passieren. Trotz gut kontrolliertem Change Management Prozess kann es nie vermieden werden, dass die Einträge in der CMDB von der Realität abweichen. Es gehört zu einem gut geführten Configuration Management Prozess, dass die Datenbestände regelmässig mit der Realität abgeglichen werden, um solche Fehler zu erkennen und korrigieren zu können. Dies kann auf verschiedene Weise geschehen: durch aktives Scanning, durch Erkennen in der täglichen Arbeit (z.B. Service Desk) oder durch periodische Begehung und Begutachtung der Infrastrukturen.Wichtig ist, dass Abweichungen zur CMDB genau untersucht werden müssen, um die Abweichung nachvollziehen zu können. Eine jede Änderung muss entweder nachträglich legitimiert oder dann rückgängig gemacht werden. Und die Fehler in den beteiligten Prozessen müssen analysiert und im Rahmen der kontinuierlichen Verbesserungen behoben werden.

Fazit

Ein gut geführtes Configuration Management ist eine echte Herausforderung für den CIO. Es ist aber seine Pflicht, dafür zu sorgen, dass dieser Prozess gelebt und eingehalten wird. Ohne ein verlässliches Configuration Management wird er nie die notwendige Transparenz der Kosten, der eingesetzten IT Assets sowie die Einhaltung der Compliance Anforderungen nachweisen können.

Weniger ist hier oftmals viel mehr. Anstelle „alle“ Daten in einer CMDB verwalten zu wollen, sollen mit klar identifizierten Datenbereichen aktuelle und gesicherte Informationen an alle Service Management Prozesse bereitgestellt werden.