Modernisierung von Altanwendungen – die Dos & Don’ts

Ende Mai / Anfang Juni fand die International PHP Conference in Berlin statt, auf der zwei unserer Kollegen als Speaker mit spannenden Themen vor Ort waren. Die gut besuchte Konferenz bot ein breites Spektrum an Besuchern und Unternehmen – und jeden trieben andere Gründe an, vor Ort zu sein.
w
Unser Björn hat die Gelegenheit genutzt und sich unters Volk gemischt. Seine Intention war es, herauszufinden, was die größten Problemfelder sind, denen sich Entwickler und Unternehmen aktuell stellen müssen. Das Ergebnis ist wenig überraschend …

Modernisierung von Altanwendungen

Wie Björn herausgefunden hat, ist die Modernisierung von Altanwendungen eines der wichtigsten Themen – und nicht selten versucht man, diesem Problem mit einem kompletten Rewrite zu begegnen.

Warum das allerdings nicht unbedingt die beste Entscheidung ist und was man sonst noch beachten sollte, erklärt Björn uns in einem Round-up-Interview.

Björn, was hast du von der International PHP Conference mitgenommen? Was treibt die Community gerade an? Wo sind die Schmerzen?

Björn Schotte: Ich habe viele Gespräche geführt; sowohl mit Teilnehmern als auch mit einer Reihe von Ausstellern der Unternehmen, die vor Ort waren. Ein großes, wichtiges Thema ist die Modernisierung von Altanwendungen.

Gerade im PHP-, JavaScript- und Java-Umfeld gibt es sehr viele Anwendungen, die schon seit zehn Jahren und mehr im Betrieb sind, mit denen die Firmen ihre Prozesse verwalten und mit denen sie auch ordentlich Geld verdienen. Aber die Entwicklung kann da teilweise nicht Schritt halten mit der Entwicklung neuer Frameworks oder Ähnlichem. Deswegen stehen viele Firmen davor, ihre Softwaresysteme zu modernisieren.

Was ich mir so mitgenommen habe aus den Gesprächen war, dass viele tatsächlich zu einem vollständigen Rewrite tendieren. Aus professioneller Sicht habe ich da natürlich ein paar Schmerzen damit …

… die da wären?

Björn: Das grundsätzliche Problem ist natürlich, dass es immer sehr leicht ist, zu sagen, man lässt seinen Monolithen erst einmal sterben, oder man lässt ihn erst einmal weiterlaufen und baut etwas völlig Neues. Am besten natürlich noch mit den neuesten Hypes garniert, wie zum Beispiel Microservices und Ähnliches.

Das ist aber in der Regel nicht sonderlich empfehlenswert, denn am Ende des Tages geht es ja auch darum, wie man so eine Modernisierung ökonomisch am besten verantworten kann. Da hat sich in der Regel gezeigt, dass ein kompletter Rewrite nicht immer die beste Lösung ist.

Du sagst ökonomisch … was sind die Indikatoren? Woran machst du eine Entscheidung für die nächsten Schritte fest?

Björn: In der Regel ist es natürlich sinnvoll, wenn Entwickler oder ein Entwickler-Team sagt, dass bestimmte Technologien veraltet sind und erneuert werden sollten. Das ist der Technik-Treiber. Aber am wichtigsten sind meiner Meinung nach die Business-Treiber an dieser Stelle.

Stell‘ dir folgendes Szenario vor: Eine Plattform, die hier in Deutschland in ihrem Markt groß geworden ist und eine gewisse Saturierung erreicht hat, und jetzt als nächstes Ziel eine Internationalisierung anstrebt. Das ist ein Business-Treiber, der unter Umständen geradezu danach schreit, die Software-Plattform zu modernisieren – vor allem, da ich aus den Gesprächen heraus festgestellt habe, dass viele Softwaresysteme das Problem haben, dass sie bestimmte aus dem Business kommende Anforderungen nicht mehr so leicht umsetzen lassen können.

Der größte Treiber sind eigentlich die Business Needs.

Man kann aus technischer Sicht sehr gut beobachten, dass mit der Zeit die Dauer für die Implementierung eines Features immer mehr zunimmt, da viele Dinge an einen Softwaremonolithen „herangestrickt“ werden, und die Entwickler sich natürlich denken, dass es schöner wäre, wenn man es besser und modularer aufbauen würde, wenn man das neueste Framework einsetzen würde – wenn man vielleicht auf Symfony oder Spring Boot aufsetzen könnte … Da haben viele entsprechend Schwierigkeiten – deswegen sind der größte Treiber eigentlich die Business Needs.

Von Business-Seite aus das Ganze prosperiert: es gibt neue Business-Ideen, die Kunden verlangen nach entsprechenden neuen Features, aber du kommst mit der Implementierung nicht mehr hinterher. Ich glaube, dass wenn man da genau darauf achtet und versucht zu erkennen, ob man Signale hat, die aus Business-Sicht her die Queue volllaufen lassen, dann ist der Zeitpunkt gekommen, um über eine Modernisierung nachzudenken.

Wie bringst du die Business-Sicht mit den Entwicklern unter einen Hut?

Björn: In der Regel ist es natürlich so, dass wenn ich an eine Umsetzung im agilen Softwaresinne – also auch in der agilen Kultur – denke, dann arbeiten Business und Technik eng zusammen und agieren wie ein gemeinsames Team.

Das ist in vielen Unternehmen natürlich häufig nicht der Fall. Deswegen hat es sich dort etabliert, zu Beginn so eine Art ATAM-Workshop (Architecture Tradeoff Analysis Method) zu machen – das ist eine leichtgewichtige Form eines Architektur-Workshops, bei dem man alle Stakeholder in einem Raum versammelt. Das heißt Stakeholder sowohl von der Technik, von der umsetzenden Seite, wie auch natürlich von der Business-Seite, aus den verschiedenen Fachbereichen, Projektsponsoren, Budgetgeber, usw. Vielleicht sogar auch den Endkunden, was durchaus einen Sinn ergibt.

Im Rahmen eines ATAM-Workshops bespricht man, was die Kriterien im Rahmen einer Softwaremodernisierung sind.

Im Rahmen eines solchen Workshops bespricht man, was die Kriterien im Rahmen einer Softwaremodernisierung sind. Man stellt die Frage, was die neue Software alles erfüllen können. Das sind dann meistens Funktionstreiber. Stell dir beispielsweise ein ERP-System vor: Die neue Architekturvariante muss mit mindestens 30 Varianten umgehen können – dann wäre das ein Kriterium, das eine bestimmte Wichtigkeit erhält. So sammelt man alle verschiedene Kriterien, die man gegen die entsprechenden zuvor ausgedachten Architekturszenarien wirft. Dabei überlegt man sich dann auch, wie intensiv die Software entsprechend modernisiert werden muss. Anhand der Bewertung erhält man am Ende einen Vorschlag, der nach bestem Wissen und Gewissen aller Teilnehmer des Workshops eine Empfehlung für eine Architekturvariante ist, die angegangen werden kann.

Dann gibt es natürlich noch Möglichkeiten, wie man sich überlegen kann, die Softwaremodernisierung so umzusetzen, dass die alte Plattform weiterläuft. Für den Entwickler wäre zum Beispiel daran zu denken, mit einem Proxysystem zu arbeiten, mit dem zum Beispiel nach URLs separiert wird: Ein bestimmter Teil der URLs geht noch auf die alte Plattform, andere URLs gehen dann entsprechend auf die neuen Bereiche, die hinzugebaut wurden. Für den Endnutzer, der sich auf der Plattform bewegt, ist es gar nicht erkennbar, dass er auf zwei verschiedenen Systemen agiert, sondern über ein Proxysytem gehandhabt wird. Das ist zum Beispiel eine Architekturvariante, wie man so eine Modernisierung schrittweise durchführen kann. Es gibt noch viele weitere Varianten und Strategien, die man umsetzen kann – das klärt man am besten in einem solchen Workshop.
[smartblock id=6342]

Wie geht es danach weiter? Ist das Business nach so einem Workshop raus aus dem Thema Modernisierung?

Björn: Nein, auf gar keinen Fall. Ich denke da immer im agilen Kultursinne, d.h. das Business arbeitet sehr eng mit der Entwicklung zusammen; was natürlich immer vom Einzelfall abhängt. Es kommt zum Beispiel darauf an, wie groß das Entwicklerteam ist, wie groß die einzelnen Teams geschnitten sind, weil man sich dann unter Umständen dafür entscheidet, einen bestimmten Teil der Arbeit auf die Maintenance der Altplattform zu verwenden, und den neuen Teil der Ressourcen entsprechend für den neuen Teil der Plattform zur Verfügung zu stellen. Das ist der organisatorische Part.

Das Wichtige ist es, sich Gedanken über den technischen Part zu machen. Man muss sehen, was der entsprechende Business-Treiber ist, was man eben in einem solchen Workshop herausfindet. Das Wichtigste ist es jedoch, zu verstehen, dass der Vorschlag zu dem Zeitpunkt herauskommt, an dem der Workshop stattfindet; dieser Vorschlag ist aber nicht in Stein gemeißelt. Denn wie wir aus der Agilität wissen: Der Scope und die Welt verändert sich permanent. Das heißt, man muss mit dem erarbeiteten Vorschlag eine Weile lang arbeiten; es ist aber eine gute Praktik, wenn man den Vorschlag immer mal wieder auf den Prüfstand stellt und wirklich genau schaut, ob es jetzt noch passt, oder ob man eine andere Variation mit einbringen muss. Der Kerngedanke dabei ist, eine gewisse Flexibilität und Adaptierbarkeit zu berücksichtigen, damit man nicht stur einem Plan folgt, sondern sich tatsächlich auch immer wieder überprüft.

Viele Kunden haben Angst davor, in regelmäßigen Abständen die Wahl der Technologie zu hinterfragen.

Deswegen glaube ich nicht daran, dass Komplett-Rewrites tatsächlich erfolgreich sind. Es gibt auch Statistiken darüber, dass ein kompletter Rewrite in der Regel nicht erfolgreich ist. Man muss tatsächlich in kleinen, iterativen Schritten arbeiten. Gerade wenn es um über viele Jahre gewachsene Softwaresysteme geht, die auch für den Kunden eine gewisse Businesskritikalität haben, packt man nicht mal eben ein neues System hin. Mann muss die Wahl der Technologie in regelmäßigen Abständen hinterfragen – war die Wahl tatsächlich das Richtige, oder muss man vielleicht doch noch einmal umsatteln? Eben weil es zum Beispiel neue Frameworks gibt, die mehr Möglichkeiten bieten, und man dann entsprechend abwägen sollte, ob man diese Benefits zum Wohle des Projekts mitnimmt?

Aus vielen Gesprächen habe ich mitgenommen, dass noch viele Kunden Angst davor haben. Sie wollen am besten immer die komplette Sicherheit, dass über eine sehr lange Strecke von vielen Monaten oder Jahren die Technologie, für die man sich entschieden hat, festgesetzt ist. Ich kann diesen Wunsch nach Sicherheit zwar verstehen, aber auf der anderen Seite nimmt man sich damit Flexibilität. Denn wenn man als Gesamtteam – sowohl von Business wie auch von der Technik her – feststellt, dass man in eine andere Richtung rennen sollte, ist es doch das Beste, tatsächlich die Richtung anzupassen.

Aus deinen Erfahrungen heraus: Wie viel Arbeit steckt dahinter, dieses Mindset in die Köpfe der Entscheider zu bringen?

Björn: Also ich glaube, da liegt an dieser Stelle noch viel Arbeit vor uns. Ich habe eine Reihe von Gesprächen geführt, bei denen die Überlegung, einen Komplett-Rewrite durchzuführen, offensichtlich schon beschlossene Sache war. Ich glaube eher, dass der iterative Ansatz viel erfolgsversprechender ist. D.h. ein Team so zu schneiden und aufzusetzen, dass man in kleinen Schritten und einer gewissen Flexibilität in der Technologie liefern kann. Man merkt, dass da noch ein wenig Education notwendig ist, um tatsächlich vernünftige Architekturentscheidungen zu treffen. Was ich mir auch mitgenommen habe, ist, dass Dinge wie ATAM-Workshops, also Architekturszenarien aufstellen, zwar teilweise schon gemacht wurde – aber nicht in der Tiefe, die es vielleicht gebraucht hätte.

Wie viel Erfahrung hast du mit solchen Workshops sammeln können?

Björn: Wir haben solche Workshops schon sehr oft durchgeführt, da wir in der Vergangenheit schon viele Projekte hatten, bei denen eine Modernisierung anstand und tatsächlich das Business der initiale Treiber war, indem man gesagt hat, man wolle die Gelegenheit nutzen, das System zu modernisieren, weil die Altplattform einfach nicht mehr mithalten konnte.

Wir haben also schon viel Erfahrung mit solchen Projekten und geben die natürlich über solche Workshops weiter und stehen passend dazu als Implementierungspartner zur Verfügung.

Wer mehr Informationen haben möchte oder daran interessiert ist, wie man einen solchen Workshop durchführt oder worauf dabei zu achten ist, der sollte mich am besten per E-Mail kontaktieren.