Alter Code rostet nicht Legacy-Anwendungen: "retten" oder nicht?

Im IT-Bereich gibt es eine ausgeprägte Ex- und Hopp-Mentalität. Ältere IT-Systeme werden einfach über Bord gekippt, weil es etwas Neues und vermeintlich Besseres gibt. Dabei kann es durchaus sinnvoll sein, sogenannte Legacy-Systeme weiter zu betreiben.

Anbieter zum Thema

Parasoft® Deutschland GmbH

NetModule AG

Trebing & Himstedt Prozeßautomation GmbH & Co. KG

Giegerich & Partner GmbH

"Mobile first, Cloud first" - lautet der Werbeslogan eines großen Softwareanbieters, was letztlich die Aufforderung beinhaltet, bestehende Anwendungen in die Tonne zu treten. Aus Sicht eines IT-Lösungsanbieters nachvollziehbar: Schließlich ist es für ihn attraktiver und lukrativer, die "alten" Systeme durch neue zu ersetzen. Trotzdem sollte man als Nutzer hinterfragen, ob diese Vorgehensweise für die jeweilige Unternehmensanwendung wirklich den Königsweg darstellt.

Denn in der Regel gilt: Alter Code rostet nicht. Anstatt einer kostspieligen und zeitintensiven Neuentwicklung ist vielen Unternehmen oftmals nämlich mit "lebensverlängernden Maßnahmen“ mehr geholfen. Vor allem dann, wenn für eine Neuentwicklung das Budget fehlt, sollte man mögliche Szenarien prüfen, bei denen das Altsystem "gerettet" werden kann. Doch wie können Unternehmen entscheiden, welche Maßnahme im konkreten Fall die richtige ist? Das IT-Lösungshaus Giegerich & Partner hat dazu einige Tipps zusammengestellt.

Erster Schritt: Identifikation von Altsystemen

Zunächst ist zu prüfen, welche Systeme möglicherweise auf dem Weg sind, problematische Legacy-Anwendungen zu werden. Dabei taucht schon die nächste Frage auf: Welche Systeme sind damit gemeint? „Pauschale Antworten sind hier wirklich schwer, aber ein guter Richtwert sind 10 Jahre“, so Tobias Krüger, Leiter Softwareentwicklung bei Giegerich & Partner. „Das ist ähnlich wie bei einer Heizung. Die läuft in der Regel nach 10 Jahren noch ganz gut, aber hier und da zeigen sich erste Verschleißschäden. Bevor es dann zum Totalausfall kommt, sollte also eine Lösung her: reparieren oder erneuern“, so Krüger weiter.

Aber nicht nur das Alter eines Systems spielt eine Rolle, sondern beispielsweise auch, ob das entsprechende Softwareunternehmen noch existiert oder ob der verantwortliche Programmierer noch verfügbar ist. Ist das nicht der Fall, lässt sich bei auftretenden Problemen möglicherweise keine schnelle Lösung auf Basis des Altsystems finden. Relevant ist außerdem, ob ein Wartungsvertrag abgeschlossen wurde, der möglicherweise die genannten Risiken abfängt.

Zweiter Schritt: Risikobewertung von Altsystemen

Ob und wann Handlungsbedarf besteht, hängt davon ab, welche Relevanz und Funktion die Anwendung im Unternehmen hat und welche Risiken damit einhergehen: ein Totalausfall oder nur eine leichte Störung des Systems?

„Im Falle eines Fünf-Sterne-Hotels im Großraum Berlin drohte ein Rechner zu versagen, auf dem die Software für die Kartenkodierung des Schließsystems lief. Im Ernstfall hätte das bedeutet, dass die Gäste schlagartig nicht mehr in ihre Hotelzimmer gekommen wären. Da liegt der Handlungsbedarf natürlich eher auf der Hand, als wenn nur die Welcome-Anzeige in der Lobby betroffen gewesen wäre“, erläutert Tobias Krüger.

Dritter Schritt: Planung zur Rettung oder Ablösung von Altsystemen

Die Ablösung alter Systeme ist nicht der einzige Weg und schon gar nicht immer der sinnvollste. In vielen Fällen helfen bereits einfache Maßnahmen, um die Anwendung weitere oder sogar zehn Jahre betreiben zu können. Dies sollte nach der Identifikation drohender Altsysteme für jeden Einzelfall geplant werden. Die folgenden fünf Optionen bilden hierbei die gängigsten Lösungsmöglichkeiten ab:

• Duplizieren des Systems (Hard- und/oder Software): Damit steht das System im Notfall zur Verfügung. Handelt es sich beispielsweise um veraltete, nicht mehr im Handel verfügbare Hardware, bei der ein Ausfalls droht, kann schon ein Kauf auf Ebay Abhilfe schaffen.

• Betrieb auf einer virtuellen Maschine: Möglicherweise kann die Anwendung auf einem neueren Rechner mit Hilfe einer virtuellen Maschine, die die alte Software-Umgebung simuliert, weiter betrieben werden. So geschehen beim oben genannten Hotel-Beispiel. Hier konnte über eine Virtualisierung des Betriebssystems OS2 innerhalb von zwei Wochen das Problem behoben werden.

• ystemumzug: Eine weitere Möglichkeit ist es, die Anwendung zu portieren und nach entsprechender Anpassung auf einer neuen Plattform zu betreiben.

• Weiterentwicklung: Sofern der Aufwand vertretbar ist, kann die Software so weiterentwickelt werden, sodass sie sich auch in einer jüngeren Software-Umgebung betreiben lässt.

• Neuentwicklung: Erst wenn keine der ersten vier Optionen möglich ist, kommt das Unternehmen nicht um die Ablösung des alten Systems herum.

In den meisten Fällen gilt die Faustregel, dass die Anpassung günstiger und schneller umsetzbar ist – und auch weniger Bugs enthält, als eine neu programmierte Lösung. Welche Option sinnvoll und überhaupt möglich ist, hängt an vielen kleinen Faktoren – teilweise mit KO-Kriterium. Hierzu gehört beispielsweise die Frage, ob der Quellcode der Anwendung vorliegt. Der folgende Entscheidungsbaum kann als erste Orientierung dienen, wie es im Unternehmen um die Systeme bestellt ist.

Vierter Schritt: Lösung umsetzen

Wie die Lösung im Einzelfall umgesetzt wird, hängt von der Expertise des Dienstleisters und von der genauen Situation ab. Voraussetzung für eine Lösung, die eben nicht nur auf den Austausch von alt gegen neu setzt, ist, dass entsprechendes Wissen sowohl über die neuen als auch über die alten Systeme vorhanden ist. „Hier braucht man dann in der Regel die alten Hasen, die sich auch mit Altsystemen noch so gut auskennen, dass sie die Anwendung auf einem neuen System zum Laufen bringen. Bei einem Kunden, dessen Kerngeschäft die Datenanalyse im Gesundheitswesen ist, gab es massive Problem mit der Datenbank -also mit dem Herzstück des Geschäftsmodells. Als der Entwickler des Flickenteppichs aus diversen Systemen nicht mehr greifbar war, konnten wir mit Hilfe meiner Erfahrung mit Microsoft Foundation Classes den Quellcode einer selbstgebauten Datenbank analysieren und damit ein Re-Engineering möglichen machen“, weiß Tobias Krüger.

(ID:44726057)