Agile Missverständnisse: Architektur entsteht emergent

Schon das agile Manifest hat eine klare Ansicht darüber, wo und wann Architektur entstehen sollte:

The best architectures, requirements, and designs emerge from self-organizing teams.

Also ist die Sache doch klar: Das Team entscheidet selbst über die Architektur, und die alten Mächte, die aus den Enterprise Architecture Boards die richtige Architektur aus der Ferne finden wollten, sind bezwungen. Endlich kann man selbst Hand anlegen und Architektur passiert dann, wenn sie gebraucht wird.

Architektur entsteht emergent

Aus dieser Sammlung von konkreten Entscheidungen entsteht per se eine Architektur, die den Geschäftsanforderungen gerecht wird – denn sie wurde daraus abgeleitet. Emergenz muss empirisch gewinnen, weil es immer nach dem modelliert wurde, was gerade erforderlich war.

Das gleiche gilt auch für Technical Debt. Und so muss die Architektur, die sich aus der Summe der Anforderungen, der geänderten Absichten und Refactorings ergibt, keineswegs eine Architektur sein, die auch das globale Optimum trifft. Die Summe der lokalen Optimierungen ist nicht das Gleiche und kann schnell in einer schlecht wartbaren Legacy-Lösung münden.

Also doch lieber das Architecture Board?

Agile Missverständnisse

Ihr habt Interesse an agilen Missverständnissen und anderen Anti-Pattern? Die passende App dazu findet ihr im Google Play Store:

Jetzt bei Google Play

Architecture Board to the rescue

Nein, die Agilisten haben schon Recht mit ihrem Ansatz, dass die besten Architekturen emergent entstehen. Emergent heißt jedoch nicht orientierungslos! Ganz im Gegenteil, eine gute, nachhaltige emergente Architektur muss orientiert entstehen. Und diese Orientierung muss dort, wo die Architektur entsteht, zur Verfügung stehen. Hier steht sie auf zwei Säulen:

  • Einerseits muss das selbstorganisierte Team wissen, welche Ziele es erreichen möchte. Und da spielen Qualitätskriterien, nichtfunktionale Anforderungen, existierende Erfahrung und Kompetenzen eine entscheidende Rolle. Sprich: Das Team muss sich – mit der Geschäftsseite – einig darüber sein, was man mit der gewählten Architektur zu erreichen gedenkt, und warum man es möchte.
  • Andererseits muss das selbstorganisierte Team ein gemeinsames Bild darüber haben, welche architektonischen Optionen zur Verfügung stehen, welche man wann auswählt und wie die gewählte Strategie funktioniert. Da reicht Dokumentation alleine nicht aus – die wird beim emergenten Schaffen von Architekturen als Arbeitsartefakt schnell vergessen – es braucht ein echtes, internalisiertes Bild der Architektur, ihrer Motivationen, ihrer Optionen und Alternativen.

So, und nur so, kann emergent eine Architektur entstehen, die auch längerfristig auf die wichtigsten Businessinteressen einzahlen kann.

Unsere Serie Agile Missverständnisse


Für neue Blogupdates anmelden:


2 Gedanken zu “Agile Missverständnisse: Architektur entsteht emergent

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.