© Ekaphon maneechot/Shutterstock.com
Nachhaltige Softwareentwicklung

Gebaut für den Wandel


Eine aufwändig entwickelte Software soll möglichst langfristig genutzt werden. Damit sie stets den aktuellen fachlichen und technologischen Anforderungen genügt, muss die Anpassung permanent erfolgen. Gleichzeitig hat sich die Art, wie Software entwickelt wird, über die Jahre hinweg nicht nur technisch, sondern auch organisatorisch geändert. Wie und von wem eine Software erstellt wurde, hat deshalb eine größere Auswirkung auf die langfristige Qualität als die eingesetzten Technologien.

Bei der Erstellung einer Software werden häufig schon viele Kardinalfehler begangen, die eine spätere Modernisierung oder Anpassung nahezu unmöglich machen. Irgendwann ist dann der Zeitpunkt gekommen, sich von dieser Altlast zu verabschieden. Doch soweit muss es gar nicht kommen, wenn man einige wenige Erkenntnisse konsequent umsetzt.

Kleine Einheiten statt großer Monolithen

Eine saubere Schichtenarchitektur und die Wiederverwendung von Komponenten galten lange als Allheilmittel gegen die Wartungskrise. Trotzdem fressen die steigenden Wartungskosten weiterhin den größten Teil der Weiterentwicklungskosten auf. Inzwischen zählen selbst objektorientierte Projekte als Legacy zu den ungeliebten Altlasten, und dabei spreche ich nicht nur von der nicht mehr zeitgemäßen Benutzeroberfläche. Häufig wird Schichtenarchitektur aus Oberfläche, Geschäftslogik und Datenhaltung eingesetzt, um das vorhandene Wissen und die Arbeit besser organisieren zu können.

pientka_nachhaltig_1.tif_fmt1.jpgAbb. 1: Alles Wissen ist in fachübergreifenden Teams vorhanden

Anstatt die Arbeit wie bei der Schichtenarchitektur nach technischen Aspekten zu organisieren und damit die einzelnen Schichten unabhängig voneinander zu betrachten, sollte immer das System als Ganzes im Auge behalten werden. Dabei trägt das Team nicht nur Verantwortung für die Entwicklung selbst, sondern auch für den produktiven Einsatz. Um die fachlichen, technischen und betrieblichen Aspekte abdecken zu können, muss ein Team interdisziplinär aufgebaut sein. So muss ein fachübergreifendes Team (Abb. 1) das gesamte benötige Wissen für die Erstellung und den Betrieb der Anwendung haben oder sich aneignen. Dieser Ansatz reduziert nicht nur die Abstimmungskosten, sondern wirkt sich auch auf die Architektur der Lösung aus. Es wird versucht, das Anforderungsproblem ganzheitlich von der Erstellung bis zum Betrieb in kleinen Schritten angemessen zu lösen. Dabei sollte sich auf den optimalen Nutzen konzentriert werden, unnötiger Ballast und die Produktion von nicht benötigten Funktionalitäten sollten vermieden werden. Da Entscheidungen dezentral getroffen werden, können Fehler schneller und pragmatischer gelöst werden.

Automatische Tests, Integration und Installation als Teil der Entwicklung führten schließlich dazu, dass eher brauchbare kleinere fachliche Dienste und vertikale Komponenten (Abb. 2) entstanden sind. Durch einen kontinuierlichen Deployment-Prozess können diese schneller mit der nötigen Qualität ausgeliefert werden, sodass früher Rückmeldungen aus dem Livebetrieb in die Weiterentwicklung einfließen können.

Miteinander statt gegeneinander

Da bei Verfolgung des DevOps-Ansatzes Betrieb und Entwicklung eng zusammenarbeiten, werden Kommunikations- und Abstimmungsprobleme schon früh vermieden und der gegenseitige Lernprozess wird gefördert. Die in der Entwicklung eingesetzten Prozesse, Prinzipien und Werkzeuge unterscheiden sich nicht, egal ob damit eine Test-, Integrations- oder Produktionsumgebung aufgebaut wird. Derartige Umgebungen werden durch Einzelschritte gestaltet, sodass Fehler durch Änderungen transparent nachvollzogen werden können. Um Fehler jedoch zu vermeiden und eine konstante Produktionsqualität zu erreichen, ist es nötig, dass die einzelnen Schritte autom...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang