Vor einiger Zeit kam ein Kunde mit dem Wunsch zu uns ein vorhandenes Softwaresystem in die Cloud zu heben und die Software möglichst auch für mobile Geräte verfügbar zu machen. Im ersten Gespräch stellte sich dann recht schnell heraus, dass die Software schon lange sehr erfolgreich genutzt wird und über die Jahre sehr viele Anforderungen umgesetzt wurden. Es waren dann irgendwann so viele Features, dass niemand mehr richtig einen Überblick darüber hatte, was die Software eigentlich alles konnte. Dokumentation war nicht wirklich vorhanden, aber es gab einige Kernentwickler, die sich richtig gut mit der Fachlichkeit auskannten und neue Wünsche immer noch schnell umsetzen konnten.
Vor allem der neue Wunsch nach Cloud und Mobile stellte alle vor eine Herausforderung, denn die Software basierte auf C++ mit MFC als Framework - war also für den typischen Windows-Desktop gedacht und auch entsprechend entworfen. Eine durchgängige Trennung zwischen Business-Logik und UI-Code gab es nicht. In einem solchen Fall ist natürlich guter Rat teuer - zumindest im sprichwörtlichen Sinne. So spontan konnten wir dazu auch keine gute Antwort geben. Es hörte sich danach an, dass man die Software einerseits in Module schneiden und andererseits, dass das Frontend Stück für Stück durch etwas anderes ersetzt werden sollte. Aber hierzu ad-hoc eine ein paar Lösungsansätze auf den Tisch zu werfen, erschien uns doch sehr fragwürdig.
Deshalb schlugen wir einen Review vor, in dem wir uns gemeinsam mit dem Kunden dem Thema nähern würden. Der Kunde war zuerst skeptisch, da die schon angedachten und angefangenen Maßnahmen eigentlich nur abgesegnet oder nachjustiert werden sollten. Deshalb wäre jetzt ein Review, der noch einmal alles in Frage stellt, doch eher kontraproduktiv. Trotzdem gelang es uns den Kunden zu überzeugen, dass die langfristigen Auswirkungen bei schlechter Wahl der Zielarchitektur und des Migrationsplans wesentlich stärker ins Gewicht fallen als eine evtl. kurzfristige Verzögerung durch parallele Review-Workshops. Die zusätzlich entstehenden Kosten fielen im Vergleich zu den Projektgesamtkosten eher sehr gering aus.
Um eine Analogie zu bemühen: Persönlich nehme ich auch für größere Umbauten z.B. am Haus auch gerne den Rat eines erfahrenen Architekten in Anspruch, bevor ich mehrere Handwerker beauftrage. Die zusätzlichen Kosten wiegen für mich das reduzierte Risiko auf jeden Fall auf.
Im konkreten Fall starteten wir ein Review und konnten nach wenigen Terminen schon ein sehr detailliertes Bild der vorhandenen Architektur identifizieren. Diese vorgefundene Architektur hatte - wie es oft bei Software der Fall ist, die in die Jahre gekommen ist - diverse Schwachstellen. Die Stabilität des Systems war durch gut umgesetzte Best Practices erstaunlich gut, allerdings zogen sich einige Abhängigkeiten quer durch die ganze Software. Auch fehlten großflächig automatisierte Tests, weshalb es eine große Testabteilung gab, die vor jedem Release alles ordentlich durchtesten musste.
Die Lösung dieser Schwierigkeiten liegt dabei nicht direkt auf der Hand. Stattdessen gibt es eine ganze Reihe von Möglichkeiten, die aber alle nicht durchgängig zum gewünschten Ziel führen:
- Ein Lift-and-Shift in die Cloud würde zwar das Deployment an sich vereinfachen, da die Software nicht mehr von jedem Kunden einzeln, sondern zentral installiert werden könnte.
- Eine große Kampagne zur Verbesserung oder Implementierung von automatisierten Tests könnte die Testaufwände reduzieren und damit die Release-Zyklen verkürzen.
- Ein Rewrite würde länger dauern, könnte dann aber auf einen Schlag alle alten Probleme lösen.
Die ersten beiden Ansätze führen nicht zur langfristig angestrebten Weblösung und letzte erübrigt sich in den meisten Fällen, da Kosten und Zeit völlig unrealistisch wären.
Es gibt bestimmt noch jede Menge andere Möglichkeiten, die aber alle für sich eher zu kurz greifen, zu lange dauern, zu teuer sind oder die weiterhin nötige Weiterentwicklung behindern würden. In diesem Fall ist es besonders wichtig, sämtliche Möglichkeiten gut untereinander abzuwägen und mit den jeweiligen Zielen der einzelnen “fachlichen Module” des Systems abzugleichen. So ist es dann möglich, die verschiedenen Lösungsideen zu einer Strategie zu verarbeiten.
Im angesprochenen Projekt war es etwa möglich zuerst aufwendige und häufig wiederkehrende Tests priorisiert zu automatisieren, um Testkapazitäten freizubekommen. Dadurch ergab sich dann die Möglichkeit an der Modularisierung zu arbeiten. Die Unterteilung wurde dann auch mithilfe von DDD-inspirierten Konzepten und Vorgehensweisen, bzw. Workshops fein geschliffen. Angefangen wurde dann mit einem Baustein, welcher einerseits den meisten Mehrwert lieferte, aber andererseits nicht die größte Komplexität aufwies. So kann gleichzeitig Mehrwert geliefert, aber auch das Risiko minimiert werden.
In unserem Beispiel wurde ein Modul ausgewählt, welches auch mobil erreichbar sein sollte. Dieses sollte ins Web portiert werden, damit sowohl Desktop- als auch Mobilgeräte Zugriff erhalten und damit einige neue Use Cases mittelfristig abgedeckt werden konnten.
Allgemein bietet sich in einem solchen Fall ein größeres Refactoring oder wie hier ein Rewrite an. Die konkrete Auswahl des neuen UIs hängt von vielen Faktoren ab - was aber zum Zeitpunkt des Reviews noch nicht entschieden werden muss. Stattdessen bietet es sich an, aus dem Review heraus eine grobe Strategie zu erarbeiten, die richtige Marschrichtung für die nächsten paar Monate festzulegen und dann währenddessen die Konzepte z.B. zum neuen UI auszuarbeiten. So kann dann nach dem erfolgreichen Abschluss der ersten Refactoringschritte auf die nun ausgearbeiteten Konzepte aufgebaut werden.
Eine Softwaremodernisierung in diesem Stil benötigt Zeit sowie eine gute, kontinuierliche Planung. Ob ein intensives Review, ein einfacher Assessment-Workshop oder eine intensivere Begleitung das richtige Mittel der Wahl ist, ist natürlich sehr kontextabhängig. Ein Review hat uns in diesem Projekt eine strukturierte sowie abgegrenzte Timebox zur Verfügung gestellt, mit der der Kunde gut informiert in den nachfolgenden Entscheidungsprozess eintreten konnte.