Wir wollen unsere monolithische Legacy-Anwendung langfristig in eigenständig lauffähige Teile zerlegen. Doch das ist leichter gesagt als getan. Natürlich gibt es konkurrierende Ziele und Projekte. Aber irgendwo muss man anfangen. Ich möchte Euch kurz anhand eines konkreten Beispiels zeigen, wie wir hier vorgehen.

Motivation

Wir bauen seit ca. 20 Jahren unsere Software lifestream für die WWK. Es enthält verschiedene fachliche Module, z. B. für die Vertragsverwaltung, für den Zahlungsverkehr, die Briefschreibung und so weiter. Wir haben vor längerer Zeit schon grundsätzlich an Modularisierung gearbeitet und können bei lifestream von einem strukturierten Monolith (Modulith) sprechen. Von einer weiteren Zerlegung in fachlich möglichst gut abgegrenzte Anwendungen (Self Contained Systems) versprechen wir uns eine Reihe von Vorteilen. Zum einen sind Modernisierungsmaßnahmen für das Gesamtsystem immer nur mit einer großen Kraftanstrengung möglich. Zum anderen schränkt es auch unsere Agilität ein, da Teams nicht vollständig für ihr System verantwortlich sein können und es viele gemeinsam genutzte Komponenten und Prozesse gibt.

Muss das jetzt sein?

Doch wie verschafft man sich Raum für Modernisierung? Es gibt im Tages- und Projektgeschäft meist eine Fülle an Aufträgen, die die vorhandenen Kapazitäten binden. Wir haben es zwar mittlerweile geschafft, dass auch auf Management-Ebene Modernisierung als relevant und wichtig angesehen wird. Aber sobald ein konkretes Vorhaben angestoßen wird, kommen (zu Recht) Fragen auf:

  • Was soll da gemacht werden?
  • Warum ist das gerade jetzt nötig?
  • Sind nicht andere Themen im Moment wichtiger?

Modernisierungsthemen sind oft nicht dringend, aber wichtig. Das heißt, es ist einfach, kurzfristig andere Themen vorzuziehen. Es muss gelingen, den Mehrwert der Modernisierung möglichst gut greifbar zu machen. Darüber hinaus ist es entscheidend, diesen Mehrwert nicht nur aus IT-Sicht darzustellen, sondern insbesondere auch aus Business-Sicht auf das Thema zu schauen. Je mehr es gelingt darzustellen, dass man nicht nur reine IT-Probleme löst, desto höher sind die Chancen, eine entsprechende Investition tätigen zu können.

Unser Modul für die Briefschreibung soll auch von anderen Systemen genutzt werden können. Das geht natürlich, wir bieten entsprechende REST-Services an, die von diesen Systemen eingebunden werden können. Aber wenn die Briefbeschreibung im Monolith bleibt, haben wir nun auch die Agilität der anderen Systeme und Beteiligten eingeschränkt. Wir liefern momentan 6 Releases im Jahr. Das heißt, wenn andere Systeme Anforderungen an die Briefschreibung haben, müssen sie sich diesem Takt beugen. Die Briefschreibung als Einzelsystem könnte natürlich viel häufiger ausgeliefert werden. Das gilt für den gesamten Monolith nicht. Aufgrund der vielen Beteiligten und der aufwendigen Prozesse sind mehr Releases für das Gesamtsystem deutlich schwerer zu erreichen.

Minimalinvasive Einführung mit dem Strangler Pattern

Doch wie zerlegen wir nun unsere Anwendung? Ihr habt vermutlich schon vom Strangler Pattern gehört. Das heißt, eine neue Anwendung wird neben dem bestehenden Monolith gebaut. Sukzessive wird nun Funktionalität aus dem Monolith in die neue Anwendung (Strangler) überführt. Diese neue Anwendung kann dann einen anderen Architekturstil wie z.B. Microservices oder aber auch Self Contained System verfolgen. Wir haben uns dazu entschlossen, die bisherige Komponente zur Briefschreibung als neues System neben den bisherigen Monolithen zu stellen. Damit wollen wir zum einen konkrete Probleme lösen, aber auch Erfahrung sammeln, um dies auch auf den Rest von lifestream anzuwenden.

Bei der WWK laufen aktuell arbeitsintensive Großprojekte. Es kommt immer die Frage, ob hier nicht ein Risiko entsteht. Wir investieren daher für das neue System zur Briefschreibung viel Zeit in die Risikominimierung. Zum einen haben wir einen Parallelbetrieb vorgesehen, sodass für eine Zeit noch das alte System führend ist. Weiterhin stellen wir nicht alles auf einmal um, sondern machen das einzeln für jeden Dokumenttyp. Das heißt, für bestimmte Dokumenttypen wird dann das neue System führend. Hinzu kommt, dass wir im neuen System einen automatisierten Vergleich mit dem alten System vorgesehen haben. Dies hilft, die Testaufwände bei der WWK extrem gering zu halten und eine hohe Sicherheit für alle Beteiligten zu erreichen.

Überzeugungsarbeit ist nötig

Meine Erfahrung ist, dass aus der IT getriebene Themen unter besonderer Beobachtung stehen. Sie sind für die Geldgeber nicht so leicht nachzuvollziehen wie Themen mit konkreten Bezug zum Geschäft, wie z. B. neue Produkte, Kundenwünsche oder gesetzliche Anforderungen. Modernisierung muss daher gut erklärt und begründet werden. Dazu hilft es, diese Themen aus möglichst vielen Blinkwinkeln zu betrachten und insbesondere auch im Management kontinuierlich die Aufmerksamkeit auf diese Themen zu lenken. Wenn alle an Bord sind, können auch größere Modernisierungsvorhaben erfolgreich bewältigt werden. Denn letztlich ist auch Modernisierung nur Mittel zum Zweck und soll als Investition helfen, den zukünftigen Herausforderungen gewachsen zu sein.