Legacy System – Fachlichkeit begraben im Sourcecode

Egal, ob in der Finanzbranche, im Versicherungswesen oder im Telekommunikationssektor, überall findest du Software mit einer langen Lebensdauer und einem hohen Anteil an Fachlichkeit. Diese Kombination im Legacy System kann zu Problemen führen, die du am besten gleich beim Entstehen einer Software bedenkst. Spätestens aber nach einigen Jahren werden diese Probleme nach Aufmerksamkeit schreien. Aber welche sind das eigentlich genau? Und was kannst du dagegen unternehmen?

Zunächst einmal zwei Begriffserklärungen:

1. Fachlicher Code implementiert das unternehmerisch wichtige Wissen. Im Finanzbereich zum Beispiel sind die Regeln zur Risikobewertung von Krediten fachlicher Code.
2. Technischer Code setzt den fachlichen Code auf der gegebenen Plattform um. Das Persistieren von Risikobewertungen bestimmter Kunden in einer Datenbank ist ein Beispiel für technischen Code.

Die Lebensdauer dieser zwei verschiedenen Arten von Code ist sehr unterschiedlich.

Technische Gegebenheiten ändern sich schnell

Vom Großrechner auf den Client, weiter über die eigene Serverfarm bis in die Cloud. Von Smalltalk über Java nach Kotlin. Von SQL über Hibernate nach Mongo. Die Techniken ändern sich ständig, und du kannst dich nicht jedem technischen Wandel widersetzen.

Dahingegen ist der fachliche Code relativ stabil

Das Wissen des Unternehmens mag sich erweitern und Stück für Stück verändern. Komplett von vorne wirst du aber kaum beginnen. Hier eine neue gesetzliche Vorgabe, dort eine Erweiterung vorhandener Regeln, aber alles über den Haufen werfen wirst du nicht. Insbesondere wenn es sich um Wissen handelt, welches vor 15 Jahren von Mitarbeitern kodiert wurde, die vielleicht gar nicht mehr im Unternehmen sind, ist die Arbeit, dieses Wissen aus dem Code zurückzugewinnen, bestenfalls schwierig.

Häufiges Problem – Vermischung von fachlichen und technischen Code

Ein Problem entsteht offensichtlich dann, wenn diese zwei Arten von Code vermischt werden. Findet eine saubere Trennung von Fachlichkeit und Technik nicht statt, dann führen die unterschiedlichen Anforderungen an die Lebensdauer für fachlichen und technischen Code zu ernsten Konsequenzen.

Ist die Software erst einmal einige Jahre auf diese Weise gewachsen, kannst du technischen Veränderungen nur noch auf zwei Arten begegnen:

1. Technische Veränderungen nicht oder nur sehr langsam umsetzen

   Der erste Weg ist zunächst der einfachere, da er zu geringen Kosten im Hier und Jetzt führt. Allerdings löst du das Problem damit nicht, sondern schiebst es lediglich vor dir her. Außerdem setzt du so nicht nur die jetzigen technischen Anpassungen nicht um, sondern gehst auch zukünftige technische Schritte nicht mit. Letzten Endes gehst du das Risiko ein, von jüngeren, technisch besser aufgestellten Mitbewerbern überholt zu werden.

2. Den gesamten technischen und fachlichen Code modernisieren

   Der zweite Weg ist meist mit extrem hohen Kosten verbunden. Eine komplette Migration eines großen Softwaresystems kann sich über Jahre hinziehen, Jahre, in denen sich sowohl die Technik als auch die Anforderungen des Marktes weiter ändern, wodurch sich die Migration noch mehr verzögert. Ein unternehmerischer Albtraum!

Wie kannst du diesem Problem begegnen?

Wenn du ein neues System entwickelst, ist die Antwort einfach: Trenne fachlichen und technischen Code. Erlaube unter gar keinen Umständen eine Vermischung von Technik und Fachlogik! Sehr gut dafür geeignet ist ein modellbasierter Ansatz, bei dem du die Fachlogik modellierst und das Tool aus dem Modell heraus den technischen Code generiert. Auf diese Weise ist es über eine Veränderung des Generators später leichter möglich auf technische Veränderungen zu reagieren.

Ob du dabei vorwiegend textuelle DSLs (Xtext) oder grafische DSLs (MPS) einsetzt, hängt von vielen Faktoren ab. Ob beispielsweise Fachanwender Code schreiben sollen, ist dabei genauso relevant wie die Erfahrung der verfügbaren Entwickler oder lizenztechnische Überlegungen.

Für ein großes, gewachsenes System ist die Antwort ungleich schwieriger. Was auch immer du tust, es werden hohe Kosten entstehen. Die wichtigste Maßgabe muss hier sein, die Kosten nicht zweimal entstehen zu lassen.

Wenn du den Code großflächig migrierst oder sogar inkrementell neu schreibst, dann muss eines der Kernziele sein, diese hohen Kosten nicht in Zukunft erneut entstehen zu lassen. Auch hier solltest du also darauf hinarbeiten, die Fachlogik aus dem technischen Code zu befreien und idealerweise in einem Modell abzubilden. Aus diesem Modell kannst du dann wiederum technischen Code für die neue Zielplattform generieren. Wie du dieses Modell aus dem vorhandenen Quellcode gewinnst, manuell, teil- oder vollautomatisiert, hängt sehr stark von der vorhandenen Codebasis ab, also vom Einzelfall.

Ob eine teilautomatisierte Migration deines Legacy Systems Sinn macht, erfährst du in unserem Blogartikel “Kann die Modernisierung deines Legacy Systems automatisiert werden?”.

Bist du in einer ähnlichen Lage? Schreib mir deine Erfahrung in die Kommentare.