Jede Anwenderumgebung verhält sich anders

Migrations- und Integrationsprojekte (MIP) sind deshalb so schwierig, weil sie von lokalen Integratoren durchgeführt werden, die nur beschränkte Produkte- und Engineeringwissen haben können. Sie nehmen Produkte aus dem eigenen Konzern oder von Drittanbieteren und integrieren diese in den Umgebungen der Auftraggeber. Da die Produkte proprietär sind, kann der Integrator von den Produkteinternals nur beschränkt Kenntnisse haben. Damit fehlen ihm fast sämtliche Hebeln.

Wenn das Produkteverhalten nicht den Erwartungen entspricht, kann häufig nur der Hersteller sagen, ob es sich um einen Produktefehler oder um einen Installations- oder Bedienungsfehler handelt. Da aber die Experten beim Hersteller ebenfalls rar sind, kann das Projekt unter Umständen lange warten, bis schlüssige Informationen vorliegen. Der lokale Integrator ist jedoch der Geschäftspartner des Kunden, so dass sich dieser nicht interessiert, ob der Hersteller Zeit und Lust hat, das Projekt zu supporten. Nicht selten führt dieser Umstand zur völligen Erosion der Marge des Integrators.

Gibt es das nur in der IT? Auch im Bauwesen sind Integratoren am Werk. Ein Fensterlieferant oder ein Bauschlosser müssen Teilgewerke in einem Hauptgewerk intergrieren. Auch sie haben die Produkte vielleicht nicht selber gemacht, sondern von einem Lieferanten eingekauft und an die projektspezifischen Gegebenheiten angepasst. Dabei könnte es sich durchaus auch zeigen, dass die Produkte Mängel haben, die eine Integration an Hauptgewerk beinahe verunmöglichen. Aber ein grosser Unterschied besteht gegenüber der IT. Die Subsysteme im Bauwesen sind statisch, während sie in der IT ein Laufzeitverhalten aufweisen, das Unbestimmtheit über die eigentliche Installation hinaus mit sich bringt.
Neue Subsysteme verhalten sich fast immer instabil bei der Integration in spezielle Kundenumgebungen, auch wenn sie die Entwicklungstests (Factory Acceptance Tests) bestanden haben. Aber jede Kundenumgebung ist anders. Die Firma mValet hat 2007 eine Umfrage unter 10 der Fortune 500 IT-Anwendern durchgeführt, um tieferen Einblick in die versteckten Kosten von Migrationsprojekten zu erhalten.

Fazit:

Frequent inconsistencies and errors in so-called „environmental variables“ – applications that work in development experience difficulties when promoted into QA or other pre-production phases owing primarily to environmental differences (e.g., configuration settings of application infrastructure components being out of sync)¹.

Die vielen Fehler und Instabilitäten, die während der Integration auftauchen, verlangen eine minutiöse Analyse und Reproduktion im Labor des Integrators. Er muss die Fehler genau dokumentieren, bevor er sie an den Hersteller oder ins Entwicklungscenter weiter geben kann. Ohne detaillierte Dokumentation des Fehlers, hören die Entwickler gar nicht erst zu. mValet schreibt dazu:

High change rates for applications in pre-production phases – these changes contribute to system instability and extended troubleshooting efforts which result in scheduling delays. Extensive analysis that wastes hours and days of IT staff time is required to diagnose and remediate the configuration setting differences that cause this issue¹.

mValet errechnete, dass die Migrationsprojekte pro befragtem Unternehmen einen Anteil an den direkten Lohnkosten von zwischen 500 und 800 Tausend Dollars jährlich verschlingt. Eigentlich unverständlich, warum sich die Literatur vor allem auf Entwicklungsprojekte fokussiert, wo doch MIP viel mehr Unbestimmtheit aufweisen!

¹mValet. Large Application Migration Projects Consume Significant and Consistent Hidden Costs. Business Wire 2007-12-12