Continuous Architecture: Prinzipien als Schlüssel erfolgreicher Softwareentwicklung – Teil 4
Continuous Architecture: Entwurfsentscheidungen verschieben
Continuous Architecture: Prinzipien als Schlüssel erfolgreicher Softwareentwicklung – Teil 4
Continuous Architecture: Entwurfsentscheidungen verschieben
Als Menschen neigen wir dazu, Unsicherheiten zu beseitigen, indem wir frühzeitig Entscheidungen treffen. Diese werden oft in bester Absicht gefällt, jedoch zu einem Zeitpunkt, an dem noch nicht ausreichend Wissen vorliegt. In diesem vierten Teil unserer Serie zu „Continuous Architecture“ [1], [2] betrachten wir das Prinzip des „Last Responsible Moment“, das dabei hilft, Entscheidungen auf einer besseren Wissensbasis aufzubauen.
„Hinterher sind wir immer schlauer“ – diese Lebensweisheit spiegelt eine Erfahrung wider, die wir alle kennen. Bezogen auf Entwicklungsvorhaben zeigt sich häufig, dass zum Abschluss Wissen vorhanden ist, das zuvor hilfreich gewesen wäre, aber noch fehlte. Ob Konzepte, Technologien oder Anforderungen, über die Dauer des Projekts haben wir dazugelernt. Was bedeutet das für die bereits getroffenen Entscheidungen?
An sich ist der Gedanke verlockend: Der letzte Meilenstein ist erreicht, das Team feiert den Erfolg und mit dem klingenden Geräusch anstoßender Gläser scheint sie plötzlich da zu sein – die ultimative Erleuchtung, mit der alle Fragen beantwortet werden. Doch natürlich ist das ein Märchen. Das Wissen, das jetzt zur Verfügung steht, ist nicht plötzlich entstanden, sondern wurde im Verlauf des Projekts Stück für Stück aufgebaut. Gehen wir also einen Schritt zurück und fragen uns: Wann genau sind wir eigentlich schlauer geworden?
Was du heute kannst besorgen …
Zu Beginn eines Entwicklungsvorhabens herrscht oft Unsicherheit. Anforderungen sind noch unklar und auch die Technik wirft Fragen auf. Selbst wenn der Technologiestack und das Toolset weitgehend vorgegeben sind, gibt es oft noch Freiheitsgrade: Middleware, Randsysteme und ihre Integrationskonzepte müssen verstanden werden. Die Architektur basiert zunächst auf Grobkonzepten, die erst verfeinert und auf ihre Tragfähigkeit geprüft werden müssen. Zu Beginn steht alles am Anfang einer notwendigen Evolution – sowohl die Konzepte als auch das Verständnis des Teams. Erst mit dem Fortschreiten dieser Evolution entsteht das Wissen, das als Grundlage für fundierte Entscheidungen dient. Je weiter man sich entlang der Zeitachse bewegt, desto mehr Wissen wurde gezielt aufgebaut.
Hier entsteht jedoch ein Dilemma (Abb. 1): Architekturentscheidungen sind langlebig und im Nachhinein oft nur schwer – und teuer – zu ändern. Gleichzeitig sind die Entscheidungen, die das Gesamtsystem langfristig prägen, häufig frühzeitig erkennbar. Es besteht die Gefahr, gewichtige, schwer revidierbare Entscheidungen zu einem Zeitpunkt zu treffen, an dem zwar bereits genug Wissen für eine mögliche Entscheidung vorliegt, das Wissen für eine bessere Entscheidung jedoch noch fehlt.
Abb. 1: The Project Paradox nach Peter Gfader [3]
Der letzte vernünftige Moment
Die Praktik, Entscheidungen nicht sofort, sondern erst zu einem späteren Zeitpunkt zu treffen, an dem man besser informiert ist, wurde von Mary und Tom Poppendieck in ihren Publikationen, u. a. in [4] beschrieben. Sie ist eine im Lean Software Development und generell im agilen Umfeld verbreitete Methode, die gelegentlich fälschlicherweise mit Prokrastination assoziiert wird. Im Deutschen wird sie häufig wortwörtlich als „letzter verantwortungsvoller Moment“ übersetzt. Stefan Toth hat in [5] eine leicht abweichende Übersetzung des Begriffs vorgeschlagen: Mit „letzter vernünftiger Moment“ wird die Rationalität und Angemessenheit des Entscheidungszeitpunkts betont. Diese Deutung...
