Software Migration 1: Rien ne va plus – Das Altsystem-Roulette

Der Begriff Obsoleszenz meint den Verschleiß oder die Alterung von Dingen, bis hin zur nicht mehr gegebenen Einsetzbarkeit. Im Bereich von Hardware ist das Thema schon lange bekannt, aber auch bei Software existieren Probleme aufgrund einer technischen Obsoleszenz. Die Migration von Altsystemen und Maßnahmen gegen Software-Erosion liegt im Erfahrungsbereich von SEKAS. Die hier beginnende Blog-Reihe berichtet über Einsichten und Erkenntnisse aus diesem Bereich.

Das erwartet Sie im folgenden Blog-Beitrag:

Die Grundproblematik der Obsoleszenz

Sätze wie “Hier sollte man mal aufräumen” oder “Das gehört eigentlich restrukturiert” haben Sie sicherlich schon öfters gehört (oder ausgesprochen), wenn Sie mit etwas betagten Softwaresystemen zu tun haben. Aber leider ist dann doch wieder etwas anderes dringend und oh, Budget haben wir gerade auch keins. Na schön, machen wir später, das System funktioniert ja noch.

Schicht für Schicht bildet sich damit ein Sediment, das immer schwerer zu durchdringen ist und Änderungen immer riskanter macht.

Aber Bits nutzen sich ja nicht ab, Software altert doch nicht, oder? Verblüffenderweise tut sie genau das, auch wenn man das System nicht mehr anfasst, sondern still vor sich hin arbeiten lässt.

In fast jedem System werden externe Komponenten wie Datenbanken, Middleware, Bibliotheken für Numerik, Grafik etc. verwendet und regelmäßig darin Sicherheitslücken oder in Grenzfällen auftretende Fehlfunktionen entdeckt und behoben. Auch die eigene IT-Abteilung schläft (hoffentlich) nicht, sondern prüft die vorhandenen Anwendungen regelmäßig mit den neuesten Hackertools auf Sicherheit und Robustheit, gelegentlich mit erschreckendem Erfolg.

Alte Anwendungen, die nicht mehr weiterentwickelt werden, strahlen also bestenfalls scheinbar Ruhe aus. In Wirklichkeit ist diese Ruhe nur temporär oder sogar trügerisch.

Ein erhöhtes Risiko bei Änderungen an Altsystemen

Sobald Hardware beteiligt ist, hat der Zahn der Zeit ohnehin genug Angriffsfläche, regelmäßig Unruhe zu schaffen. Die alten Rechner zeigen Ausfallerscheinungen, neue Rechner sind häufig nicht mehr mit einem alten Betriebssystem zu bekommen. Technische Systeme sind darüber hinaus von umgebender Elektronik abhängig, also von Subkomponenten und Geräten, deren Marktverfügbarkeit in der Regel auf ein Zeitfenster von wenigen Jahren beschränkt ist. Die Standzeit der Geräte ist damit wesentlich größer als die Marktverfügbarkeit, Geräteersatz ist deswegen praktisch immer mit Systemanpassungen verbunden. Leider zeigt die Erfahrung, dass auch als „kompatibel“ versprochene neue Geräte in der Regel „ziemlich kompatibel“ sind und eben doch Softwareänderungen erfordern.

Software Migration als Mittelweg zwischen Risiko und Kosten

Weil über das Innere von alten Anwendungen meist wenig bekannt ist, haben die Änderungen, die im Lauf der Zeit zwangsläufig nötig werden, durchaus den Charme eines Roulette-Spiels: Ob bei Änderungen das System stabil bleibt oder die Entwicklung am Ende des Budgets letztlich ein “rien ne va plus” signalisiert, wie weit die Kosten überhaupt planbar sind und ob der vorgesehene Termin gehalten werden kann, weiß man erst hinterher. Dumm nur, dass meist um hohe Summen gespielt wird und die Entwickler in der Zwischenzeit eigentlich ganz andere Aufgaben erledigen sollten.

Bleiben also, unter gehöriger Unsicherheit, die Handlungsalternativen “pflegen”, “neu bauen” oder “gezielt verfallen lassen”, die ganz klar von wirtschaftlichen Überlegungen geleitet werden.

Als sehr wirtschaftlich erweist sich in bestimmten Fällen ein Mittelweg zwischen Pflege und Neubau, nämlich die Migration eines Altsystems auf ein neues technisches Fundament.
Dabei wird in der Regel eine Mischung aus Handarbeit und spezialisierten Tools eingesetzt, um diese Software Migration zuverlässig, ressourcenschonend und wirtschaftlich durchzuführen.

Wie im Immobilienbereich ist das eine Kernsanierung, bei der nur langfristig werthaltige Teile aus dem Altbestand übernommen werden.

Zusammenfassend lässt sich sagen:

  • Softwaresysteme altern auch dann, wenn sie nicht mehr verändert werden, weil enthaltene Softwarekomponenten von Obsoleszenz betroffen werden.
  • Hardwarekomponenten in technischen Systemen sind stets von Obsoleszenz betroffen, die praktisch immer auch in die zugehörige Software hineinwirkt.
  • An realen Projekten hat sich gezeigt, dass Anpassungen von Altsystemen schwerer planbar und riskanter sind als Neuprojekte vergleichbarer Größenordnung, bis hin zum Scheitern des Vorhabens.
  • Um wieder eine zukunftsfähige Software zu erhalten, hat sich, als machbarer Mittelweg zwischen aufwendiger Pflege und den hohen Kosten eines Neubaus, die Migration durch Transformation eines Altsystems auf ein neues technisches Fundament unter Verwendung neuer Technologien erwiesen. Diese bettet die fachlichen Kerne des Altsystems in einen neuen, aktuellen Technologierahmen

 

Ein tieferer Blick in die Ursachen der Altsystemproblematik, sinnvolle Maßnahmen im Verlauf der Systempflege sowie Erfahrungen und Strategien aus den Migrationsprojekten bei SEKAS sind Gegenstand der künftigen Beiträge dieser Blog-Reihe.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Bitte beachte unsere Nutzungsrichtlinien

Mehr zu diesem Thema

Legacy Code in Altsystemen

Legacy Code in Altsystemen ist ein Thema, welches jeden softwareentwickelnden Bereich irgendwann mit Wucht trifft und zu einem Problem werden kann. Es gibt jedoch erprobte

Weiterlesen »
Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Weitere Informationen finden Sie in unserer Datenschutzerklärung.