Kostenkontrolle beim Softwaremanagement
Schon vor Upgrades Bescheid wissen
Neue Anwendungen bedingen im Vorfeld meist Änderungen an der IT-Infrastruktur. Dafür nötige Aufrüstungen an Hardware und Software bedeuten Risiken und verursachen mitunter erhebliche Kosten. Auf Basis eines leistungsfähigen Konfigurationsmanagements lassen sich jedoch alle anfallenden Änderungen ermitteln und daraus deren Kosten ableiten.
Der Einsatz neuer Anwendungen ist oft eine Herausforderung. Die dazu nötige Planung
umfangreicher Änderungen an der IT-Infrastruktur ist eine anspruchsvolle Aufgabe, die in komplexen
Umfeldern mit bis zu mehreren tausend Servern nur mit bestens gestalteten Prozessen lösbar ist.
Neben der Koordination der Änderungen und der Abstimmung der Termine gilt es, Randbedingungen
technischer Art zu bedenken und zunächst geeignete Voraussetzungen zu schaffen, zum Beispiel durch
Upgrades für das Betriebssystem oder die Datenbankmaschine. Neue Anwendungen oder zum Beispiel
solche, die im Rahmen des Wechsels auf SOA (Service-Oriented Architecture) auf den neuesten Stand
zu bringen sind, werden es oft auch erfordern, zunächst die Hardware der betroffenen Server
aufzurüsten. Wenn solche Begleitmaßnahmen unterbleiben oder nicht zeitgerecht vor einer
Softwareänderung stattfinden, wird sich das in aller Regel negativ auf den Geschäftsprozess
auswirken. Anwendungen sind dann wegen fehlender Upgrades nicht ablauffähig oder wegen fehlender
Ressourcen nicht performant.
Aufrüstungen kosten Zeit und Geld. Vorlaufzeiten müssen in die Terminplanung eingehen,
Investitionen für Hard- und Software sind in der Kostenplanung zu budgetieren. Upgrades, die nur
wenige Maschinen betreffen, lassen sich vielleicht noch aus dem vorhandenen Budget bestreiten. Wenn
jedoch eine Aufrüstung vieler Maschinen – zum Beispiel zahlreicher Server – ansteht, ist eine
rechtzeitige Budgetierung unumgänglich. Wie also ermittelt das IT-Controlling verlässliche
Informationen für eine Kostenkontrolle?
Eine solche Kostenkontrolle ist prinzipiell möglich, wenn ausreichende Informationen vorliegen:
über eine neue Anwendung, insbesondere die hard- und softwareseitigen Voraussetzungen für deren
Einsatz, sowie über die Konfiguration der betroffenen Maschinen. Dann lassen sich aus einer
Baseline resultierende Änderungen an Hard- und Software berechnen und die Kosten der dafür
anstehenden Aufrüstung ermitteln.
Configuration-Management ein Muss
Mit den Herausforderungen des IT-Service-Management vertraute IT-Profis werden schnell erkennen,
dass für diesen Lösungsansatz ein stark ausgeprägtes Configuration-Management unabdingbar ist. Die
CMDB (Configuration Management Database) muss aktuelle Daten liefern, und zwar zu dem Soll-Stand
der Anwendungen (Baseline), dem Ist-Stand der installierten Hard- und Software und den
Abhängigkeiten der Software-CIs (Configuration Items) von Hard- und Software. Ohne diese
Informationen ist die Ermittlung der Kosten von komplexen Änderungen an der IT-Infrastruktur nicht
vorstellbar.
IT-Organisationen, die für ihr komplexes IT-Umfeld eine Kostenkontrolle etablieren wollen,
benötigen diese und weitere Informationen jedoch auch für andere Zwecke: Das Change-Management kann
die nötige Abstimmung und Koordination ohne genaue Kenntnis der Baseline kaum leisten. Ohne
Informationen über die aktuelle Ist-Konfiguration werden Ansätze zum Management komplexer
IT-Strukturen scheitern. Auswirkungen und Risiken von Änderungen an der IT-Infrastruktur entziehen
sich ohne Kenntnis der Abhängigkeiten einer Ermittlung. Diese ist jedoch unabdingbar für stabile
und verfügbare Geschäftsprozesse.
Insofern wird das Konfigurationsmanagement bei IT-Organisationen mit hohen Qualitätsansprüchen
solche Informationen in aller Regel bereitstellen. Probleme kann es bereiten, Informationen über
eine neue Baseline sowie die zugehörigen Softwareobjekte frühzeitig vor einem Rollout zu erhalten.
Die Erfahrung zeigt, dass tragfähige Aussagen dazu manchmal erst wenige Tage vor dem Deployment
vorliegen. Deshalb kann es schwierig sein, die Kosten eines Roll-outs frühzeitig mit der
gewünschten Genauigkeit zu ermitteln.
In solchen Fällen wird die IT-Organisation ihre Erfahrungen nutzen und Annahmen treffen. Sind
bessere Informationen verfügbar, kann die Kostenermittlung erneut erfolgen, um das Budget
gegebenenfalls anzupassen. Bei komplexen IT-Infrastrukturen wird es sinnvoller sein, Auswirkungen
von Änderungen anhand eines strukturierten Verfahrens zu ermitteln, als Vermutungen über die
Auswirkungen anzustellen. Dies gilt selbst dann, wenn für die Eingangswerte, also die
Abhängigkeiten der Software-CIs von ins-tallierter Hard- und Software, zunächst nur Schätzwerte
vorliegen. Dies ermöglicht sukzessive bessere Einsichten in die letztlich anstehenden Änderungen –
und somit auch in die dadurch bedingten Risiken. Insofern ist die Ermittlung der Kosten für
Aufrüstungen mehr oder weniger der Nebeneffekt einer Auswirkungsanalyse (Impact Analysis).
Problemfall Änderung der Baseline
Wie kommt die IT-Organisation zu Informationen über Aufrüstungen, die an der IT-Infrastruktur
anfallen? Im Grundsatz ist dazu eine Funktion erforderlich, die anhand der vom
Configuration-Management bereitgestellten Informationen alle aus der Baseline resultierenden
Änderungen ermittelt, zum Beispiel die Installation und Deinstallation von Software, die
Installation zusätzlicher Hardware (spezieller Grafikkarten etc.) und die Aufrüstung bereits
vorhandener Hardware (Speicher, CPUs etc.).
Danach ist jede Maßnahme im Hinblick auf ihre Kosten (Lizenzierung von Software, Beschaffung von
Hardware) zu bewerten. Dies ist sicherlich nicht trivial: Zum Beispiel sollte das Controlling die
Kosten einer für mehrere Softwareobjekte nötigen Aufrüstung des Serverhauptspeichers nicht ohne
weiteres einfach summieren.
Zunächst gilt es, die Maschinen zu identifizieren, die der Einsatz der neuen Anwendung betrifft.
Erfolgen kann dies statisch anhand in der CMDB geführter Gruppen oder dynamisch auf Basis in der
CMDB enthaltener Informationen über installierte Software. Multi-Tier-Anwendungen erfordern
mitunter spezielle Techniken, die zum Beispiel auf einer Kategorisierung der Maschinen (App-Server,
DB-Server, Client etc.) beruhen. Im Ergebnis steht damit fest, welche Maschinen potenziell
betroffen sind und eventuell Änderungen unterliegen.
In einem zweiten Schritt geht es darum, aus der Baseline die zugehörige Soll-Konfiguration der
betroffenen Maschinen zu ermitteln. Dies wird meist nur derjenige Teil der Softwareausstattung
sein, der für die jeweilige Anwendung relevant ist. In weiteren Baselines lassen sich parallel dazu
Änderungen an weiteren Anwendungen vorbereiten. Die Soll-Konfiguration ergibt sich aus den Objekten
der Baseline selbst und aus den Objekten, die über Abhängigkeiten zugeordnet sind.
Mit dem nun folgenden Soll-/Ist-Abgleich kommen wir zum Kern der Funktion: Dazu vergleicht der
zuständige Mitarbeiter die Soll-Konfiguration der Software jeder Zielmaschine mit ihrer
individuellen Ist-Konfiguration, die er der CMDB entnommen hat. Objekte, die im Soll-Stand, nicht
jedoch im Ist-Stand enthalten sind, sieht er zur Installation vor und nimmt sie in eine
maschinenspezifische Liste von Änderungsmaßnahmen auf. Voraussetzungen und Abhängigkeiten dieser
Objekte – ebenfalls der CMDB entnommen – erzwingen die Planung weiterer Maßnahmen, wie zum Beispiel
die Installation weiterer Softwareobjekte, die Deinstallation älterer Versionen des Softwareobjekts
oder auch anderer Objekte wegen fehlender Koexistenz oder die Installation oder Aufrüstung von
Hardwareobjekten.
Die Abfolge der Softwareänderungen folgt unmittelbar aus den Abhängigkeiten der Software-CIs
untereinander. Für jede betroffene Maschine erhalten wir eine Liste aller Änderungen, die
umzusetzen sind, um die aus der Baseline abgeleitete neue Zielkonfiguration zu erreichen. Diese
Funktion liefert somit völlig automatisch eine umfassende Handlungsanweisung für alle beteiligten
Prozesse, anhand derer das Change-Management seine Koordination ausrichtet, das Risikomanagement
Änderungen über eine Impact Analysis bewertet und das Deployment die Änderungen in der notwendigen
Reihenfolge realisiert.
Das IT-Controlling bewertet nun die Kosten der errechneten Maßnahmen. In einem ersten Ansatz
kann es ausreichen, die Kosten für den Einsatz lizenzpflichtiger Software sowie für eine
Hardwareaufrüstung über eine Tabelle (zum Beispiel einen pauschalen Eurobetrag je GByte
Hauptspeicher) als grobe Anhaltswerte einzubringen. Eine anspruchsvollere Lösung könnte jedoch auch
auf Informationen des Asset-Managements zurückgreifen, um beim Einbau weiterer CPUs zwischen Intel-
und RISC-Architekturen zu unterscheiden oder gar herstellerspezifische Konditionen zu
berücksichtigen.
Die Funktion ist bei geeigneter Gestaltung beliebig oft aufrufbar– sie ändert ja nichts. Dem
jeweiligen Ergebnis kann der Anwender entnehmen, wie sich zum Beispiel Änderungen der Baseline,
zwischenzeitlich erfolgte Aufrüstungen der Maschinen und veränderte Voraussetzungen oder
Abhängigkeiten der CIs auswirken. Da manche Highend-Tools zum Softwaremanagement die Ermittlung der
Auswirkungen einer neuen Anwendung als integrierte Funktion anbieten, muss die hier skizzierte
Funktion nicht erst aufwändig realisiert werden. Von Vorteil ist es, wenn ein solches Tool dann
auch noch sicher und kostengünstig das Deployment übernimmt.
Lesen Sie mehr zum Thema
