In diesem Artikel beleuchte ich eines der schwierigsten Probleme in der Software-Produktentwicklung: die richtige Balance zwischen dem Entwickeln neuer Features und dem Weiterentwickeln der technischen Architektur. 

Lieferdruck ist immer da

Je besser ein Produktmanagement ist, desto mehr Ideen zur Weiterentwicklung der eigenen Produkte gibt es. Ideen sind einfach, aber die Umsetzung ist schwer. Dieser Umstand und ein oft dynamischer Wettbewerb führen zu einem hohen Druck möglichst schnell möglichst viele neue Features zu implementieren. 

Ideen sind einfach, aber die Umsetzung ist schwer.

Damit steigt die Bereitschaft technische “Workarounds” zugunsten einer kürzeren Time-to-market zu akzeptieren. Doch selbst ohne unsaubere Abkürzungen entsteht in jeder Software über die Zeit unweigerlich eine unsaubere Architektur oder sogenannte “technische Schulden”. Dies kann passieren, weil Software erweitert wird, aber auch einfach deshalb, weil das Geschäft erfolgreich wächst und damit auch der Umfang und die Menge der verarbeiteten Daten. 

Was sind “Altsysteme” oder “technische Schulden”?

Es gibt viele Begriffe für nicht optimale Softwarearchitektur, zum Beispiel “Technical Debt” (“technische Schulden”) oder “Legacy Software” (“Altsysteme”). Doch wann kann man Softwarearchitektur als nicht gut klassifizieren? Ich finde dafür zwei Kriterien hilfreich, nämlich wenn die Software:

• die aktuellen Anforderungen nicht erfüllt und/oder
• Änderbarkeit, Skalierbarkeit oder zuverlässiger Betrieb nicht gegeben sind.

Negative Begriffe wie “Legacy” zu verwenden, finde ich nicht hilfreich. Sie brandmarken die Software und unter Umständen auch die Kollegen, die an ihr arbeiten. Ich halte es für nützlicher statt dessen von “architektonischer Qualität” zu sprechen und es damit ins Positive umzukehren. 

Welche architektonische Qualitäten gibt es?

Man muss zwei Ebenen der Architektur für die Qualitätsbeurteilung unterscheiden:

1. Die Mikroarchitektur bezeichnet die Implementierung einzelner Services. Beispiele für mangelnde architektonische Qualität auf dieser Ebene können notwendige Refactorings sein, eine geringe Testabdeckung oder ähnliches. Solche Qualitätsprobleme entstehen durch hohen Zeitdruck bei der Implementierung, aber auch durch fehlende Kapazitäten bei der späteren Pflege von Software. Durch Microservice-Architekturen und Cloud Provider kann man heute neue Services in Minuten erschaffen. Wer all diese Services aber langfristig pflegt, ist häufig unklar oder es fehlt dafür die Zeit. Daraus entstehen sehr schnell Probleme in der Mikroarchitektur.
2. Die Makroarchitektur bezeichnet die übergreifende Architektur als Zusammenspiel der einzelnen Services in komplexen Systemen. Typische Architekturprobleme sind hier etwa die Speicherung von Daten (mit falscher Technologie an den falschen Stellen) oder deren Verarbeitung und Verfügbarmachung (unklare Domänen, Verantwortung und Source of Truth, suboptimale Datenflüsse). Solcherlei Qualitätsprobleme entstehen auch durch “pragmatische Workarounds” (Funktionalität wird da eingebaut, wo es schneller geht, anstatt an der richtigen Stelle). Aber auch eine vormals adäquate Makroarchitektur kann über die Zeit unpassend werden. Steigt etwa das verarbeitete Datenvolumen signifikant an (z. B. auf Grund von Geschäftswachstum), kann es sein, dass eine weitere Skalierung in der bestehenden Architektur schwierig wird. Diesen Punkt sollte man in einem erfolgreich wachsenden Geschäft nicht unterschätzen.

Auf beiden Ebenen gilt: Die State-of-the-art-Lösung von heute wird zur Legacy von morgen, wenn ich nicht in ihre architektonische Qualität investiere. 

Wann muss ich in Architektur investieren?

Wenn ich nun bei digitalen Produkten in deren Architektur investieren muss: Wann muss ich das tun?

Die State-of-the-art-Lösung von heute wird zur Legacy von morgen, wenn ich nicht in ihre architektonische Qualität investiere.

Hier ist es wichtig zu verstehen, wie sich mangelnde architektonische Qualität auswirkt. Investiere ich ausschließlich in Business Features und kaum in architektonische Qualität, so werde ich kurzfristig schneller Wert liefern können. Der rote Graph in der untenstehenden Grafik zeigt einen solchen Fall. Allerspätestens mittelfristig werde ich jedoch immer langsamer. Änderungen werden aufwändiger oder gar nicht mehr machbar. Im schlimmsten Fall führt das zu einem Migrationsprojekt, bei dem ich meine hoffnungslose “Legacy-Software” durch einen kompletten Neubau ersetzen muss. Solche Projekte blockieren über lange Zeit wichtige Umsetzungskapazitäten. Noch schlimmer: Häufig werden während der langwierigen Migration möglichst keine neuen Features hinzugefügt um das Migrationsprojekt beherrschbar zu halten. Das bedeutet jedoch, dass in dieser Zeit kaum neuer Wert für den Kunden geschaffen wird, sondern erst danach wieder.

Um solche Worst-Case-Szenarien zu vermeiden, ist es notwendig kontinuierlich in architektonische Qualität zu investieren. Der grüne Graph zeigt ein solches, ideales Szenario. Hierbei erzeuge ich zwar zunächst weniger Business Value als wenn ich gar nicht in Architektur investiere, aber dafür über die Zeit konstant und in Summe deutlich mehr als bei mangelnder Investition.

Wie kann ich effektiv kontinuierlich in Architektur investieren?

Wie stelle ich nun aber sicher, dass ich im Angesicht des Tagesgeschäfts, dringender Vorhaben etc. wirklich kontinuierlich in architektonische Qualität investiere? Auch hierfür ist es sinnvoll die beiden Ebenen separat zu betrachten. 

Mikroarchitektur

Wenn neue Business Features fertiggestellt wurden, ist die Versuchung (oder der Druck) für Teams oft hoch sofort das nächste Vorhaben anzugehen. Das Ziel sollte aber sein, dass die veränderten Komponenten noch aufgeräumt und in deren Mikroarchitektur investiert wird. Hierbei können Regeln helfen, die die nötige Zeit schaffen. 

Eine solche Regel könnte lauten, dass ein Projekt alle Services, die es verändert, in mindestens der gleichen oder einer besseren Qualität hinterlassen muss. Das lässt sich durch klassische Code-Metriken, z. B. Test Coverage, messen. Es lässt sich auch erzwingen, dass ein Deployment nur möglich ist, wenn die Regel eingehalten wurde.

Eine andere Möglichkeit ist es am Ende jedes Vorhabens oder Projektes eine Zeitspanne für Code-Pflege vorzusehen. Nach dem Erreichen des Business-Zieles könnte das Team z. B. zwei weitere Wochen Zeit bekommen um den Code aufzuräumen, bevor das nächste Vorhaben startet. 

Alternativ könnte man auch zwei Tage im Monat festlegen, an denen das Team Code-Pflege betreiben darf und nicht an anderen Themen arbeiten muss.

Makroarchitektur

Um kontinuierlich und zielgerichtet in die Makroarchitektur investieren zu können, gilt es zunächst ein paar Voraussetzungen zu erfüllen: 

Als Wichtigstes brauche ich eine langfristige Architekturvision für meine Systeme, die das optimale Zielbild definiert. Diese Vision muss laufend gepflegt und weiterentwickelt werden, denn natürlich verändert sich auch das optimale Zielbild mit der Zeit. Diese Architekturvision muss heruntergebrochen sein in eine schrittweise umsetzbare Roadmap. 

Doch selbst wenn ich diese Roadmap habe, ist es deutlich schwieriger diese Schritte umzusetzen. Echte Verbesserungen auf Makroebene sind nämlich typischerweise aufwändig und stehen damit in noch stärkerer Konkurrenz zu neuen Business Features. 

Im Idealfall kann ich die Umsetzung von Business Features mit Investitionen in die Architektur kombinieren. Dazu muss man die Roadmap aus Verbesserungen haben und ernsthaft versuchen Schritte daraus mit aktuellen Business Features zu kombinieren. Das klappt meiner Erfahrung nach öfter als man denkt.

Dennoch klappt es nicht immer und dann muss ich einen anderen Weg finden. Um Architekturverbesserungen gegenüber Business Features zu priorisieren, kann ich idealerweise ihren Wert beziffern, z. B. wenn ich Hosting-Kosten reduziere. Oftmals ist das jedoch nicht so einfach möglich. Dann werden Architekturinvestitionen leicht zugunsten von Business Features zurückgestellt. Eine einzige funktionierende Lösung habe ich zu diesem Problem kennengelernt. Hierbei muss man einen festen Teil der Engineering-Kapazität für Architekturverbesserungen reservieren. Wenn das von den Stakeholdern akzeptiert ist, muss ich über diese Kapazität auch nicht jedes Mal neu verhandeln.

Wie kann das funktionieren?

Einige Fragen sind dazu naheliegend:

• Wie viel Prozent meiner Engineering-Kapazität kann ich fortwährend “abzwacken” und sie in Architektur investieren? Die Antwort hängt natürlich von den jeweiligen Gegebenheiten ab: einerseits vom aktuellen Zustand der Makroarchitektur und andererseits von den Business-Anforderungen. Ganz allgemein halte ich Werte zwischen 15 und 30 Prozent für vernünftig.
• Wenn fortwährend Kollegen an Architekturqualität arbeiten, wie legt man fest, was sie genau tun? In erster Linie sollte sich das aus der Architekturvision und Roadmap ergeben. Generell würde ich das den Engineering-Teams und Führungsrollen überlassen. Produktmanager müssen bei diesen Entscheidungen nicht zwingend mitwirken, sie sollten aber zumindest immer wissen, woran die Kollegen arbeiten und was sie verbessern. Sehr hilfreich wäre es dafür KPIs zu definieren samt Zielwerten. Diese können dann eine praktische Hilfe bei der Priorisierung und gleichzeitig ein Erfolgsmesser sein. 
• Wenn fortwährend die gleichen Mitarbeiter nur an Architektur(-defiziten) arbeiten, demotiviert sie das nicht? Ob immer die gleichen Mitarbeiter daran arbeiten, hängt zuerst von der Organisation der Teams ab. Im Missions-Modell könnte zum Beispiel die Architekturqualität eine kontinuierliche Mission sein. In diese würden Mitarbeiter aus anderen abgeschlossenen Mission hinein und später in neue Missionen heraus wechseln können.
  Wenn Teamstrukturen hingegen fest an Komponenten gekoppelt sind, sieht es natürlich anders aus. In meiner Zeit bei idealo hatte ich aber beispielsweise ein Team, das eine “Legacy”-Applikation modernisiert hat. Diese erfüllte hinterher noch dieselbe Funktion, hatte aber nur noch halb so viel Code und eine großartige Testabdeckung. Das Team war zurecht sehr stolz darauf. Es war war allerdings auch schon vorher sehr motiviert die Qualität alter Applikationen zu verbessern.
• Wenn ich schon ein Team vorhalte, das sich fortwährend um die Makroarchitektur kümmert, kann das nicht gleich auch die Mikroarchitektur verbessern? Vorsicht, das ist der Abzweig auf die dunkle Seite der Macht! Ein dediziertes Team sollte sich stets vorrangig um übergreifende Architekturverbesserungen kümmern. Andernfalls verleitet es die Kollegen, die an den Business Features arbeiten, selbst nicht mehr auf die Mikroarchitektur zu achten. Die Verantwortung geht verloren und ehe man sich versieht, räumt das dedizierte Team nur noch hinter den anderen Teams auf und hat keine Zeit mehr für Verbesserungen der Makroarchitektur.

Fazit

Was auch immer man versucht: Der größte Fehler wäre es, nicht nach der Balance zwischen Feature-Entwicklung und Architektur-Weiterentwicklung zu streben. Jegliches Übergewicht auf der einen oder anderen Seite wird früher oder später die digitale Produktentwicklung enorm verlangsamen.