Altsystem

Illustration eines Altsystems und der Probleme beim Umstieg auf neue Software

Der Begriff Altsystem, Legacy-System (englisch legacy system) oder im engeren Sinne Legacy-Code bezeichnet in der Informatik eine etablierte, historisch gewachsene Anwendung im Bereich der Unternehmenssoftware. Das englische Wort legacy („Erbschaft“) ist in diesem Kontext ein weitgehend wertfreier Fachbegriff. Er kann aber umgangssprachlich auch negativ im Sinne einer lästigen „Hinterlassenschaft“ oder „Altlast“ im übertragenen Sinne verwendet werden.

Theorie

In seinem IEEE-Artikel liefert Sebastian Rosenkranz (und andere) eine detaillierte empirischen Beschreibung über die Eigenschaften von Altsystemen, sowie einer Darstellung über die Ursachen, die zur Ausbildung von Altsystemen beitragen, und die Folgen, die mit dem Einsatz solch gealterter Informationssysteme einhergehen. Außerdem wird ein theoretisches Modell vorgeschlagen mit dem Altsysteme (englisch Legacy Information Systems) greifbar gemacht werden können.

Eine mögliche Kurzdefinitionen lieferte Michael C. Feathers:

„In the industry, legacy code is often used as a slang term for difficult-to-change code that we don’t understand. But over years of working with teams, helping them get past serious code problems, I’ve arrived at a different definition. To me, legacy code is simply code without tests.“

– Michael C. Feathers: Working Effectively with Legacy Code, 2004

„In der Branche wird Legacy-Code oft als umgangssprachlicher Begriff für schwer zu ändernden Code verwendet, den wir nicht verstehen. Aber im Laufe der Jahre, in denen ich mit Teams zusammengearbeitet und ihnen geholfen habe, ernsthafte Codeprobleme zu überwinden, bin ich zu einer anderen Definition gelangt. Für mich ist Legacy-Code einfach nur Programmcode ohne Tests.“

Weitere Definitionen zielen auf die Folgen für Entwickler ab, die mit dem Legacy-Code anvertraut wurden:

„Die Entwickler scheuen sich, den Code zu verändern oder zu erweitern („Never touch a running system“).“

Eigenschaften

Beispiele für Altsysteme innerhalb der Anwendungslandschaft eines Unternehmens könnten beispielsweise großrechnerbasierte Individualentwicklungen sein, die sich oft durch unzureichende Dokumentation, veraltete Betriebs- und Entwicklungsumgebungen, zahlreiche Schnittstellen und eine hohe Komplexität auszeichnen. Die dort anzutreffende zentrale Daten- und Funktionshaltung galt seit der Client/Server-Euphorie als überholt.

Solche Merkmale können der Grund dafür sein, dass sich die Ablösung solcher Systeme oft deutlich über ihr erwünschtes Lebensende hinauszieht. Sowohl in wirtschaftlichen Aufschwung- wie in Abschwungphasen wird oft repriorisiert, um die mit einer Ablösung verbundenen hohen Ausfallrisiken bzw. Umstellkosten zu umgehen. Der bloße Ersatz eines Legacy-Systems ist in der Regel nicht mit einem direkten Mehrwert, sondern meist nur mit der Einsparung von kalkulatorischen Kosten (Kosten für temporären oder dauerhaften Ausfall) oder Opportunitätskosten (entgangene Umsätze wegen begrenzter Leistungsfähigkeit des Legacy-Systems) verbunden.

Grundsätzliches Problem bei der Ablösung von Legacy-Systemen ist der gewachsene Funktionsumfang. Auch wenn recht häufig ein weiträumiger Ersatz durch mächtige Standardsoftware stattfindet, verbleiben meist nicht abgedeckte Zusatzfunktionen und Schnittstellen. Das sind oft Alleinstellungsmerkmale der gewachsenen und über Jahrzehnte entwickelten Software, über die Standardsoftware nicht unbedingt verfügt. Oft ist eine Runderneuerung der Systeme schon deshalb schwierig, weil sie über die Historie hinweg nicht konsistent beschrieben wurden, zum Beispiel mit Anforderungen, Anwendungsfällen usw.

Kompatibilität

Abgekündigte Schnittstellen werden oft für einen bestimmten Zeitraum weiterhin unterstützt, meist aber nicht mehr weiterentwickelt, damit alte Hard- und Software auch auf neuen Systemen weiterhin lauffähig bleibt. Ein Beispiel dafür ist das Unified Extensible Firmware Interface (kurz: UEFI), das ab ca. 2005 auf PCs die bisherige Firmware, das PC-BIOS, schrittweise abgelöst hat: ab ca. 2010 wurden zwar die meisten Computer mit UEFI ausgeliefert, dieses beinhaltete aber mit dem Compatibility Support Module (kurz: CSM, auf Deutsch in etwa Kompatibilitätsunterstützungsmodul) eine BIOS-Emulation, sodass sich ein UEFI-PC wie ein PC mit BIOS verhalten kann, wenn dies eine Erweiterungskarte oder das Betriebssystem (die Software) zum Betrieb benötigt. Dies war z. B. bei vielen Grafikkarten um 2010 noch notwendig, deren Video-BIOS („VBIOS“, die Firmware der Grafikkarte) ein BIOS voraussetzte, aber auch das verbreitetste PC-Betriebssystem, Windows von Microsoft, benötigte bis Windows XP grundsätzlich ein BIOS, und bis Windows 7 ein VBIOS (und damit auch im UEFI-Betriebsmodus ein geladenes CSM). Nach einer Übergangsphase wurde nach 2020 das CSM weggelassen – und damit die Altlast BIOS in Form der BIOS-Emulation, das daher auch oft als „Legacy BIOS“ bezeichnet wurde. Weil der Übergang der PC-Firmware vom BIOS zum UEFI ein fließender war, werden Funktionen der Firmware teilweise immer noch als „BIOS“ bezeichnet, wie etwa das „BIOS-Setup“ (das Einstellungsmenü der Firmware).

Auch Programmierschnittstellen (engl. Application Programming Interface, kurz API) werden meist als „Legacy-Schnittstellen“ bezeichnet, wenn diese nicht weiterentwickelt und durch modernere Schnittstellen ersetzt werden.

Umgang mit Legacy-Systemen

Der Einsatz serviceorientierter Architekturen bietet hier sinnvolle Ansätze, die Schnittstellenproblematik durch Einsatz von Konnektoren abzudecken. Dabei werden die auszutauschenden Systeme nach außen „gekapselt“, indem eine Zwischenschicht aus verschiedenen Quellsystemen eine gemeinsame Schnittstelle betreibt.

Siehe auch

• Brownfield (Softwareentwicklung)

Literatur

• Michael C. Feathers, Working Effectively with Legacy Code, 2009 (Effektives Arbeiten mit Legacy Code, 2010).