W tym czasie Harvard Business Review odrzucił jego oryginalną pracę na podstawie faktu, że nie udowodnił on swojej hipotezy. Niemniej jednak obserwacja ta stała się znana jako Prawo Conwaya, a zbiorowe doświadczenia zarówno moje, jak i moich kolegów, raz po raz potwierdzały prawdziwość tego stwierdzenia. Ale nie musisz wierzyć nam na słowo!
W „Exploring the Duality between Product and Organizational Architectures”, badanie przeprowadzone przez The Harvard Business School przeprowadziło analizę różnych baz kodów, aby sprawdzić, czy mogą udowodnić oryginalną hipotezę Conwaya stosowaną do systemów oprogramowania. W nim, wzięli wiele przykładów oprogramowania stworzonego do rozwiązywania tego samego celu (na przykład edytory tekstu, oprogramowanie do zarządzania finansami i bazami danych) i porównali bazy kodów stworzone przez luźno połączone zespoły open source i te stworzone przez ściśle połączone zespoły. Ich badania wykazały, że często zlokalizowane w jednym miejscu, skoncentrowane zespoły produktowe tworzyły oprogramowanie, które miało tendencję do tworzenia ściśle powiązanych, monolitycznych baz kodowych. Natomiast projekty open source zaowocowały bardziej modularnymi, zdekomponowanymi bazami kodu.
Organizacje od kilku lat rozumieją ten związek pomiędzy strukturą organizacyjną a tworzonym przez nie oprogramowaniem i przyjmują nowe struktury, aby osiągnąć pożądany rezultat. Na przykład Netflix i Amazon tworzą struktury wokół wielu małych zespołów, z których każdy jest odpowiedzialny za niewielką część całego systemu. Te niezależne zespoły mogą być właścicielami całego cyklu życia usług, które tworzą, dając im większy stopień autonomii niż jest to możliwe w przypadku większych zespołów z bardziej monolitycznymi bazami kodu. Te usługi z ich niezależnymi problemami mogą się zmieniać i ewoluować niezależnie od siebie, co skutkuje możliwością szybszego dostarczania zmian na produkcję. Jeśli te organizacje przyjęłyby większe rozmiary zespołów, większe monolityczne systemy, które by się pojawiły, nie dałyby im tej samej zdolności do eksperymentowania, adaptacji i ostatecznie utrzymywania zadowolonych klientów.
Możecie zauważyć napięcia w waszych własnych organizacjach, gdzie wasza struktura i oprogramowanie nie są w zgodzie. Być może widzieliście na przykład wyzwania związane z tym, że rozproszone zespoły próbują pracować na tej samej monolitycznej bazie kodu. W tym przypadku ścieżki komunikacji, o których wspomina Conway, kontrastują z samym kodem, gdzie pojedyncza baza kodowa wymaga drobnoziarnistej komunikacji, ale rozproszony zespół jest zdolny jedynie do komunikacji gruboziarnistej. Tam, gdzie pojawiają się takie napięcia, poszukiwanie możliwości podziału monolitycznych systemów wokół granic organizacyjnych często przynosi znaczące korzyści.
W poprzednich Radarach Technologicznych podkreślaliśmy rosnącą popularność Mikroserwisów, które są coraz częściej adoptowane przez organizacje poszukujące możliwości zwiększenia autonomii swoich zespołów i zwiększenia szybkości zmian. Artykuł Martina Fowlera i Jamesa Lewisa pogłębia ten temat, podkreślając fakt, że architektury te pozwalają organizacjom na znacznie większą elastyczność w dopasowywaniu architektury systemów do struktury zespołów, aby zapewnić, że prawo Conwaya działa dla Ciebie. W kolejnym wydaniu Tech Radaru omówimy odbicie rosnącego wpływu Microservices, od technologii infrastrukturalnych takich jak Packer czy Docker, po narzędzie do odkrywania usług Consul, czy mikro-kontenery takie jak popularny DropWizard czy całkiem nowy SpringBoot. Omówimy również sytuację odwrotną – organizacje zmieniające strukturę zespołu, aby dopasować ją do swoich systemów IT.
W pełni oczekujemy, że pojawi się więcej technik i technologii wspierających architektury mikroserwisowe, które będziemy śledzić w nadchodzących miesiącach. W międzyczasie, jeśli chcesz dowiedzieć się więcej, zapisz się na najnowszy Tech Radar, sprawdź artykuł Martina i Jamesa na temat mikroserwisów lub moją książkę od O’Reilly, Building Microservices.