Wellness für Software

Langlebige Softwaresysteme

Die zentrale Frage ist: Wann ist ein System langlebig? Wenn zentrale nichtfunktionale Anforderungen wie Wart- und Erweiterbarkeit, Analysierbarkeit usw. von Anfang an berücksichtigt wurden und immer noch beachtet werden.

Oft wird nämlich zugunsten neuer Funktionalität die Integrität des Systems aufs Spiel gesetzt. Kapazität für eine adäquate Anpassung der Architektur wird nicht bereitgestellt, schnelle Ergebnisse werden gefordert, das System degradiert. Mitarbeiter verlassen das Team und nehmen ihr Wissen mit, gleichzeitig wird die ungeliebte Dokumentation von Architektur und Code nicht nachgezogen.

Die Folge ist ein System, das zwar noch die funktionalen Anforderungen erfüllt, aber dessen Wart- und Erweiterbarkeit immer kritischer wird.

Was ist also zu tun, um ein System vor diesen Folgen zu schützen und seine Langlebigkeit sicherzustellen?

Aktuelle Dokumentation

Die Dokumentation der Architektur und der Software insgesamt muss jederzeit aktuell sein. Hierbei geht Aktualität immer vor Vollständigkeit. Im Zweifelsfall lieber nur ein gutes Architekturbild, das aber stets den aktuellen Stand dokumentiert, als große Mengen von Detaildokumenten mit fragwürdiger Gültigkeit.

Adäquate Architektur

Änderungen an den Anforderungen bedingen in vielen Fällen Anpassungen an der Architektur. Ein laufendes Refactoring parallel zur Entwicklung ist unabdingbar, um nicht in unregelmäßigen Abständen große Reengineering-Projekte starten zu müssen oder gar irgendwann das besagte nicht wartbare Legacy-System zu erhalten.

Kritisch ist in diesem Zusammenhang nicht nur eine degenerierte Architektur. Zu vermeiden ist auch ein Overdesign, also die Definition einer Architektur, die für die aktuellen Anforderungen zu mächtig ist und damit unnötigen Overhead zur Laufzeit und für die Entwicklung erzeugt. Oft wird hier Flexibilität an Stellen vorgesehen, die später an anderen Stellen benötigt wird. Hier gilt: „Design for today's use!“.

Konsequenzen aufzeigen

Ein oft unterschätztes Merkmal des Softwarearchitekten ist die Sorge für die jeweils adäquate Architektur: Der Architekt hat nicht nur eine gestalterische Rolle, er ist auch der Anwalt des guten Designs. Er hat dafür Sorge zu tragen, dass die Architektur immer im Sinne der Anforderungen wart- und erweiterbar bleibt. Das bedeutet auch, dem Management bzw. dem Kunden die Auswirkungen von Kosten- und Zeitdruck plausibel zu machen und die langfristige Wichtigkeit von Architekturanpassungen herauszustellen. Bei Änderungen, die mit der jetzigen Architektur nicht (sinnvoll) machbar sind, dürfen diese nicht durch Hacks eingebaut werden.

Regelmäßiger Frühjahrsputz

Aus Zeitgründen sind solche schnellen Lösungen jedoch oft kurzfristig notwendig. Wichtig ist, dass diese Hacks gut dokumentiert und die Verstöße als ToDos markiert werden. Sie sollten dann zeitnah repariert werden und die Architektur nachgezogen werden.

Hier ist es ratsam, in regelmäßigen Abständen eine Art Frühjahrsputz einzuschieben, bei dem sich das System wieder erholt. In einem kurzen Zeitabschnitt (z.B. ein Sprint von 2-3 Wochen) wird zunächst ein Feature Freeze verhängt und das Team kümmert sich ausschließlich darum, die Architektur zu aktualisieren, Unsauberkeiten zu beseitigen, nachzudokumentieren und das System somit wieder fit zu machen für die kommenden Herausforderungen.

Ein solcher Wellnessurlaub wirkt Wunder gegen degenerierende Systeme und unterstützt die Leistungsfähigkeit von langlebigen Systemen.

Dr. Jörg-Volker Müller