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. Gerade, wenn für eine aufwändige Neuentwicklung das Budget fehlt, sollten Unternehmen mögliche Szenarien prüfen, bei denen das Altsystem gerettet werden kann. Doch wie können Unternehmen entscheiden, welche Maßnahme für sie die richtige ist? Dieser Beitrag gibt Tipps aus dem Beratungsalltag des IT-Lösungsanbieters Giegerich & Partner, wie Unternehmen die Risiken ihrer Altsysteme abschätzen und eine gute informierte Entscheidung treffen können.

Erster Schritt: Identifikation von Altsystemen

Zunächst sollten Unternehmen frühzeitig prüfen, welche Systeme möglicherweise auf dem Weg sind, problematische Legacy-Anwendungen zu werden. Doch hier stellt sich oftmals die erste Frage: Welche Systeme sind eigentlich mit Altsystemen 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.

Doch 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: 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 den Fall.

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

Die Ablösung alter Systeme ist nicht der einzige Weg und vor allem nicht immer der attraktivste. In vielen Fällen helfen schon einfache Maßnahmen, um die Anwendung 5 oder sogar 10 Jahre weiter zu betreiben. 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:

1. 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.

2. 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.

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

4. Weiterentwicklung: Sofern der Aufwand vertretbar ist, kann die Software so weiterentwickelt werden, dass sie sich beispielsweise auch in einer neueren Software-Umgebung betreiben lässt.

5. Neuentwicklung: Erst wenn keine der ersten vier Optionen möglich ist, kommt das Unternehmen nicht um eine Neuentwicklung und 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 dient für Unternehmen als erste Orientierung, wie es in ihrem jeweiligen Einzelfall um die Systeme bestellt ist: Bitte sehen Sie das Bild
 
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“, so Tobias Krüger.

Es bleibt also festzuhalten: Das Neue ist nicht immer das Bessere. In vielen Fällen lohnt es sich, den Weiterbetrieb der Systeme in Betracht zu ziehen und ergebnisoffen prüfen zu lassen.