Aufgabenstellung
Modernisierung und Weiterentwicklung eines Software-Systems zur Bearbeitung und Verbuchung von Treuekarten-Requests aus angeschlossenen Einzelhandelsfilialen.
Technologie
Programmiersprache: C++
Architekturstil: Monolith, Batch-Verarbeitung
Betriebsplattform: Linux, AIX
Warum Software-Modernisierung?
Der Software-Monolith wurde in C++ programmiert und ist mehr als 15 Jahre alt. Die Anwendung wurde kontinuierlich angepasst und unterstützt die Geschäftsprozesse gut. Die Software ist wartbar und lässt sich mit vertretbarem Aufwand erweitern und anpassen, z.B. um neue Mandanten anzubinden. Dennoch unterliegt das System einem nicht-trivialen Änderungsdruck, da die Software nur von einer einzigen Programmiererin betreut wurde.
Änderungstreiber "Braindrain"
Der Änderungstreiber "Braindrain" bezeichnet den absehbaren Verlust von entscheidenden Knowhow-Trägern, z.B. aufgrund einer anstehenden Pensionierung. In diesem Projekt betrug die verbleibende Zeit bis zur Rente der verantwortlichen Mitarbeiterin weniger als ein Jahr.
Der vom Braindrain erzeugte Änderungsruck war hoch, da es sich bei der Software um ein wichtiges System handelt, das hohe Umsätze generiert. Dieser Druck zwingt den Betreiber zu reagieren.
Ursachen
Fachkräftemangel: Der Änderungsdruck ist hoch, weil der Markt an C++-Expert:innen leer ist. Außerdem verfügt die in Rente gehende Mitarbeiterin über Jahrzehnte aufgebautes Fachwissen, das sich auch bei potenziell vorhandenen Nachfolger:innen nicht so ohne weiteres transferieren ließe.
Partielle Auslastung: Die Betreuung und Anpassung des Loyalty / Giftcard-Systems ist kein Vollzeit-Job, sondern erfordert im Durchschnitt etwa zehn Arbeitsstunden pro Woche. Dennoch ist es dem Betreiber wichtig, dass zu normalen Geschäftszeiten ein Programmierender zur Verfügung steht, der im Fehlerfall eingreifen und ohne Einarbeitungsaufwand Patches liefern kann.
Änderungstreiber "Fehlerfreiheit"
Der Änderungstreiber "Fehlerfreiheit" erfordert die Abwesenheit von Fehlern im Produktivbetrieb, insbesondere nach dem Rollout neuer Produktversionen. Das System ist ein Zahlungsnahes-System, so dass jeder Fehler in Produktion kritisch ist. Entsprechend hoch ist der Testaufwand vor jeder Lieferung.
Der vom Änderungstreiber Fehlerfreiheit erzeugte Änderungsdruck ist hoch, da Regressionsgefahr für alle angebundenen Mandaten besteht. Dieser hohe Druck sorgt dafür, dass Änderung nur dann vorgenommen werden, wenn diese absolut notwendig sind, da der resultierende Testaufwand unverhältnismäßig hoch ist und jede Änderung entsprechend teuer macht. Die seltene Änderungsfrequenz führt mittelfristig zu einer zunehmend schlechteren Unterstützung der Geschäftsprozesse.
Ursachen
Fehlende Testautomatisierung: Das System verfügt über keine automatisierten Tests. Regressionen werden ausschließlich durch manuelles Testen entdeckt.
Fachkräftemangel: Ähnlich dem Mangel an C++-Expert:innen ist der Markt an QA-Expert:innen leer.
Modernisierungsstrategie
Die Betreiber der Software haben gemeinsam mit CodeKeepers eine zweigleisige Modernisierungsstrategie erarbeitet. Diese beinhaltet zum einen den Umgang mit dem drohenden Personalverlust aufgrund der anstehenden Pensionierung. Und zum anderen die Verbesserung der automatisierten Qualitätssicherung und Software-Lieferung.
Knowledge Backup ist eine CodeKeepers-Strategie zum Umgang mit drohenden Personalengpässen. Für das Projekt hat CodeKeepers zwei C++-Experten abgestellt, die sich intensiv und in enger Zusammenarbeit mit der in Rente gehenden Programmiererin in das System eingearbeitet haben. Seit Abschluss der Einarbeitung und Übernahme beschäftigen sich die beiden kontinuierlich in einem Umfang von zwei Entwicklungstagen pro Monat mit dem System. Primär geht es an diesen beiden sog. Knowledge Backup-Tagen darum, dass die Entwickler am Ball bleiben und im Fall der Fälle (3rd Level-Support, kurzfristige Erweiterungen) schnell aktiv werden können. Der Betreiber des Systems erhält dadurch ausreichend Sicherheit, um schnell auf neue Anforderungen und Fehler reagieren zu können, ohne dafür ein oder zwei Vollzeitstellen besetzen zu müssen.
Der zweite Teil der Modernisierungsstrategie bestand im Aufbau eines automatisierten Testnetzwerks sowie der Deployment-Automatisierung. Als zentrale Teststrategie kam dabei die sog. Golden-Master-Technik zum Einsatz. Der Test betrachtet das System als Blackbox, die Daten auf einer TCP/IP-Verbindung empfängt und entsprechende Antworten sendet. Für den Test wurden eine Reihe von exemplarischen Antwortdaten in Produktion aufgezeichnet. Nach jeder Änderung des Systems wird automatisiert sichergestellt, dass die vom System gelieferten Antwortdaten weiterhin mit den aufgezeichneten Daten übereinstimmen, was die Abwesenheit von Regressionen zeigt.
Basierend auf dem Regressions-Test wurden zwei GitLab-CI/CD-Pipelines aufgesetzt. Die Development-Pipeline baut die Anwendung nach jedem Commit und führt den Regressionstest für eine kleine Anzahl von Mandaten durch. Die Release-Pipeline wird manuell gestartet, führt einen großen Regressionstest für alle Mandaten durch und sendet das verpackte Release an die Betriebsabteilung.
Zusammenfassung
Mit Hilfe der Modernisierungsstrategie Knowledge Backup in Kombination mit Golden Master-Tests und Build-Automatisierung konnte das System erfolgreich übernommen und in einen stabilen Produktivbetrieb überführt werden. Aktuell beanspruchen Wartung und Betrieb im Mittel drei bis vier Personentage im Monat. Diese Tage werden von unseren beiden Mitarbeitern für kleinere Verbesserungen, Refactorings sowie der Erweiterung des Testnetzwerks genutzt. Darüber hinaus gewährleistet die kontinuierliche Beschäftigung mit dem System den Erhalt des erforderlichen Wissens und ermöglicht dem Betreiber das verzögerungsfreie Hochfahren der Entwicklungskapazitäten, sobald größere Änderungen, wie das Anbinden neuer Mandanten anstehen.