Open Loops

An dieser Stelle sei einmal auf den Podcast SoftArchitekTOUR verwiesen. In bisher dreizehn Folgen wurden viele relevante Themen, ausgehend von einer Episode zum Thema Pattern über Diskussionen zur Mittelschicht bis hin zu einer Folge über Architektur-Refactoring, behandelt.

Die Podcasts haben dabei keinen Präsentationscharakter, sondern sind offene Gespräche, in denen auch kontroverse Standpunkte diskutiert werden. Zwar sind die einzelnen Episode recht lang (bis zu einer Stunde dauert ein solcher Podcast), doch lassen sich die Themen meist auch nicht kürzer darstellen.

Der Podcast bietet eine Menge Informationen und Standpunkte zum Thema Architektur und ist meiner Meinung nach durchweg hörenswert. Viel Spaß beim Reinhören!

Die Architektur einer Anwendung entsteht auf Basis funtionaler und nicht-funktionaler Anforderungen im Spannungsfeld zwischen Vollständigkeit und Planungshorizont.

Sie sollte den Rahmen für die Umsetzung der gerade anstehenden Features bilden und dadurch die Effizienz der Umsetzung fördern. Die Architektur darf dabei aber nicht alle denkbaren Änderungen bereits vorwegnehmen. Sie würde dadurch mit Balast überfrachtet, der die dann tatsächlich eintretende Änderung doch nicht berücksichtigt und nur unnötigt erschwert. Als Planungshorizont erscheint ein Umfang von ein bis zwei Iterationen ideal.

Man entwickelt die Architektur iterativ und inkrementell, indem die gerade geforderten Features umgesetzt und direkt anschließende Änderungen gegebenenfalls mitgedacht werden. Das so entstehende System hat eine tragfähige Basis und genug Flexibilität um auch grundlegende Änderungen kurzfristig zu ermöglichen

Die Kunst besteht gerade darin, das Gesamtsystem trotz aller abgebildeten Komplexität nicht kompliziert werden zu lassen.

In Diskussionen gewinne ich immer wieder den Eindruck, dass “iterativ” und “inkrementell” synonym verwendet werden, zumindest aber die eigentliche Bedeutung von “iterativ” nicht vollständig verstanden wird. Das Langenscheidt Fremdwörterbuch definiert “Inkrement” und “Iteration” wie folgt:

• “In·kre’ment, das; -s,-e kleine Stufe der Zunahme”
• “Ite·ra·ti’on, die; -,-en Verfahren der schrittweisen Annäherung an eine exakte Lösung”

Dementsprechend bedeutet ein iteratives Vorgehen etwas anderes als ein inkrementelles. Bei ersterem gibt es von Anfang an einen Blick auf und einen Eindruck vom Gesamtsystem. Die zunächst grobe Ausgestaltung wird dann iterativ überarbeitet, verfeinert und ergänzt. Das Gesamtziel gerät dabei aber nie aus dem Blick.

Bei einem inkrementellen Vorgehen wird hingegen eine Basis Schritt für Schritt um Imkremente ergänzt. Das Gesamtsystem existiert dann erst, wenn alle Inkremente erstellt worden sind. Hier besteht die Gefahr, dass durch den Wunsch nach immer mehr Funktionalität kein Ende gefunden wird.

Alistair Cockburn verdeutlicht den Unterschied zwischen beiden Begriffen anhand einer fiktiven Entstehungsgeschichte des Gemäldes “Die Bauernhochzeit” von Pieter Brueghel: Incremental means adding, iterative means reworking. Alistair Cockburn übernimmt dabei die Veranschaulichung von Jeff Patton, der die Idee auf den XP-Days präsentiert hat. Dieser beschreibt die Unterschiede und die Synthese beider Begriffe ausführlich in seinem Blog: “Don’t know what I want, but I know how to get it.“

In den Beiträgen wird deutlich, dass ein iteratives Vorgehen bedeutet, vorhandene Bestandteile zu überarbeiten und zu verfeinern: Das Grundgerüst ist von Anfang an vorhanden und wird im Laufe der Iterationen verbessert. Dies entspricht der Forderung von Kent Beck: “The rules of the Planning Game state that the result of the first iteration must be a functional skeleton of the system as a whole.” (Extreme Programming Explained, Addison-Wesley, 2000) Bei einem inkrementellen Vorgehen ist dies nicht zwangsläufig so, und es besteht damit die Gefahr, das eigentliche Ziel aus den Augen zu verlieren.

Ein Projekt, auch gerade eines, das mit agilen Methoden durchgeführt wird, besteht immer aus iterativen und inkrementellen Schritten. Dies und die damit verbundenen Unterschiede sollte man nicht aus den Augen verlieren.

In klassischen Vorgehensmodellen werden Anforderungen häufig in Form von Use Cases beschrieben, in agilen Modellen ist hingegen meist von User Stories die Rede. Die Vermutung, es würde hier nur die gleiche Idee neu benannt ist zwar naheliegend aber falsch. Eine sehr treffende Unterscheidung hat Alistair Cockburn gefunden:

“A user story is the title of one scenario, whereas a use case is the contents of multiple (related) scenarios.”

Außerdem ist die Differenzierung zwischen klassischen und agilen Methoden an dieser Stelle nicht zielführend. Use Cases sind auch - oder gerade - im Kontext agiler Methoden sinnvoll, da sie im Gegensatz zu User Stories ein vollständigeres Bild des Projektumfanges geben und die einzelnen Anforderungen zueinander in Beziehung setzen. Eine ausführliche Erörterung findet sich ebenfalls bei Alistair Cockburn: “Why I still use use cases“. Ebenfalls lesenswert ist in diesem Zusammenhang Jens Coldewey: “Use Cases, User Stories und Akzeptanztests“.

Eine Architektur für eine Anwendung zu entwickeln ist eine Sache. Dafür zu sorgen, dass auch nach einigen Erweiterungen und Änderungen des Systems die Architektur noch trägt, eine ganz andere. Wenn der Zeitdruck steigt, wenn einfach etwas fertig werden muss, besteht die Gefahr, dass ‘mal eben’ an der Architektur vorbei entwickelt wird. Wie stelle ich nun aber fest, ob die angedachte Architektur auch tatsächlich wie beabsichtigt implementiert wurde?

Soll eine Architektur einer Anwendung ermittelt werden, bietet sich am ehesten ein Review des entsprechenden Systems an. Hierbei wird anhand konkreter Fragestellungen die Anwendung begutachtet und eine detaillierte Analyse erstellt. Leider ist dieses Verfahren nicht automatisierbar und damit aufwändig und teuer. Wenn im Laufe einer Iteration oder zwischen Iterationen der Status ermittelt werden soll, ist ein Review nicht geeignet.

Um schnell einen Überblick zu gewinnen, muss eine möglichst stark automatisierbare Lösung geschaffen werden. Es bietet sich hierbei an, die neuerdings unter dem Begriff “technische Qualität” oder “Architekturmanagement” firmierenden Metriken zur Softwarequalität auszuwerten. Ein Klassiker ist die Cyclomatic Complexity Number, die McCabe bereits 1976 entwickelte. Die Koppelung zwischen Modulen lässt sich z.B. mit der Average Component Dependency bestimmen. Ganz neu ist das Maß C.R.A.P. (Change Risk Analysis and Predictions), das einen Hinweis darauf geben soll, mit wie viel Aufwand die Änderung an einem Stück Software verbunden ist. Natürlich gibt es keine Metrik, mit welcher sich die Architektur einer Anwendung auf einer Skala von null bis eins bewerten ließe. Das kann schon alleine deshalb nicht funktionieren, da die Architektur anhand der Anforderungen entwickelt wird und es damit für funktional identische Systeme bei unterschiedlichen Anforderungen verschiedene “beste” Architekturen gibt.

Metriken können dennoch helfen. Sie können Hinweise geben, an welcher Stelle im System eventuell ein genauerer Blick notwendig ist. Und wenn die Kopplung zwischen den Modulen im Laufe der Entwicklung zunimmt, dann ist dies in der Tat ein starkes Indiz dafür, dass die Architektur leidet. Das Ermitteln der Metriken kann z.B. mittels XRadar einfach in den Buildprozess integriert werden. Probieren Sie es aus und schreiben Sie uns ihr „Aha“-Erlebnis in Bezug auf Metriken. Wir sind gespannt.