Pannen beim Rollout neuer Applikationen, Versionen, Betriebssystem-Patches oder -Hotfixes sind der Albtraum jedes IT-Verantwortlichen, bedeuten sie dch auf alle Fälle Kosten und beim Ausfall geschäftskritischer Systeme auch einen Imageschaden. Der Grund für solche Störungen liegt meist in den Inkompatibilitäten zwischen der neu installierten Software und der existierenden Umgebung. Derzeit hat ein durchschnittliches Unternehmen zwischen 400 und 15.000 Softwarepakete einschließlich unterschiedlicher Versionen der gleichen Software, Patches, Hotfixes, Betriebssystem-Updates etc. im Einsatz. Probleme beim Rollout neuer Applikationen sind somit geradezu programmiert.

Genau aus diesem Grund wird Qualitätssicherung beim Ausrollen neuer Softwarekomponenten immer wichtiger. Ein Beispiel: In einem Großunternehmen sollte eine verhältnismäßig kleine Applikation neu installiert werden, die automatisch einen Mail-Footer erzeugt - an sich eine relativ triviale Angelegenheit. Man hatte allerdings nicht bedacht, dass eine Bestellkomponente, die in den Vertriebsstellen eingesetzt wird, vom Mail-System als Kommunikationskomponente benutzt wird.

Verhängnisvolle Konflikte

Die neue Kombination ist zwar zuvor analysiert worden, aber es war nicht bekannt, dass die Bestellkomponente eine bestimmte Dynamic Link Library (DLL) aus dem MAPI-Interface nutzt, die jedoch durch die Mail-Footer-Applikation verändert wurde. Die Folge war, dass die Bestellkomponente eine Woche lang nicht funktionierte. Die durch den Ausfall entstandene materielle Einbuße ließ sich zwar ermitteln, nicht bezifferbar dagegen war der Imageschaden. Mit einer entsprechenden Analyse (oder einem Test) hätte man diese Abhängigkeit bereits im Vorfeld erkennen und beseitigen können. Ein weiteres Beispiel sind Börsenplätze oder international operierende Call-Center. Wenn dort Handelssysteme über Stunden nicht verfügbar sind, entstehen extreme finanzielle Schäden.

Vermeiden lassen sich solche Pannen nur durch wirksame Maßnahmen zur Qualitätssicherung im Vorfeld des Rollouts, also durch Untersuchungen, ob und wie Softwarepakete sich gegenseitig beeinflussen. Zu reduzieren beziehungsweise vermeiden sind derartige Konflikte durch das so genannte Glass Box Testing, bei dem zwischen statischer (White Box Testing) und dynamischer Analyse unterschieden wird.

Statische Analysen haben in jüngerer Vergangenheit zweifellos die Qualitätssicherung beim Rollout verbessert und die Kosten gesenkt. Bei dieser Technik wird in der Regel das Installationspaket analysiert, wobei man davon ausgeht, dass der Softwarehersteller das Standard-Installationspaketformat MSI von Microsoft verwendet. Dieses Format ist dokumentiert und offengelegt. Allerdings findet je nach Unternehmen nur bei etwa 75 bis 95 Prozent der erwähnten Softwarepakete das MSI-Format Verwendung. Fünf bis 25 Prozent der Installationspakete setzen Non-MSI-Installer ein.