Die Beziehung zwischen Teamorganisation und Anwendungsarchitektur

Diese Beziehung ist als Conways Gesetz bekannt, das 1967 von Melvin Conway formuliert wurde und wie folgt lautet: „Organisationen, die Systeme entwerfen […], sind darauf beschränkt, Designs zu produzieren, die Kopien der Kommunikationsstrukturen dieser Organisationen sind.“

Die Kommunikation innerhalb des Teams ist häufig und fließend, mit regelmäßigen Planungsmeetings, Dailies, Retrospektiven und Demos. Dies ermöglicht dem Team ein hohes Maß an Abstimmung und agiler Koordination, was für die Entwicklung einer Komponente grundlegend ist. Wenn Sie plötzlich beschließen, dieses Team in 2 Teams aufzuteilen, entsteht ein Bruch in der Kommunikation. Die Kommunikation mit anderen Teams ist viel seltener, da eine der Ideen von Teams darin besteht, sie von externen Einflüssen zu isolieren, damit sie sich auf ihren Bereich konzentrieren können. Diese Reduzierung der Kommunikation zwischen den Teams macht die Aufgabe, eine einzelne Komponente zu pflegen, komplexer. In diesen Fällen gibt es zwei Möglichkeiten: 1) Die Komponente in 2 aufteilen, eine pro Team, was den Teams erlaubt, sich zu entkoppeln und autonomer zu arbeiten. 2) Eine einzelne Komponente beibehalten, was die Einrichtung einer Reihe von Koordinationsmechanismen und Meetings zwischen den Teams erfordert, mit der damit verbundenen Mehrbelastung. Darüber hinaus sind die Teams voneinander abhängig, was Geschwindigkeit und Autonomie reduziert und die Produktivität beeinträchtigt (da sie so eng zusammenarbeiten müssen, könnte man fast sagen, dass es praktisch immer noch nur ein Team gibt).

Traditionell wird die Teamreorganisation oft von oben durchgeführt, und nicht immer von Personen mit tiefem Wissen über die Anwendungsarchitektur. Immer wieder sah ich Teams um Kunden herum reorganisiert werden, sodass bei einem neuen Kunden ein neues Team gebildet wurde. Und in einigen Fällen endeten wir damit, den Code zu forken, damit das neue Team unabhängig und agil sein konnte. Mit allem, was das mit sich bringt: den Code zu duplizieren, mit all seinen Bugs und technischen Schulden;

Um eine architektursensibelere Reorganisation durchzuführen, die die Anwendung nicht negativ beeinflusst, gibt es das sogenannte umgekehrte Conway-Manöver. Dieses besteht darin, das Team so zu organisieren, dass es die Architektur der zu erreichenden Anwendung nachbildet. Um diese Art von Reorganisation zu entwerfen, ist es unerlässlich, auf die Zusammenarbeit von Software-Architekten zu zählen, die bei der Gestaltung unter Verwendung von Software-Architekturprinzipien helfen. Teams können als System betrachtet werden, mit verschiedenen Komponenten mit ihren Verantwortlichkeiten, deren Kommunikation über gut definierte Schnittstellen erfolgt.

Wenn Sie sich für dieses Thema mehr interessieren, empfehle ich das Buch Team Topologies von Matthew Skelton und Manuel Pais. Und wenn Sie Hilfe oder Beratung benötigen, wie Sie eine Reorganisation angehen können, können Sie mich hier kontaktieren.