OOP 2008: Agilität + Architektur?

Im Blog der OOP 2008 fragt Michael Stal nach der Lösung für die Addition "Agilität + Architektur". Architektur setzt er dabei vor allem in Bezug zur Zahl der an ihr beteiligten Köpfe vom einzelnen Architekten bis zur ganzen Entwicklergruppe eines Projektes.

Ohne nun sagen zu wollen, dass Agilität oder Softwarearchitektur leichte Geschäfte seien, habe ich bei dieser Frage aber doch gestutzt. Warum scheint sie überhaupt so schwer zu beantworten? Sie zu stellen suggeriert geradezu einen Gegensatz zwischen Agilität und Architektur. Wenn Agilität mit Flexibilität zu tun hat, steht dann Architektur für Inflexibilität? Hm...

Ich glaube, um die Addition zu lösen, ist zunächst ein Schritt zurück notwendig. Agilität und Architektur müssen von ihrer Absolutheit befreit werden. Weder Architektur noch Agilität sind Selbstzwecke. Hier mein Versuch der Reduktion auf das Wesentliche:

Agilität ist vor allem eine Haltung, die Unsicherheit und Unwissen eingesteht. Sie erkennt an, dass Software sich ständig einer wechselnden Umwelt anpassen muss. Softwareentwicklung ist für sie nur als Handlung-Feedback-Kreislauf denkbar, da Software und Umwelt rekursiv gekoppelt sind. Agile Softwareentwicklung bedeutet konstantes bewusstes Lernen mit allem, was dazu gehört (z.B. eine Vielfalt von Wahrnehmungsorganen, Reflektion, Fehler).

Architektur beschäftigt sich mit Plänen. Pläne sind Abstraktionen für Zukünftiges und Gegenwärtiges. Eine Softwarearchitektur ist zunächst die Beschreibung der zukünftigen Struktur einer Software. Und später ist sie (im besten Fall) nah an ihrer Implementation und dient als Landkarte. Beide Funktionen erfüllt sie durch Abstraktion: Die Architektur ist nicht die Implementation, sondern beschreibt sie nur vereinfacht.

Und was bedeutet das konkret? Wenig. Denn diese Definitionen haben nicht den Zweck, Konkretes zu liefern. Eine agile Haltung mag zum Konzept der Iterationen führen - aber über die Länge einer Iteration kann und soll sie keine Aussage machen. Und Architektur mag zwischen lokalen und entfernten Aufrufen unterscheiden - aber über die zu nutzende Technologie macht der Begriff Architektur keine Aussage.

Sowenig Konkretes mag nun den einen oder anderen verwundern oder gar ärgern. Was nützen denn allgemeine Konzepte für die harte Projektrealität? Oder ist denn nicht eine Collective Code Ownership der beste Weg zur gemeinsamen Arbeit an Software?

Sicherlich, am Ende müssen konkrete Handlungsanweisungen stehen. Doch zur Beantwortung der allgemeinen Ausgangsfrage nach der Summe von Agilität und Architektur bzw. dem Verhältnis zwischen beiden, sind nur gleichfalls allgemeine Definitionen hilfreich.

Agilität ist also quasi ein Synomym für Lebendigkeit, das Leben, denn Leben heißt permanente Anpassung, heißt konstantes Lernen, funktioniert nur durch Versuch und Irrtum. Doch Achtung: Eine Bakterie, ein Molch, ein Elefant, sie alle leben und verhalten sich doch ganz unterschiedlich. Alle sind angepasst an ihre Umwelt. Im Umkehrschluss bedeutet das, Agilität tut gut daran, wenn sie sich dem Lernen verpflichtet fühlt, keine Absolutheiten zu verkünden, sondern zunächst "nur" zur Ermittlung (!) angemessener Verhaltensweisen zu animieren. Was angemessen ist, bestimmt die Umwelt, zu der die Verhaltensweisen passen müssen.

Architektur auf der anderen Seite ist ebenfalls ein Synonym für Anpassung. Sie beschreibt das, was nach aktuellen Kenntnisstand über eine Umwelt eine zu ihr passgenaue Software ist. Doch nicht nur das! Architektur ist auch ein Synonym für Nachhaltigkeit und damit ein Gegengewicht zum "sprudelnden Leben". Zwar führt "sprudelndes Leben", also autopoietische Systeme ohne externe Kontrolle, auch zu Passgenauigkeit - aber das nur unter hohen Verlusten und über lange Zeiträume. Um Passgenauigkeit in kürzerer Zeit zu erreichen, ist Bewusstheit nötig. Und die liefert Architektur. Architektur ist insofern eine zutiefst menschliche Disziplin. Sie verlangt Vorausschau und balancierte Entscheidungen.

Vor dem Hintergrund dieser Betrachtungen, wird die Antwort auf die Ausgangsfrage plötzlich recht einfach:

Agilität ohne Architektur ist möglicherweise das Ideal. Die Architektur einer Software ist dann emergent; sie "mendelt sich aus" in einem evolutionären Prozess. Allerdings braucht das viel, viel Zeit und viele, viele Irrtümer. Die genetische Programmierung kann davon ein Lied singen. Mit Agilität ohne Architektur einen Kunden zu seinen Lebzeiten zufrieden stellen zu wollen, ist nur für triviale Projekte realistisch. Agilität ohne Architektur ist also eine Utopie.

Architektur ohne Agilität ist wie die Reflektionen eines Einsiedlers in seiner Höhle. Bewusstsein ohne Handlung und Feedback und Fehlerkorrektur ist nutzlos und realitätsfern - wenn nicht sogar ein Widerspruch in sich. Der Wasserfall war insofern immer eine naive Kontrollphantasie.

Agilität + Architektur ist damit keine Frage, sondern die Antwort. Software-Entwicklung, d.h. ein Prozess der bei einem Ausgangspunkt startet und dessen Ende meist möglichst weit in der Zukunft liegen soll, ist ein Bildungsprozess. Und Bildung passiert nicht einfach, sondern muss sich an den Gesetzen des Lebens orientieren - es gibt z.B. keinen Nürnberger Trichter - und ein Ziel haben, d.h. Vorstellungen darüber, wie das Ergebnis aussehen soll. Agilität liefert die Lebendigkeit und Architektur die Zielvorstellung für den Software-Bildungsprozess.

Wie lang in diesem Prozess dann ein Handlung-Feedback-Zyklus ist, bestimmt die Umwelt. Wieviele Köpfe über einer Architektur zu zerbrechen sind, bestimmen Problem und Umwelt. Wer unabhängig von konkreter Umwelt und konkretem Problem aufsteht und sagt, so und so lang muss eine Iteration sein oder so und soviele Personen müssen die Architektur definieren, der handelt wider das Leben. Der ist dogmatisch. Das ist zwar auch eine Haltung - aber eine, die eher früher als später auf Ungereimtheiten und Widerstände stößt.

Sicherlich lassen sich aus den allgemeinen Definitionen von Agilität und Architektur Rahmenbedingungen oder gar Gesetzmäßigkeiten ableiten. Sie setzen sinnvollen Antworten auf Fragen wie nach der Länge einer Iteration oder der Zahl der Architekten Grenzen. Doch diese Antworten sind weniger universell als viele vielleicht gern hätten.

So bleibt am Schluss nur die Feststellung: ohne Agilität+Architektur geht es nicht. Aber wirklich einfach wird das Geschäft der Software-Entwicklung dadurch noch nicht. Wer Software entwickeln will, muss sich damit anfreunden, dass es nicht um schnell hergestellte tote Maschinen geht, sondern um langlebige, komplexe Systeme für eine sich im steten Wandel befindliche Umwelt. Software-Entwicklung hat mit Leben + Planung, mit Lebensplanung zu tun. Und das schließt Ungewissheit und Unsicherheit, also auch Fehler mit ein.