Vorlesung 2: Wie beeinflussen Organisationsstrukturen die Softwarearchitektur? Flashcards
Erkläre Conway’s Law
“Organisationen, die Systeme entwerfen, sind dazu gezwungen, Designs zu produzieren, die Kopien der Kommunikationsstrukturen der Organisation sind.”
-Conway’s Gesetz hilft dabei, die Beziehung zwischen Softwarearchitektur und Organisationen zu verstehen.
-Das Designen, Architekturieren und Entwickeln von Systemen erfordert ein hohes Maß an Kommunikation.
-Die Kommunikation wird komplizierter, wenn verschiedene Teams oder organisatorische Einheiten beteiligt sind.
-Schnittstellen zwischen Softwarekomponenten, Systemen oder Subsystemen werden organisatorische Grenzen widerspiegeln:
–Systeme oder Subsysteme werden organisatorische Einheiten widerspiegeln.
–Schnittstellen werden koordinierende Rollen widerspiegeln.
-Organisatorische Strukturen und entwickelte Architekturen sind isomorph.
-“Teamzuordnungen sind der erste Entwurf der Architektur”.
-Die Architektur muss schnellen Fluss innerhalb jedes Teams ermöglichen und fördern
Wie sind die Conway’s Law - Funktionsübergreifende Teams aufgebaut?
Wenn Teams in einer Organisation “cross-functional” sind, bedeutet das, dass sie aus Mitgliedern mit unterschiedlichen Fachkompetenzen und Verantwortlichkeiten zusammengesetzt sind. Zum Beispiel könnten Entwickler, Designer, Tester und Produktmanager gemeinsam in einem Team arbeiten. Diese Art von Teamzusammensetzung zielt darauf ab, die Effizienz und die Qualität der Arbeit zu verbessern, indem sie verschiedene Perspektiven und Fähigkeiten vereint.
In Bezug auf Conway’s Law bedeutet dies, dass cross-funktionale Teams dazu beitragen können, die traditionellen organisatorischen Silos zu überwinden, die sonst die Kommunikation und die Zusammenarbeit behindern könnten. Indem Teammitglieder mit unterschiedlichem Hintergrund eng zusammenarbeiten, können sie besser die Anforderungen und Bedürfnisse des Systems verstehen und die Architektur entsprechend gestalten, um diese Bedürfnisse effektiv zu erfüllen.
Wie sind die Conway’s Law - Funktionale Teams aufgebaut?
Wenn Teams in einer Organisation als “functional teams” (funktionsorientierte Teams) organisiert sind, bedeutet dies, dass sie oft nach funktionalen Bereichen oder Fachgebieten aufgeteilt sind. Zum Beispiel könnten Entwickler, Designer und Tester jeweils in getrennten Teams arbeiten, die sich jeweils auf ihre spezifischen Aufgaben und Fachgebiete konzentrieren.
Im Kontext von Conway’s Law hat die Organisation in funktionalen Teams direkte Auswirkungen auf die Softwarearchitektur. Diese Teams neigen dazu, ihre Arbeit entlang funktionaler Grenzen zu organisieren und daher die Software in Module oder Komponenten zu unterteilen, die den funktionalen Zuständigkeitsbereichen entsprechen. Dies kann zu einer Architektur führen, die ebenfalls entlang dieser funktionalen Grenzen strukturiert ist.
Ein potenzielles Problem dabei ist, dass die Kommunikation und Koordination zwischen den funktionalen Teams herausfordernder sein kann, insbesondere wenn sie an Teilen des Systems arbeiten, die miteinander interagieren müssen. Conway’s Law warnt vor der Gefahr, dass die Struktur und Kommunikation innerhalb der Organisation direkt die Struktur und Kommunikation im entwickelten System widerspiegeln kann, was zu suboptimalen Architekturentscheidungen und ineffizienter Zusammenarbeit führen könnte.
Was ist das Inverse Conway Maneuver (Umgekehrtes Conway-Manöver)
Das Inverse Conway Maneuver nutzt diesen Effekt umgekehrt, indem es die Organisation der Teams und die Kommunikationsstrukturen gezielt so anpasst, dass sie die gewünschte Architektur unterstützen. Anstatt zu versuchen, die Architektur direkt zu erzwingen, wird die Organisationsstruktur so gestaltet, dass sie natürlicherweise zu der gewünschten Architektur führt.
Zum Beispiel, wenn eine Organisation eine Architektur fördern möchte, die stark auf Microservices basiert, könnten sie Teams schaffen, die jeweils für spezifische Dienste oder Komponenten verantwortlich sind. Diese Teams könnten unabhängig voneinander arbeiten und hätten klare Schnittstellen und Verantwortlichkeiten, die der Architektur von Microservices entsprechen. Durch diese Organisationsstruktur würde die Architektur natürlicherweise in Microservices aufgeteilt und die Teams würden ihre Arbeit entsprechend koordinieren.
