Eine Beobachtung der existierenden IT-Systeme in Unternehmen zeigt, dass diese häufig eine heterogene Landschaft bilden und historisch gewachsen sind. Aus Kostengründen werden bestehende Systeme nicht immer rechtzeitig reformiert oder ersetzt. Die Software-Migration hat die Überführung eines Systems in eine veränderte Umgebung zum Gegenstand. Im Unterschied zur klassischen Neuentwicklung existiert ein System, das bereits die gewünschten fachlichen Anforderungen erfüllt. Durch den schnellen technologischen Wandel ist die zu migrierende Software zu einem Altsystem geworden und hemmt Unternehmensprozesse. Da die Funktionalität nicht neu entwickelt werden muss, ist die Software-Migration oftmals eine kostengünstigere und risikoärmere Alternative zur Neuentwicklung. Damit beginnt das Projekt allerdings nicht auf der grünen Wiese , sondern wird durch Eigenschaften des Altsystems (auch negativ) beeinflusst. Die Durchführung der Migration erfordert Ressourcen, für deren Beschaffung und Verwendung Aufwand entsteht. In diesem Buch werden Typen von Migrationen unterschieden und ein Scoring-Modell entwickelt, dass die Aufwandsabschätzung von Migrationen ermöglicht.

Textprobe: Kapitel 3, Typen von Migrationsvorhaben: GIMNICH UND WINTER unterscheiden drei Typen der Software-Migration (2005, S. 22). Die Migration der Laufzeitumgebung behandelt Veränderungen der Systemsoftware (z. B. Betriebssystem oder Datenbankmanagement-Systeme). Umstellungen der Systemstruktur werden unter dem Begriff der Architektur-Migration gefasst (z. B. von monolithischen Systemen zu Mehr-Schichten-Architekturen). Eine Migration der Entwicklungsumgebung liegt vor, wenn sich die Programmierumgebung ändert (z. B. Wechsel von C/C++ auf Java [Martin 2009]). Diese Typisierung legt ein enges Begriffsverständnis von Software-Migration zu Grunde, bei dem die tatsächliche technische Realisierung im Vordergrund steht. Das Gesamtspektrum der Software-Migration kann durch die Dreiteilung nicht adäquat abgebildet werden. Im Folgenden wird daher zunächst eine Merkmalsuntersuchung vorgenommen, um Charakteristika zu identifizieren und um einen umfassenden Blick auf Software-Migrationsvorhaben geben zu können. Wie bereits in vorangehenden Kapiteln wird unter Software-Migration ein Projekt verstanden (s. Kapitel 2). 3.1, Anforderungen an die Typisierung: Die Untersuchung wesentlicher Kriterien soll dabei helfen, kennzeichnende Eigenschaften zur Differenzierung zu bestimmen. In der Summe aller Merkmalsausprägungen ergibt sich ein Gesamtbild eines Software-Migrationsvorhabens, das sich von anderen unterscheidet. Durch die Einbettung in ein Projekt ergeben sich unabhängig von der Tatsache, dass es sich um Software-Migration handelt, erste Unterscheidungskriterien (s. Kapitel 3.2). Der Blick in das Projekt offenbart migrationsspezifische Charakteristika, die eine formale Differenzierung, auch bei gleichen Eigenschaften der Projektgröße aus Kapitel 3.2, erlaubt. Für die angestrebte Typisierung lassen sich folgende Anforderungen postulieren: Universalität: Beliebige Migrationsprojekte sollen anhand der Kriterien typisiert werden können. Das heißt jedes Kriterium ist auf jegliche Vorhaben anwendbar. Vollständigkeit: In Kombination aller Kriterien ergibt sich ein Gesamtüberblick über das Vorhaben. Ferner ist die Menge der Kriterien ausreichend, um unterschiedliche Migrationstypen auch unterschiedlich zu typisieren. Unabhängigkeit: Die Kriterien sind untereinander überschneidungsfrei und unabhängig. Das heißt eine Belegung einer bestimmen Ausprägung eines Kriteriums führt nicht zwangsläufig zu bestimmten Ausprägungen anderer Kriterien. Auswählbarkeit: Die Ausprägungsvorgaben sind vollständig, das heißt für ein bestimmtes Projekt kann für jedes Kriterium mindestens eine Ausprägung gewählt werden. Eine Mehrfachauswahl ist möglich. Die beschriebenen Anforderungen sind notwendig, um eine hohe Qualität und Brauchbarkeit der Typisierung von Software-Migrationsvorhaben sicherzustellen. Die Zielerreichung ist dadurch kontrollierbar und bewertbar. 3.2, Typisierung nach Projektgröße: Diese Kategorie umfasst die Kriterien Budget, Team und Projektdauer, deren Ausprägungen zur Unterscheidung von Projekten dienen können. Sie sind universell für alle Projekte beobachtbar und können als Maß für die Projektgröße dienen. 3.2.1, Budget: Das Projektbudget ist die ‘Summe der einem Projekt zur Verfügung gestellten finanziellen Mittel’ (Jenny 2001, S. 276). Abhängig von der Projektkostenrechnung sind alle Aufwände abgedeckt (d. h. Personalkosten, Sachkosten usw.) oder nur reine Sachkosten, als Mittel für projektspezifische Beschaffungen (Angermeier 2005, S. 309). Die Ermittlung der Höhe des Projektbudgets ist Teil der Projektplanung und entscheidet über Qualität und Umfang der Ressourcen (s. Kapitel 2.3). Im Mittelpunkt muss eine Wirtschaftlichkeitsanalyse stehen, die Nutzen und Kosten gegenüberstellt (Gaulke 2004, S. 115). Insbesondere bei Sekundärnutzen (z. B. Imageverbesserung in Prestigeprojekten) stellt die quantitative Erfassung jedoch eine nicht triviale Aufgabe dar und erschwert die Budgetplanung. Grundsätzlich sind zwei Ansätze zur Bestimmung der Höhe des Projektbudgets möglich (Wegmann und Winklbauer 2006, S. 125ff.). Bei der Top-Down-Vorgabe wird das Budget durch den Auftraggeber determiniert. Er bestimmt, in welcher Höhe er finanzielle Mittel bereitstellt ohne einzelne Arbeitsschritte im Detail zu kennen. Es erfolgt eine grobe Abschätzung, welcher monetäre Wert für den zu erwartenden Nutzen als angemessen erachtet wird. Bei zu knapper Vorgabe steht das Management vor der Herausforderung, die Migrationsziele unter Berücksichtigung des limitierten Budgets erreichen zu müssen. Die Einschränkung hat Auswirkungen auf die Ressourcenplanung. Im Rahmen einer Bottom-Up-Analyse wird das Projektbudget durch den Aufwand der durchzuführenden Aufgaben entwickelt. Dazu muss eine Kostenbewertung einzelner Arbeitspakete erfolgen, dessen Ergebnisse zum Gesamtvolumen summiert wird. Ausgangspunkt kann der Netzplan sein, der Tätigkeiten in Arbeitspakete zusammenfasst. WEGMANN UND WINKLBAUER ziehen das Bottom-Up Vorgehen der Top-Down-Vorgabe vor, da sichergestellt wird, dass die geplanten Aufgaben auch tatsächlich mit dem Budget durchgeführt werden können (2006, S. 126). Zudem wird eine Kostenkontrolle während des Projekts erleichtert, indem nach Fertigstellung eines Arbeitspakets ein Vergleich mit dem verbrauchten Budget stattfinden kann. Offensichtlich ist der zweite Ansatz mit höherem Aufwand verbunden, da im Gegensatz zur groben Gesamtschätzung, eine Detailplanung stattfinden muss. Eine vorangehende Rahmenschätzung kann daher sinnvoll sein, um entscheiden zu können, ob das Projekt grundsätzlich eine Chance hat, in der angedachten Art und Weise erfolgreich umgesetzt zu werden. Fällt die Entscheidung positiv aus, kann anschließend die Bottom-Up-Analyse erfolgen. Wenn das ermittelte Budget unterhalb der Vorgabe liegt, kann das Projekt gestartet werden.

• Software-Migration

• Migrationsprojekt

• System-Migration

• Altsystem

• IT-Migration

• IT-System