© everythingpossible / 123RF.com

Altsysteme kranken an vielen und auf den ersten Blick unterschiedlichen Stellen. Die richtige Diagnose und passende Therapiemaßnahmen helfen ihnen wieder auf die Sprünge.

Wenn Teams auf der grünen Wiese mit einem Softwareprojekt beginnen, macht alles Spaß, und die Chose fällt leicht. Die Entwickler reagieren blitzschnell auf neue Anforderungen, die Anwender sind begeistert. Die Entwicklung geht in großen Schritten voran. Über die Lebenszeit des Systems hinweg wird sich das allerdings ändern, die Komplexität der Software erhöht sich unausweichlich. Das führt unweigerlich zu höherer Fehleranfälligkeit, immer langsamerem Fortschritt und schlechterer Wartbarkeit.

Das Ende vom Lied: Es braucht ein halbes Jahr, bis auch nur die kleinste Änderung in der Produktion ankommt. Die anfänglich blühende grüne Wiese hat sich in einen schlammigen, stinkenden Acker verwandelt. “Altsystem”, “Legacy-Software”, “Big Ball of Mud”, “Monolith” oder “Gummistiefelprojekt” lauten die wenig schmeichelhaften Namen, mit denen Teams diese Art von Systemen titulieren. Doch es gibt Hoffnung: Auch in die Jahre gekommenen Systemen können Sie Flexibilität, Fehlerrobustheit und Entwicklungsgeschwindigkeit zurückgeben. Die Kernaufgabe dabei besteht darin, die entstandene Komplexität zu beherrschen und aufzuteilen.

Softwaresysteme leiden unter unterschiedlichen “Krankheiten”, und Sie benötigen eine Vielzahl von Mitteln, um sämtliche zu heilen. Vier Malaisen konnten wir in verschiedenen Kombinationen bei Legacy-Systemen – egal, ob Monolithen oder Microservices – und ihren Organisationen beobachten.

Den Anfang macht der Big Ball of Mud: Mit der Zeit ist das Legacy-System zu einem solchen angeschwollen, weil niemand die Abhängigkeiten kontrolliert hat und nun alles mit allem verbunden ist. Daneben kann die Fachlichkeit in einem großen Domänenmodell miteinander verwoben sein, dessen Teile lediglich eingeschränkt zusammenpassen oder sich sogar widersprechen. Bei der dritten Krankheit haben sich der fachliche und der technische Quellcode miteinander vermengt. Angesichts dessen mutieren der Austausch von veralteter Technik oder eine fachliche Erweiterung zu einer Herkulesaufgabe. Außerdem kommt es vor, dass die Beteiligten in einer Teamstruktur stecken, die sich kaum für schnelles Vorankommen eignet oder es sogar gänzlich verhindert.

Innerhalb der letzten 20 Jahre konnten wir bei unserer Arbeit mit Domain-driven Design (DDD) und Legacy-Software einige Heilmittel gegen diese Krankheiten identifizieren: Refactorings, Domain Storytelling, Event Storming, Team Topologies und den Modularity Maturity Index (MMI). Wir kombinieren sie in einer Art Therapieplan, den wir als Domain-driven Transformation bezeichnen.

Wenn wir in unseren Projekten und mit unseren Kunden die Behandlung angehen, dann erreichen wir, dass das jeweilige Entwicklungsteam deutlich positiver in die Zukunft schaut und die Motivation steigt. Je weiter der Heilungsprozess voranschreitet, desto zufriedener zeigen sich Fachanwender, Projektleiter und Manager, da die schwergängige und teure Legacy-Software an Stabilität gewinnt, sich schneller anpassen lässt und letztlich sogar (wieder) innovative, zukunftsweisende Erweiterungen erlaubt.

Das Vorgehen auswählen

Grundsätzlich können Sie sich für die Transformation entweder vornehmen, das Legacy-System komplett zu ersetzen oder es als Basis zu behalten und lediglich umzuformen beziehungsweise zu refaktorieren. Beim Ersetzen gibt es die zwei Varianten Big Bang Replacement und schrittweises Ablösen. Ersteres bedeutet, auf der grünen Wiese ein komplett neues System zu bauen, während das Altsystem weiter im Einsatz bleibt. Zu einem bestimmten Zeitpunkt legen Sie den Schalter von der Altlast auf das neue System um.

Beim schrittweisen Ablösen eines Legacy-Systems entwickeln Sie das neue System scheibchenweise und nutzen jedes Teilstück so früh wie möglich produktiv. Gleichzeitig schalten Sie die entsprechende Funktionalität im Altsystem ab. Entscheiden Sie sich für den Weg des Umformens, passen Sie den Big Ball of Mud mithilfe von Refactorings an. Währenddessen bleibt er die ganze Zeit in Betrieb.

Zunächst nehmen wir die Vor- und Nachteile der verschiedenen Arten der Transformation unter die Lupe, damit Sie im Anschluss die für Sie passenden Entscheidungen treffen können. Abbildung 1 visualisiert die erste Variante des Ersetzens, das Big Bang Replacement.

Abbildung 1: Das alte System bleibt so lange (und ausschließlich) im Dienst, bis das neue System komplett steht (Pfeile 1 und 2). Erst dann steigen Sie in einem Rutsch um (Pfeil 3).

Die Strategie heißt Big Bang Replacement, da wie beim Urknall auf einen Schlag eine ganz neue Welt vorliegt. Unglücklicherweise trifft der Name auch deshalb ins Schwarze, weil es dabei unvermeidlich einen großen Knall gibt. Was in der Theorie gut klingt, nämlich das neue System neben dem alten hochzuziehen, funktioniert in der Praxis aus verschiedenen Gründen nicht: Im Altsystem versteckt sich viel unbekanntes Wissen, das beim Nachbau oft unter den Tisch fällt. Häufig fällt das Altsystem so groß aus, dass es sich nicht in einer kurzen Zeit nachbauen lässt. Das führt dazu, dass es nicht “einfrieren” kann und sich während des Nachbaus in eine sich bewegende Zielscheibe verwandelt.

An diesen Ausführungen merken Sie wahrscheinlich, dass wir nicht zu den Fans einer Big-Bang-Einführung gehören. Nach unserem Eindruck sind wir nicht die einzigen, die so auf das Ablösen von Legacy-Systemen sehen. Die kollektive Erfahrung der IT-Industrie zeigt, dass die zweite Herangehensweise – das Legacy-System Schritt für Schritt durch ein langsam wachsendes neues System zu ersetzen (Abbildung 2) – besser funktioniert als der Big Bang.

Abbildung 2: Bei einer schrittweisen Ablösung tauschen Sie langsam einzelne Komponenten, bis das Altsystem vollständig ersetzt ist.

Dabei schneiden Sie nach und nach Teile aus dem Altsystem heraus und platzieren sie in neuem Gewand neben der Legacy-Software. Die Anwender sehen sich nach kurzer Zeit direkt mit dem neuen System konfrontiert und arbeiten produktiv damit. Sobald die gewünschte Funktionalität im neuen System bereitsteht, schalten Sie das alte ab (Pfeil 4 in Abbildung 2). Vor nahezu zwei Jahrzehnten, im Jahr 2004, hat Martin Fowler diesem Vorgehen den sehr bildlichen Namen “Strangler Fig Application” gegeben [1]. Er hat diesen Namen gewählt, weil das alte System vom neuen System umschlungen und schließlich “erwürgt” wird, wie der Wirtsbaum von einer Würgefeige.

Diese Art des Modernisierens passt mit dem in der IT bevorzugten agilen Vorgehen zusammen, bei dem Sie von Iteration zu Iteration dazulernen. Das ermöglicht Ihnen, den weiteren Weg, den Sie beschreiten wollen, immer wieder auf Basis der jüngsten Erkenntnisse zu bewerten und zu justieren.

Viele Organisationen gehen davon aus, dass in ihr Altsystem sehr viel Know-how geflossen ist, das sie verständlicherweise in die Zukunft retten wollen. In diesem Fall sehen Sie besser davon ab, das Altsystem zu ersetzen. Stattdessen betreiben sie es die ganze Zeit weiter und bauen es Schritt für Schritt durch Refaktorierung um.

Strategische Transformation

Um eine Legacy-Software fachlich zu zerlegen, müssen Sie die aktuellen Arbeitsprozesse mit all ihren Workarounds erfassen und durchdenken. Anders formuliert liegt der Schlüssel zum Erfolg darin, die Domäne (wieder) zu verstehen. Es genügt also nicht, allein die Lösung zu betrachten, sprich den vorhandenen Quellcode. Stattdessen müssen Sie beim Problem ansetzen, also in der Fachdomäne, um ein über Jahre durch An- und Umbau verwobenes Softwaresystem zu entwirren und zu vereinfachen. Dabei sollten Sie sich mit zweierlei auseinandersetzen.

Zunächst müssen Sie den Monolithen und die darin vorhandene Struktur gedanklich beiseite legen und sich noch einmal grundlegend mit der Fachlichkeit beschäftigen, genauer gesagt der Aufteilung der Domäne in Subdomänen. Sie fangen also interessanterweise zumindest analytisch doch auf der grünen Wiese an, obwohl Sie schon ein System haben. Auf Basis dieses frischen Verständnisses der Fachdomäne können Sie die überflüssigen oder falsch verstandenen Anteile in der Softwarelösung identifizieren und aus- sowie umbauen.

Deswegen gilt sowohl für die Entwicklung von neuen Softwaresystemen als auch für die Zerlegung von Monolithen, dass die kritischen Tätigkeiten nicht nur das Schreiben von Code umfassen, sondern zuallererst das Lernen und Verstehen aller Stakeholder untereinander. Die Entwickler müssen lernen, was genau die Fachexperten in ihrer täglichen Arbeit tun. Auf der anderen Seite müssen die Fachexperten verstehen, welche technischen Gründe es für die Einschränkungen und die Priorisierung in den Lösungen gibt.

Die strategische Transformation lässt sich in vier Teilschritten beschreiben. Dazu gehören das Wiederentdecken der Fachdomäne, das Modellieren der fachlichen Soll-Architektur, das Abgleichen der Ist- mit der Soll-Architektur und das Priorisieren sowie Realisieren der Umbaumaßnahmen.

Soziotechnische Transformation

Um ein Legacy-System in einen besseren Zustand zu versetzen, müssen Sie mehr beachten als nur die technischen und fachlichen Dimensionen von Domain-driven Transformation. Häufig lohnt es sich, zusätzlich die Teamstrukturen und das Vorgehen zu überdenken.

Inzwischen hat sich erfreulicherweise in vielen Organisationen agiles Vorgehen gut etabliert. Falls das bei Ihnen noch nicht zutrifft, sollten Sie darüber nachdenken, denn agile Transition und Domain-driven Transformation gehen häufig Hand in Hand. Zudem bedeutet organisatorische Domain-driven Transformation oft, horizontal organisierte Teams (Abbildung 3) zu vertikal organisierten Arbeitsgruppen (Abbildung 4) weiterzuentwickeln.

Abbildung 3: Führt zu Abhängigkeit: Schichten mit horizontalen Teams.

Abbildung 4: Macht Unabhängigkeit möglich: Schichten mit funktionsübergreifenden Teams.

Wir verwenden im Folgenden den Begriff Refactoring in einem sehr weiten Sinn; alternative Bezeichnungen wären Reorganisation oder soziotechnische Transformation. Um Teams einen Anhaltspunkt zu geben, wie die geplanten Veränderungen ablaufen sollen, lassen sich einige soziotechnischen Refactorings beschreiben. Dazu gehört die Methode des Cross-Layer Refactorings [2], bei dem Sie ein funktionsübergreifendes Team aus den Mitgliedern der unterschiedlichen Fachgruppen (User Interface, Business-Logik, Datenbank etc.) bilden.

Beim Partly-Layer Refactoring [3] stellen Sie ein zweites funktionsübergreifendes Team aus Mitgliedern weiterer Fachgruppen und des ersten funktionsübergreifenden Teams zusammen. Während des Second-Team Refactorings [4] gehen Sie ähnlich vor, mit dem Unterschied, dass die bestehenden funktionsübergreifenden Teams ungestört weiterarbeiten, da sich niemand daraus an der neuen Arbeitsgruppe beteiligt. Außerdem können Sie so mehrere neue funktionsübergreifende Teams auf einmal schaffen.

Taktische Transformation

Bei der taktischen Transformation geht es darum, die Fachlichkeit in Ihrer Legacy-Software zu stärken. Selbstverständlich verbirgt sich in jedem Altsystem Fachwissen, es versteckt sich aber häufig unter viel Technik und ist uneinheitlich. Eine Reihe von Maßnahmen helfen dabei, die Fachlichkeit freizulegen [5].

Beginnen Sie damit, den fachlichen und den technischen Quellcode voneinander zu trennen. Daraufhin erhöhen Sie die Kohäsion, was bedeutet, dass Sie Ihre Modellierung fachlich anreichern, Value Objects [6] einsetzen, fachliche Vorbedingungen einführen und die fachliche Identität von Entitäten explizit machen. Gleichzeitig verringern Sie die Kopplung, indem Sie an Aggregatsgrenzen ID-Referenzen einführen, Vererbung im fachlichen Quellcode reduzieren und Domain Events zur Entkopplung verwenden. Schließlich dokumentieren Sie Ihre Architektur im Code und prüfen sie.

Fazit

Egal, ob Legacy-Systeme sich lediglich in einem schlechten Zustand befinden oder bereits als Wrack am Boden liegen: In ihnen schlummert ein fachlicher Schatz. In den meisten Fällen ist er wertvoll genug, um ihn aus dem Verborgenen wieder ans Licht zu holen, anstatt ihn durch eine Neuentwicklung zu ersetzen. Bei einer Neuentwicklung müssen Sie mit so viel Unbekanntem rechnen, dass der tatsächliche Aufwand die Schätzungen häufig um ein Vielfaches übersteigt.

Ein Legacy-System zu renovieren bedeutet wie die Neuentwicklung hohen Zeitaufwand. Mit Domain-driven Transformation lässt sich dieses Unterfangen in kleinen Schritten und damit risikoärmer umsetzen. Um den fachlichen Schatz in einem Legacy-System zu heben, müssen Sie die Teile im Quellcode identifizieren, die das wertvolle fachliche Wissen Ihrer Domäne enthalten.

Naturgemäß lässt sich über ein so großes Feld wie Softwarearchitektur jedoch nur ein grober Überblick geben. Mehr zum Thema von den beiden Autoren dieses Artikels finden Sie im Buch “Domain-driven Transformation” [7], das bei Dpunkt erschienen ist. (csi)