Architektura zespołów (struktura organizacyjna) bezpośrednio wpływa na architekturę korporacyjnych systemów IT. Jest to powiązane z "prawem Conwaya": system opracowywany przez organizację odzwierciedla struktury komunikacji zespołów.
Projektując system z uwzględnieniem zespołów cross-functional, pojawia się możliwość rozdzielenia odpowiedzialności w różnych dziedzinach, minimalizacji punktów przecięcia i zmniejszania zależności architektonicznych.
Przykład wyodrębniania obszarów odpowiedzialności i granic architektonicznych:
W każdej dziedzinie odpowiada własny zespół, kontrakty API są maksymalnie sformalizowane, współpraca odbywa się za pośrednictwem interfejsów publicznych lub zdarzeniowych. Ułatwia to skalowanie rozwoju i przyspiesza reakcję na zmiany.
Kluczowe cechy:
Pytanie: Czy można powierzać jednemu zespołowi utrzymanie od razu kilku dużych dziedzin?
W dużych systemach — nie, to grozi przeciążeniem i wąskimi gardłami w komunikacji. Lepiej wydzielać zespoły według zasady "jedna dziedzina — jeden zespół".
Pytanie: Czy granice mikrousług zawsze powinny pokrywać się z granicami zespołów?
Idealnie — tak, ale w praktyce nie zawsze jest to możliwe. Jednak dążenie do tego jest ważne dla optymalizacji komunikacji i zmniejszenia liczby integracji między usługami.
Pytanie: Czy ważne jest uzgadnianie decyzji architektonicznych między zespołami, jeśli są one całkowicie niezależne?
Tak, kluczowe! W celu zapobiegania "zoo technologii" i utrzymania standardów integracyjnych niezbędne jest architektoniczne uzgodnienie, na przykład poprzez komitety architektoniczne lub gildie.