Viele Firmen benutzen Software über einen längeren Zeitraum. Für die Wertschöpfung sind diese legacy-Systeme unverzichtbar und eine Migration auf andere Systeme schwierig und langwierig. Aufgrund des Alters der Software und der verwendeten Technologie, die meist mit altert, sind verschiedene Herausforderungen zu meistern:
- es ist für manche Entwickler wenig aufregend an alter Software mit zu arbeiten. Es ist eher eine Pflicht- bzw. Daueraufgabe, die im Tagesgeschäft mit Termindruck schnell untergeht.
- die Modernisierung fällt schwer, da häufig vieles historisch gewachsen ist. Abhängigkeiten in dem System bestehen, wo die verantwortlichen Mitarbeiter vielleicht schon längst nicht mehr im Hause sind.
- das Know-how, um die verwendete Technologie, nimmt langsam ab
Kurzum, „an das Ding will keiner mehr so richtig ran“ und Themen wie Code-Pflege oder Wartung treten langsam immer weiter im Geiste der Entwicklerschaft zurück. Das legacy-System erodiert weiter.
Gamechanger Modernisierung
Im Team arbeiten wir gerade an so einem legacy-System. Wir modernisieren das Build-System. Konkret bedeutet dies: Ein Umstieg von Apache Ant auf Gradle.
Das Build-Tool ist ein zentrales Element in der Produkterstellung und Wertschöpfungskette. Die Aufgabe ist herausfordernd und nicht trivial aufgrund der Größe des legacy-Systems (>5 Mio. LoC), Verwobenheit der technischen Schulden und Abhängigkeiten, teils mit nicht mehr vorhandenem internen Know-how. An dieser Stelle möchte ich darauf aber nicht eingehen, andere Geschichte…
Was mich hier erfreut, ist folgender Umstand: Die umfangreiche Modernisierung unseres legacy-Systems ist für alle sicht- und spürbar. Dies führt dazu, dass die Entwicklungsteams sich wieder mehr in die Modernisierung einbringen. Konkret bedeutet dies, wir bekommen Hinweise auf:
- technische Schulden
- zu entsorgenden Code, der manchmal seit Jahren nicht angefasst wurde, aber irgendwie doch liegen blieb
- Lösungsansätze, wie manches deutlich vereinfacht werden kann. – Und im Idealfall die direkte Unterstützung bei einer konkreten Umsetzung.
Dies sind nur Beispiele bei der Umsetzung in den letzen Monaten. Die Beteiligung, gerade was die Umstellung auf ein neues Build-System angeht, erfordert die Mitarbeit aller. Insbesondere der bei uns vorgefundene Unterschied zwischen automatisierter Buildstrecke im CI-System und der lokalen Entwicklung, war immer ein Spannungsfeld. Änderungen auf der einen Seite waren manchmal nicht kompatibel und führten zu genervten Entwicklern auf der einen Seite und Systembetreuern auf der anderen Seite. Jetzt sind beide Seiten deutlich näher zusammengekommen und Effekte zahlen sich beidseitig aus. Kommunikation und gemeinsamer Austausch setzt ein.
In meinen Augen ist sogar ein auftretender Bug bei einer Anpassung positiv anzusehen. Da dieser jetzt sowohl lokal als auch zentral in der Automatisierung gleichermaßen auftritt. Der Fehler wird sehr schnell bemerkt und zügig gefixt. Dadurch besteht deutlich weniger Angst vor notwendigen Veränderungen und Modernisierungen, da nun negative Effekte transparent und offensichtlich sind.
Fazit
Langfristig wird so Modernisierung wieder einfacher in der Umsetzung und die Zusammenarbeit zwischen Entwicklern und Systembetreuern gefördert. In der Einstellung der Beteiligten sinkt hoffentlich so die Hemmschwelle, das System dauerhaft aktuell zu halten. Für die Ausbaufähigkeit und Wandlungsfähigkeit des legacy-Systems eine große Chance. Nutzen wir sie.
mehr dazu auch unter Meetup Legacy & Innovation No. 13