Altsystem
Der Begriff Altsystem oder Legacy-System (englisch legacy system) und im engeren Sinne Legacy-Code bezeichnen in der Informatik eine etablierte, historisch gewachsene Anwendung im Bereich 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
Eine mögliche Kurzdefinitionen lieferte Michael C. Feathers:[1]
„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.“
Weitere Definitionen zielen auf die Folgen für Entwickler ab, die mit dem Legacy-Code anvertraut wurden:[2][3]
„Die Entwickler scheuen sich, den Code zu verändern oder zu erweitern („Never touch a running system“).“
Eigenschaften
Innerhalb der Anwendungslandschaft eines Unternehmens sind es beispielsweise großrechnerbasierte Individualentwicklungen, die sich oft durch unzureichende Dokumentation, veraltete Betriebs- und Entwicklungsumgebungen, zahlreiche Schnittstellen und hohe Komplexität auszeichnen. Die dort anzutreffende zentrale Daten- und Funktionshaltung galt seit der Client/Server-Euphorie als überholt.
Diese Merkmale sind der Grund dafür, dass sich die Ablösung solcher Systeme oft deutlich über ein 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 ist. Ein Beispiel dafür ist das
(kurz: UEFI), das ca. ab 2005 auf PCs die bisherige Firmware, das BIOS, schrittweise abgelöst hat: ab ca. 2010 wurden zwar die meisten Computer mit UEFI ausgeliefert, dieses beinhaltete aber mit dem
(dt. Kompatibilitätsunterstützungsmodul) eine BIOS-Emulation, sodass sich ein UEFI-PC wie ein PC mit BIOS verhalten kann, wenn die Software ein BIOS voraussetzt. Dies war z. B. bei vielen Grafikkarten vor ca. 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 ein BIOS. Nach einer Übergangsphase wurde nach 2020 das CSM und damit die BIOS-Emulation, das auch oft als „Legacy BIOS“ bezeichnet wurde, weggelassen. Weil der Übergang der PC-Firmware vom BIOS zum UEFI ein fließender war, werden Funktionen der Firmware teilweise immer noch mit „BIOS“ bezeichnet, wie etwa das „BIOS-Setup“ (das Einstellungsmenü der Firmware). Auch Programmierschnittstellen (engl.
, 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
Literatur
- Michael C. Feathers, Working Effectively with Legacy Code, 2009 (Effektives Arbeiten mit Legacy Code, 2010).
Einzelnachweise
- ↑ Michael C. Feathers: „Working Effectively with Legacy Code“ (englisch)
- ↑ Lars Jacobi - „Alptraum Legacy Code - Wie gehen Profis damit um?“
- ↑ Dylan Beattie - YouTube: Ctrl-Alt-Del: Learning to Love Legacy Code (englisch), Vortrag Februar 2019, Uploaddatum weicht ab
