"Monolithen sind Einfallsvektoren für Kopfmonopole"

Softwareentwicklungsprojekte in Konzernen müssen bereits vorhandene Systemarchitekturen berücksichtigen. Dabei stehen die Projektteams vor der Frage, wie die monolithischen Altsysteme erneuert werden können – vor allem wenn sie groß, inflexibel und schwergewichtig sind.

Bei genauer Betrachtung ergeben sich beim Umbau von Monolithen sowohl organisatorische als auch technische Herausforderungen. Wir sprechen darüber mit FSS-Geschäftsführer Mark Flemming und FSS-Softwarearchitekt Philipp Traue, die das Thema aus persönlicher Sicht bewerten.

Ihr beschäftigt euch schon seit längerem mit monolithischer Software. Warum?

Philipp Traue: Mein berufsbedingter Betrachtungsschwerpunkt sind Kernbankensysteme, die in der Vergangenheit an vielen Stellen ausgeweitet und abgesichert wurden. Klassische Alleskönner, die sämtliche Unternehmensprozesse in einem System abbilden, aber nur unzureichend die Gesamtbetrachtung oder gar eine verlustfreie Zerlegung einzelner Teilbereiche zulassen.

Es hatte seine Gründe, warum solch ein System serviceorientiert angelegt war. Allerdings bindet die Modernisierung dieser Architektur sehr viele zeitliche und finanzielle Ressourcen. Die technischen Veränderungen, die der Markt vorgibt, kommen wenig bis gar nicht zum Einsatz und wenn, dauert es seine Zeit bis zur Produktionsreife.

Mark Flemming: Wenn man darüber nachdenkt, wie die Funktionen in Monolithen umgesetzt werden, dann sind natürlich Zeit- und Kostendruck ganz wesentliche Elemente. Strategisch stellt sich auch die Frage, wie das Unternehmen im Voraus die Implementierung neuer Funktionen in seine IT-Architektur plant. Ich meine damit konkret die möglichen Konsequenzen, die sich aus einer mangelhaften Programmierung ergeben und den zusätzlichen Aufwand, der dadurch für zukünftige Änderungen anfällt.

Ist damit das Problem der technischen Schulden gemeint?

Philipp Traue: Ja, der Monolith ist immer das Erbe von früheren Architekturentscheidungen und die Systemgrenzen werden in den meisten Fällen von den Abhängigkeiten der Teilsysteme zueinander und ihren Schnittstellen bestimmt.

Und obwohl viele IT-Abteilungen der Überzeugung sind, dass sie ihre Schnittstellen sauber strukturiert haben, trifft man häufig auf Abhängigkeiten auf der Metaebene. Insofern sind die Sorgen durchaus berechtigt, denn Änderungen an einer Stelle des Monolithen könnten diesen Big Ball of Mud als Gesamtsystem beeinträchtigen und schlimmstenfalls destabilisieren.

Auch kleine und mittelgroße Softwaresysteme können übrigens ein Big Ball of Mud sein. Beispielsweise bieten Skriptsprachen die Möglichkeit, umfangreichere Funktionen mit weniger Code sehr schlank umzusetzen. Das bedeutet aber nicht, dass ein System mit weniger Code auch gleichzeitig übersichtlicher ist.

Mark Flemming: Ein Monolith ist eine komplexe Software mit vielen Komponenten, die sehr strukturiert aufgebaut ist und als Gesamtanwendung kompiliert wird. Es gibt sicherlich Grenzen bei den Klassen- oder Programmteilgrößen. Die aktuelle Struktur beinhaltet aber keine Pflicht weiterhin die einstigen Design-Entscheidungen beizubehalten. Monolithische Software kann trotz gewisser Einschränkungen das Zeitalter der digitalen Transformation aktiv begleiten.

Philipp Traue: Aus der technischen Perspektive betrachtet, geht es in vielen Fällen um die Frage, ob ein komplexes System mit all seinen Teilsystemen immer vollständig zu einem Releasetermin ausgerollt werden muss. Die Antwort darauf kann ein guter Indikator für die Zukunftsfähigkeit des Systems sein.

Welche Herausforderungen ergeben sich daraus?

Mark Flemming: Bei einem Monolithen kann es schwieriger sein, einen Gesamtüberblick zu behalten – häufig ist das Wissen über elementare Abhängigkeiten auf wenige Köpfe verteilt. Damit wird es schwer für Neulinge sich in einen Monolithen einzuarbeiten, weil sie zu wenig vom Gesamtcode übersehen, um bestimmte Kernfunktionen umzubauen. Schlecht strukturierte Monolithen verhindern ein schnelles Onboarding neuer Entwickler.

Philipp Traue: Jedes Unternehmen, welches grundsätzlich einen komplexen Softwareentwicklungsprozess hat, benötigt länger beim Onboarding. In aller Regel lassen sich bei Monolithen sehr einfach die Oberflächen umprogrammieren. Aber wenn es um das eigentliche Bestandsführungssystem, das Kundensystem, oder den administrativen Kern geht, gibt es oft nur wenige Entwickler, die das notwendige Wissen haben. Es ist ein klassischer Einfallsvektor für Kopfmonopole. Dies hat wiederum Auswirkungen auf die Unternehmenskultur. Mitarbeiter mit Kopfmonopolen sind für die Organisation dann unverzichtbar. Diese Tatsache beeinflusst ganz wesentlich die Zusammenstellung der Entwicklungs-Teams.

Mark Flemming: Wenn der große Softwareblock mit seinen vielen Komponenten gut strukturiert aufgebaut ist, dann muss ein Monolith nichts Schlechtes sein. Bei anstehenden Veränderungen stellen sich Fragen danach, wo das System verändert werden muss und an welchen Stellen bleiben die Funktionen unberührt.

Kein Monolith gleicht dem anderen. Wo muss die Veränderung ansetzen?

Mark Flemming: Die Gründe zur Veränderung des Monolithen bestehen vor allem in der größer werdenden Konkurrenz aus Big-Tech und Fin-Tech, den regulatorischen Vorgaben zur Öffnung und den Forderungen der Kunden nach einem zeitgemäßen Nutzererlebnis.

Ein großes Problem bei diesen Modellen in der Praxis ist, dass die Entwickler meist keine Übersicht darüber haben, wo sich die Datentöpfe befinden und wie die Datenflüsse ausgestaltet sind. Wer entscheidet eigentlich, wo welche Daten liegen? Wer besitzt die Information darüber, welche Daten in welcher Struktur wo abgelegt sind? Daten haben teilweise Abhängigkeiten, die der Dateninhaber gar nicht kennt.

Man muss beim Umbau also die verschiedenen Architekturebenen des Systems betrachten und bestimmen, ob es dabei eine Komponente, eine Domäne oder die gesamte Unternehmensarchitektur betrifft. Je nach Architekturebene existieren unterschiedliche Paradigmen, wie diese aufzubauen sind. Das Separieren von Informationen innerhalb des Monolithen ist die Voraussetzung dafür, später bestimmte Teile auszuschneiden.

Philipp Traue: Aus der Erfahrung ist zu sehen, dass man in der Vergangenheit schon oft Systeme technisch oder architekturell neugestaltet hat, bei der Entwicklung aber die alten Mindsets verwendet wurden. Das führte dazu, dass sich viele serviceorientierte Architekturen der Nullerjahre aus heutiger Sicht immer noch ein wenig wie Hostsysteme anfühlen.

Als seinerzeit die zentralisierten Großrechner über serviceorientierte Systeme verteilbarer wurden, ist das oft noch im Geiste der alten Umgebung geschehen. Wenn die gleiche Herangehensweise nun auf die aktuellen Monolithen angewendet wird, verschieben sich die grundsätzlichen Probleme wieder in die Zukunft.

Welche Lösungen bieten sich an?

Philipp Traue: Im Domain Driven Design beispielsweise löst man bestimmte Komponenten komplett aus dem Monolithen heraus. Ein solcher bounded context besitzt dann keine Abhängigkeiten zum Altsystem und verfügt über einen eigenen Systemcharakter. Dieser Umstand führt wiederum zu einer Reihe von potentiell neuen Konflikten.

Würde man die Geschäftsprozesse des Monolithen so aufgliedern, dass jeweils alle ihren bounded context bilden, wäre die Weiterentwicklung einer einzelnen Komponente unabhängig von allen anderen möglich. Man könnte sie darüber hinaus mit genau den Technologien modellieren, die zum Problem passen.

Mark Flemming: Der Vorteil der modularen Herangehensweise im Domänenmodell ist sicherlich, dass alles voneinander unabhängig ist. Einerseits könnte man die jeweiligen Teilbereiche des Monolithen in voneinander abgegrenzte Prozesse schneiden und zieht sich die Stammdaten weiter aus dem Altsystem. Oder man konzipiert ein komplett neues Kerndatenmodell und baut alle weiteren Domänen auf diesem Datensatz auf.

Auf der Enterprise-Ebene ist dieser lose Bezugsrahmen aber eher ungeeignet. Denn damit bleibt das Problem der serviceorientierten Architektur bestehen und alle anderen Domänen fragen wieder die Daten einer Zentraldomäne ab – mit allen Vor- und Nachteilen des Single Point of Truth und einer einzigen Stelle, an der alle Informationen zusammenlaufen.

Philipp Traue: Das aufzusetzende System muss zwischen den Ansätzen von Microservices und serviceorientierter Architektur bei der Transformation des Monolithen vermitteln. Für das Strukturieren von Abhängigkeiten mehrerer bounded contexts existiert schon die Idee der so genannten „Onion Architecture“. Das ließe sich auf Enterprise-Ebene weiterentwickeln zu einer Art „Nucleus Onion Architecture“ in der es eine kleine, fest definierte Anzahl an Kerndomänen gibt, die lediglich kontrolliert beeinflussbar sein dürfen.

Diese zentralen Services müssten hochverfügbar und über verschiedene Wege ansprechbar sein. Es sollte nur den rudimentären Teil des Domänenmodells abbilden, so dass lediglich die Stammdaten abgefragt und diese jeweils in der einzelnen Domäne um weitere Informationen angereichert werden.

So kann beispielsweise die Kreditabteilung die Kunden-Stammdaten in relationalen Tabellen speichern und den Prozess nur durchlaufen, wenn alle vorgegebenen Felder ausgefüllt wurden. Die Analytics-Abteilung könnte sich hingegen das Verhalten des Kunden in der Webfiliale anschauen, sämtliche Bewegungen unstrukturiert in einer Datenbank abspeichern und später mit maschinellen Algorithmen auswerten.

Vielen Dank fürs Gespräch!