Altsystem

Illustration eines Altsystems und der Probleme beim Umstieg auf neue Software

Der BegriffAltsystem,Legacy-System(englischlegacy system) oder im engeren SinneLegacy-Codebezeichnet in derInformatikeine etablierte, historisch gewachsene Anwendung im Bereich derUnternehmenssoftware.Das englische Wortlegacy(„Erbschaft “) ist in diesem Kontext ein weitgehend wertfreierFachbegriff.Er kann aber umgangssprachlich auch negativ im Sinne einer lästigen „Hinterlassenschaft “oder „Altlast“im übertragenen Sinne verwendet werden.

Theorie

In seinemIEEE-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 (englischLegacy 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 ohneTests.“

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 beispielsweisegroßrechnerbasierteIndividualentwicklungen 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 derClient/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 vonkalkulatorischen Kosten(Kosten für temporären oder dauerhaften Ausfall) oderOpportunitä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ächtigeStandardsoftwarestattfindet, 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 dasUnified Extensible Firmware Interface(kurz: UEFI), das ab ca. 2005 aufPCsdie bisherige Firmware, dasPC-BIOS,schrittweise abgelöst hat: ab ca. 2010 wurden zwar die meisten Computer mit UEFI ausgeliefert, dieses beinhaltete aber mit demCompatibility Support Module(kurz: CSM, auf Deutsch in etwaKompatibilitätsunterstützungsmodul) eine BIOS-Emulation, sodass sich ein UEFI-PC wie ein PC mit BIOS verhalten kann, wenn dies eineErweiterungskarteoder das Betriebssystem (die Software) zum Betrieb benötigt. Dies war z. B. bei vielenGrafikkartenum 2010 noch notwendig, deren Video-BIOS („VBIOS “, dieFirmwareder Grafikkarte) ein BIOS voraussetzte, aber auch das verbreitetste PC-Betriebssystem,WindowsvonMicrosoft,benötigte bisWindows XPgrundsätzlich ein BIOS, und bisWindows 7ein VBIOS (und damit auch im UEFI-Betriebsmodus ein geladenes CSM). Nach einer Übergangsphase wurde nach 2020 das CSM weggelassen – und damit dieAltlastBIOS 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).

AuchProgrammierschnittstellen(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 Einsatzserviceorientierter Architekturenbietet 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).