Das Gesetz von Conway (Conway’s Law) wurde von Melvin Conway 1968 formuliert und besagt:

„Organisationen, die Systeme entwerfen, sind gezwungen, Designs zu produzieren, die die Kommunikationsstrukturen dieser Organisationen widerspiegeln.“

Bedeutung in der Softwarearchitektur:

Das Gesetz von Conway beschreibt, dass die Architektur eines Softwaresystems oft unbewusst die Organisationsstrukturen des Entwicklerteams widerspiegelt. Wenn ein Unternehmen beispielsweise aus mehreren getrennten Abteilungen besteht, dann tendieren auch die Softwarelösungen dazu, stark voneinander abgegrenzte Module oder Services zu haben.

Beispiele:

1. Monolithische Organisation → Monolithische Software
   Ein stark hierarchisch strukturiertes Unternehmen führt oft zu monolithischen Softwarearchitekturen mit wenigen, aber großen Komponenten.
2. Dezentrale Teams → Microservices
   In agilen Unternehmen mit autonomen Teams entstehen oft Microservices, da jedes Team einen unabhängigen Service verwaltet.
3. Globale verteilte Teams → API-zentrierte Systeme
   Wenn Teams in verschiedenen Ländern arbeiten, sind Schnittstellen oft durch gut dokumentierte APIs definiert, um die Zusammenarbeit zu erleichtern.

Anwendung im Cloud Computing & DevOps:

• DevOps & Conway’s Law: DevOps fördert interdisziplinäre Teams mit Verantwortung für Entwicklung und Betrieb, was oft zu Microservice-Architekturen führt.
• Reverse Conway Maneuver: Unternehmen können bewusst ihre Organisationsstruktur so ändern, dass sie eine gewünschte Softwarearchitektur begünstigt.

Das Gesetz von Conway wird oft in Domain-Driven Design (DDD) und Cloud-native Architekturen diskutiert, da es Unternehmen hilft, die Wechselwirkungen zwischen Teamstruktur und Softwarearchitektur zu verstehen.