Die Teamarchitektur (Organisationsstruktur) beeinflusst direkt die Architektur von Unternehmens-IT-Systemen. Dies wird mit "Conways Gesetz" in Verbindung gebracht: Ein System, das von einer Organisation entwickelt wird, spiegelt die Kommunikationsstrukturen der Teams wider.
Wenn man ein System unter Berücksichtigung von cross-funktionalen Teams entwirft, erhält man die Möglichkeit, Verantwortung auf Domänen zu verteilen, Schnittstellen zu minimieren und architektonische Abhängigkeiten zu reduzieren.
Beispiel für die Bildung von Verantwortungsbereichen und architektonischen Grenzen:
In jeder Domäne ist ein eigenes Team verantwortlich, die API-Verträge sind maximal formalisiert, die Interaktion erfolgt über öffentliche oder Ereignisschnittstellen. Dies vereinfacht die Skalierung der Entwicklung und beschleunigt die Reaktion auf Veränderungen.
Wichtige Merkmale:
Frage: Kann einem Team die Wartung mehrerer großer Domänen gleichzeitig übertragen werden?
In großen Systemen – nein, das ist mit Überlastung und Engpässen in der Kommunikation verbunden. Es ist besser, Teams nach dem Prinzip "eine Domäne – ein Team" zu bilden.
Frage: Müssen die Grenzen von Mikrodiensten immer mit den Grenzen der Teams übereinstimmen?
Idealerweise – ja, aber in der Praxis ist das nicht immer möglich. Dennoch sollte man danach streben, um die Kommunikation zu optimieren und die Anzahl der internen Integrationen zu reduzieren.
Frage: Ist es wichtig, architektonische Entscheidungen zwischen Teams abzustimmen, wenn sie völlig unabhängig sind?
Ja, es ist entscheidend wichtig! Um einen "Technologiedschungel" zu vermeiden und Integrationsstandards aufrechtzuerhalten, ist eine architektonische Abstimmung notwendig, beispielsweise durch Architekturkomitees oder -gilden.