Soziologie der Softwarearchitektur

Im Oktober 2020 habe ich auf der Konferenz “Der agile Kompass” das Spotify-Modell referiert und hier beschrieben. Beim Vortrag machte Boris Gloger eine Aussage, die ich in diesen Artikel aufgreifen möchte:

“Viel zu oft erlebe ich bei agilen Coaches das ausschließliche Denken in Werteströmen. Aber ich muss mir bei der Organisationsentwicklung auch über die Architektur Gedanken machen, die den Produkten zugrunde liegt.”

Conways Law

Der Zusammenhang zwischen Organisationsstrukturen und Softwarearchitekturen hat Melvin E. Conway bereits 1968 beobachtet. Conway hat herausgefunden, dass die Architektur der IT ein Abbild der Kommunikationsstrukturen einer Organisation ist.

Wenn also eine Organisation zur Entwicklung der Architektur die Abteilungen S1, S2 und S3 hat, dann wird das geschaffene System mit hoher Wahrscheinlichkeit die Schichten E1, E2 und E3 aufweisen

Conways Gesetz

Architektur und Innovation am Beispiel Amazon

Jeff Bezos, Gründer und CEO von Amazon, macht sich relativ früh Gedanken, wie er den damaligen monolithischen Amazon Web Shop so strukturieren kann, dass Innovationen einfach möglich sind. Und er erkannte folgendes: Innovation findet nur statt, wenn Fehlschläge reversibel sind und nicht das gesamte System betreffen. Die Lösung für Amazon war die Erfindung der 2-Pizza-Regel. Mache die Teams nur so groß, dass diese mit 2 Pizzen satt werden. Die 2-Pizza-Regel galt auch für die Architektur: Mache die Module nur so groß, dass diese vollständig von so einem 2-Pizza-Team entwickelt werden können.

Innovation erfordert autonome dezentrale Teams

Jeff Bezos verband für den Bereich Forschung & Entwicklung die Architektur des Systems mit der Organisationsentwicklung. Die Lösung für Amazon war die Schaffung von dezentralen autonomen Teams und die Entwicklung von Micro-Services, die von diesen Teams mit großer Unabhängigkeit entwickelt und betrieben werden können. Andere Bereiche bei Amazon, die eher dem Operations zugeordnet sind, werden als Werteströme organisiert und betrieben. So ist es auch bei Spotify. Das agile Spotify-Modell mit seinen Chapters, Tribes, Squads und Gilden ist im Bereich Forschung & Entwicklung angesiedelt. Andere Bereiche wie Business Development, Marketing und Vertrieb arbeiten klassisch funktional.

Organisationsentwicklung und Architektur

Mein Fazit: Ich sage nicht, dass jetzt alles ganz einfach ist und innovative Bereiche in dezentralen Zellen und Operations in Funktionen organisiert werden soll. Das wäre zu kurz gedacht. Ich sage aber, dass eine agile Organisationsstruktur auch eine Architektur erfordert, diese Organisationsstruktur unterstützt und dass es nicht reicht, einfach nur agile Teams zu gründen. Oder anders gesagt, die optimale Organisationsform existiert nicht, sondern sie ist das Ergebnis einer Reise der Adaption an die jeweils notwendigen Zwecke. Eine Reise, die vielleicht niemals endet.

Talk und Folienvortrag von Gerrit Beine

Wenn du mehr zu dem Thema wissen möchtest, schau dir den Talk und Folienvortrag von Gerrit Beine zu dem Thema an. Ich kann ihn sehr empfehlen.

Viel Spaß beim Anschauen

Previous PostVoodoo Priester und die Methode Spotify – Teil 1 - Die Illusion
Next Post12 Gründe für den "Best of Blog 2020" auf t2informatik.de
comments powered by Disqus