Agile Missverständnisse: Architektur entsteht emergent

Agile Missverständnisse: Architektur entsteht emergent

Avatar von Johann-Peter Hartmann

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?

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.

[smartblock id=“7056″]

Unsere Serie Agile Missverständnisse


Avatar von Johann-Peter Hartmann

Kommentare

2 Antworten zu „Agile Missverständnisse: Architektur entsteht emergent“

  1. Lesetipp: Agile Missverständnisse: Architektur entsteht emergent https://t.co/U017G6tiwq https://t.co/KQsA487CyT

  2. Wie entsteht eigentlich emergent eine Architektur, die auch längerfristig auf die wichtigsten Businessinteressen ei… https://t.co/RzVM7r4Uhg

Schreibe einen Kommentar

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


Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.