Frank PientkaInnovation und Technologie

Ein Weg aus der Software-Wartungsfalle

Eine aufwändig entwickelte Software soll möglichst lange genutzt werden. Damit sie den aktuellen fachlichen und technologischen Anforderungen genügt, muss sie permanent angepasst werden. Bei der Erstellung wurden dabei schon viele Kardinalfehler gemacht, die eine spätere Modernisierung oder Anpassung immer schwerer machen. Irgendwann ist der Zeitpunkt gekommen, sich von dieser Altlast zu verabschieden. Doch soweit muss es nicht kommen, wenn man einige wenige Erkenntnisse konsequent umsetzt.

Die Wiederverwendung von Komponenten und eine saubere Schichtenarchitektur galten lange Zeit als Allheilmittel gegen die Wartungskrise. Doch inzwischen zählen selbst objektorientierte Projekte als Legacy zu den ungeliebten Altlasten und ich spreche nicht nur von der nicht mehr zeitgemäßen Benutzeroberfläche.

Eine Schichtenarchitektur aus Oberfläche, Geschäftslogik und Datenhaltung wird häufig deswegen eingesetzt, um das vorhandene Wissen und die Arbeit besser organisieren zu können. Damit konnte jedoch nicht verhindert werden, dass ein nur schwer kontrollierbarer Software-Monolith herangewachsen ist. Selbst kleinere Anpassungen können nur von mehreren Personen in den jeweiligen Schichten vorgenommen werden, so dass die Software immer nur als Ganzes aktualisiert werden kann.

Neben Kommunikations- und Abstimmungsproblemen führt der Engpass der Verfügbarkeit von Spezialisten dazu, dass die Entwicklung unnötig verlangsamt und verteuert wird. Um die Gesamtqualität des Systems zu gewährleisten, steigen auch die Test- und Integrationsaufwände. Aufwände zur Optimierung der Qualität für eine Schicht wirken sich nicht zwingend positiv auf die Gesamtqualität und Aufwände aus.

Ein anderer Ansatz, der vor allem durch Scrum populärer wurde, sind die fachübergreifenden Teams, in denen das gesamte benötige Wissen für die Erstellung und den Betrieb der Anwendung vorhanden ist. Dieser eher produktorientierte Ansatz reduziert nicht nur die Abstimmungsaufwände, sondern wirkt sich auch auf die Lösung aus. Hierbei wird versucht, das Anforderungsproblem ganzheitlich von der Erstellung bis zum Betrieb in kleinen Schritten angemessen zu lösen. Dabei wird vermieden, unnötigen Ballast aufzubauen oder nicht benötigte Funktionalität zu produzieren, sondern die Entwickler konzentrieren sich auf den optimalen Nutzen. Dadurch dass Entscheidung dezentral getroffen werden, können Fehler schneller und pragmatischer gelöst werden.

Der im Open-Source-Bereich bekannte Ansatz des Design-by-Community mit wenigen festen Regeln ist dem Design-by-Committee-Ansatz weit überlegen. Dieser Ansatz wirkt sich auch auf das Design der Anwendung aus. Dadurch dass automatisches Testen, Integration und Installation bereits Teil der Entwicklung sind, werden eher kleinere Dienste und Komponenten erstellt. Diese können schneller ausgeliefert werden, so dass Rückmeldungen für die Weiterentwicklung bereits früher einfließen können. Dadurch dass Betrieb und Entwicklung bei DevOps schon früh und eng zusammenarbeiten, können diese leichter voneinander lernen. Die Prozesse, Prinzipen und Werkzeuge, die in der Entwicklung eingesetzt werden, unterscheiden sich nicht, ob damit eine Test-, Integrations- oder Produktionsumgebung aufgebaut wird. Dadurch dass diese wiederholt und nachvollziehbar schnell aufgebaut werden, kann das nur in kleinen automatisierbaren Schritten erfolgen. Nur so lässt sich die nötige Flexibilität und Nachvollziehbarkeit erreichen, um Fehler zu vermeiden und eine konstante Produktionsqualität zu halten. Damit können Wissensinseln vermieden und der Bau von neuen Silos verhindert werden. Das Entwicklungsteam kann lokal und selbständig entscheiden, welche Maßnahmen es ergreifen möchte und welche Technologie für ihr Problem am besten geeignet ist.

Als schöner Nebeneffekt können kleinere, überschaubarere und testbare Einheiten schneller erstellt und mit höherer Qualität geliefert werden. Kleine unabhängige Software-Komponenten haben auch den Vorteil, dass diese einfacher zu ändern oder zu ersetzen sind. Hier gilt der Grundsatz, dass Design-for-Replacement wichtiger ist als Design-for-Reuse. Um sicherzustellen, dass die Ersetzbarkeit auch erhalten bleibt, ist es nötig, dass neben der eigentlichen Zielumgebung im automatischen Build- und Deployment-Prozess alternative Versionen oder Umgebungen mitgetestet werden.

Die kontinuierliche Überprüfung der Ersetzbarkeit vermeidet später größere und riskantere Migrations- und Modernisierungsschritte. Dadurch werden nicht nur die späteren Aufwände und das damit verbundene Risiko minimiert. Es können auch neuere Versionen schneller ausgetauscht werden, um z. B. Sicherheitslücken oder Fehler in Fremdkomponenten in der Produktion zu beheben, da diese bereits präventiv mitgetestet wurden. So bleibt die Anwendung in der Produktion länger stabil und durch die neuen eingesetzten Versionen frisch, um auch mit wachsenden Anforderungen Schritt halten zu können.

Interessante Links

Build to last, Frank Pientka, Materna Monitor 2/2012

Schlagwörter: , , , ,