Prawo Conwaya w kontekście transformacji DevOps

Prawo Conwaya brzmi:

“Każda organizacja, która projektuje system (rozumiany szeroko), stworzy projekt, który jest kopią struktury komunikacji w tej organizacji”

(eng. “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure)

Warto dodać, że im większa organizacja, tym dane zjawisko jest bardziej obserwowalne.

Jeśli dwa zespoły, które mają współpracować nad jednym systemem, to jedną z bardziej prawdopodobnych architektur, jaka powstanie, to dwa komponenty komunikujące się ze sobą po wspólnie ustalonym API.

Częściej nieświadomie niż świadomie zespoły będą optymalizować niedogodności związane z komunikacją między sobą. Mogą one oczywiście pracować na jednym kodzie źródłowym w jednym repozytorium, robić częste synchronizacje, rozwiązywać konflikty na poziomie merge’y itd. Jednak atrakcyjną alternatywą do tego będzie ustalenie, że każdy zespół stworzy swój komponent, a sposób komunikacji między tymi komponentami za pomocą API będzie kontraktem między zespołami. Rzeczy schowane za API są szczegółem implementacyjnym danego zespołu i są definiowane przez jego autonomię. Takie API można względnie łatwo pokryć testami automatycznymi, co jest dodatkową zaletą takiego podejścia.

Ten prosty przykład obrazuje jednak większe zjawiska w wystarczająco dużej skali. Jeśli mamy ludzi pracujących w silosach specjalizacyjnych (np. analitycy biznesowi, deweloperzy, testerzy, wdrożeniowcy), to optymalizacja komunikacji znajdzie swoją realizację w procesie dostarczania wartości na produkcję – będzie ona najprawdopodobniej etapowa i istnieje duże prawdopodobieństwo, że etapy będą odwzorowywać silosy. W ten sposób powstanie proces typowo waterfallowy: analiza - development - testy - wdrożenie. Architektura nie będzie obiektem optymalizacji, bo to nie ona będzie źródłem niedogodności związanej z komunikacją. Będzie nią proces. Istnieje jednak duże ryzyko, że organizacja skończy z monolityczną aplikacją z dużą ilością poukrywanych złożoności.

Alternatywnym podejściem jest dążenie do stworzenia organizacji opartej o autonomiczne zespoły z możliwie jak najszerszym zestawem kompetencji. W takim przypadku docelowa architektura może przypominać mikroserwisy (lub ogólniej tzw. loosely-coupled architecture), w którym dany zespół jest odpowiedzialny za dany mikroserwis. Tłumaczy to popularność tego typu architektury, modelowania Domain Driven Design itp.

Podsumowując, architektura i organizacja są ze sobą bardzo silnie powiązane. NIe jest możliwe prowadzenie rozważań tylko o jednej z nich.

Część II

Część dotyczyła natury prawa Conwaya: jak w architekturze systemu IT można dopatrywać się wzorców komunikacji w organizacji, która ten system tworzy. W ten sposób można wyjaśnić, dlaczego organizacje silosowe pracują najczęściej w waterfallowym procesie, efektem którego często jest architektura monolityczna. Z drugiej strony, organizacje stawiające na autonomiczne zespoły o szerokich kompetencjach, kończą najczęściej z architekturami mikroserwisowymi. Do tej pory były to rozważania o zabarwieniu teoretycznym. Jak zatem można wykorzystać świadomie splątanie architektury i kształtu organizacji?

Prawo Conway’a ma swoje konsekwencje podczas transformacji DevOps. Załóżmy, że mamy do czynienia z organizacją silosową, która do tej pory stworzyła monolityczną aplikację. Została podjęta decyzja, aby dokonać transformację DevOps, aby zwiększyć przepustowość organizacji i stabilność systemów, które ona tworzy. Aby to osiągnąć trzeba zorganizować zespoły wokół strumienia wartości. Zespoły te muszą mieć w sobie wszystkie możliwe kompetencje, by wziąć odpowiedzialność od początku do końca za to, czego doświadcza klient. 

Od czego zacząć? Istnieją dwa skrajne podejścia, dzięki którym łatwiej można zrozumieć rodzinę strategii hybrydowych.
Pierwsza opcja to przeorganizowanie zespołów, które niejako wyprzedza architekturę i w wyniku tego “zmusi” nowe zespoły do późniejszego refaktoringu do docelowej architektury. 
Druga opcja to za pomocą starej organizacji rozbić monolit na np. mikroserwisy i gdy nowa architektura będzie gotowa, dokonać zmiany kształtu zespołów rozbijając silosy na autonomiczne zespoły o szerokich kompetencjach.

Pierwsze podejście jest ryzykowne, ponieważ przy nieefektywnym przywództwie ludzie w organizacji mogą nie zrozumieć sensu zmiany, odczują dużo frustracji z pracy w teoretycznie autonomicznych zespołach, a w praktyce z architekturą na razie blokującą tę autonomię. Nowe zespoły będą początkowo zablokowane ograniczeniami wynikającymi z monolitu: konieczność deploy’owania pojedynczego artefaktu przez wszystkich, piekło merege’owania zmian pochodzących od wielu zespołów, które często nieświadome siebie tworzyły sprzeczne konstrukcje w kodzie, potrzeba wielu spotkań synchronizacyjnych itd. W efekcie, cała zmiana może doprowadzić do sytuacji, w której ludzie zaczną odchodzić z organizacji, a obecni pracownicy będą próbowali sobie radzić z transformacją poprzez ucieczkę w ironię i sarkazm na temat zmiany. Jest to ogromne ryzyko dla organizacji. Jeśli jednak czujesz, że przywództwo w organizacji jest silne i potrafi zapewnić spójność od wysokopoziomowej wizji po niskopoziomowe poczucie właścicielstwa wśród ludzi, to jest to droga warta rozważenia. W innym wypadku odradzam tej strategii.

Alternatywnym podejściem jest próba refaktoringu architektury za pomocą starej organizacji. Gdy architektura będzie już w pożądanym kształcie, dopiero następuje reorganizacja zespołów. Jest to na pewno bezpieczniejsze podejście, nie generujące zazwyczaj tylu frustracji wśród ludzi. Może to być co najwyżej dyskomfort w konieczności deploy’owania większej ilości komponentów. Ludzie mogą jednak dostrzec szybko zalety tego, dzięki zmniejszającej się liczbie zależności między rozwijanymi funkcjonalnościami. Gdy architektura jest gotowa, dokonywana jest zmiana organizacyjna. To podejście wydaje się być drogą dłuższą, ale bezpieczniejszą dla organizacji.

Od kontekstu Twojej organizacji zależy, którą drogę lub ich hybrydę, wybierzesz.

Jest jeszcze jeden wniosek płynący z prawa Conway’a w kontekście transformacji. Transformacja DevOps to bardzo często też transformacja zwinna. Proszę uważajcie na Agile Coachów, którzy chcą zmieniać proces i kształt zespołów, a bagatelizują kwestię architektury systemów, które te zespoły tworzą. Ryzyko niepowodzenia transformacji w takim przypadku jest bardzo wysokie.