Prawo Conway’a

W 1968 Melvin Conway, wtedy programista, postawił następującą tezę: „...organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations.”. W wolnym tłumaczeniu: organizacje które projektują systemy, budują rozwiązania, które są kopiami struktur komunikacyjnych tych organizacji. Albo inaczej – architektura budowanego rozwiązania będzie izomorficzna do struktury zespołu projektowego. Prawo to jest oparte na obserwacji, że – aby dwa moduły mogły się ze sobą komunikować to – ich projektanci i programiści muszą się ze sobą skomunikować. Dlatego struktura interfejsów systemu będzie odpowiadała strukturze komunikacji pomiędzy ludźmi, którzy te interfejsy projektują i implementują.

Przykłady

Załóżmy, że firma chce zbudować duży system S. Firma zatrudnia dostawcę X, aby jej ten system zbudował. Załóżmy, że dostawca X posiada 3 zespoły inżynierów E1, E2 i E3, która biorą udział w projekcie. Prawo Conway’a sugeruje, że zbudowane rozwiązanie będzie się składało z trzech podsystemów, każdy zbudowany przez jeden zespół inżynierów. A co istotniejsze, zbudowane interfejsy pomiędzy podsystemami (S1-S2, S1-S3, itd.) będą odzwierciedlać jakość i charakter komunikacji pomiędzy poszczególnymi grupami inżynierów.

Inny przykład: rozważmy dwu-osobowy zespół inżynierów IT, A i B. Powiedzmy, że A zaprojektował i zakodował klasę X. Później zespół odkrywa, że klasa X potrzebuje nowych funkcji. Jeśli nowe funkcjonalności będzie projektował i implementował inżynier A, to A najprawdopodobniej rozszerzy klasę X o te funkcje. Jeśli natomiast nowe funkcje będzie dodawał inżynier B, to B może się obawiać, że coś w klasie X zepsuje, więc zamiast zmieniać klasę X, utworzy nową klasę pochodną X2, w której B umieści nowe funkcje i która odziedziczy funkcje klasy X. W tym przykładzie ostateczny projekt zależy od tego, kto projektuje i implementuje rozwiązanie.

Wnioski

Wnioski wynikające z prawa Conway’a można zastosować w praktyce. Np. jeśli struktura organizacji projektu nie odzwierciedla ściśle architektury budowanego rozwiązania albo jeśli relacje pomiędzy elementami budowanego rozwiązania nie odzwierciedlają ściśle relacji pomiędzy częściami rozwiązania, to projekt najprawdopodobniej znajdzie się w kłopotach. Wniosek: w każdym projekcie należy się upewnić, że organizacja projektu jest kompatybilna / izomorficzna do architektury budowanego rozwiązania. Przykład z życia: Orbiter NASA Mars Climate rozbił się, że ponieważ jeden zespół (z USA) wykorzystywał swoje jednostki miary (np., cale, stopy i funty), podczas gdy innych zespół (z Europy) stosował jednostki metryczne.

Prawo Conway’a doczekało się różnych wersji. Jedną z bardziej znanych jest wersja Eric S Raymond’a, propagatora open source’u, współzałożyciela Open Source Initiative. Raymond powiedział, że organizacja oprogramowania i organizacja zespołu programistów będą przystające. Dla przykładu: jeśli masz cztery zespoły pracujące nad kompilatorem, otrzymasz kompilator 4-ro przebiegowy.

Podsumowanie

Z prawa Conway’a wynika, że struktura zespołu projektowego wpływa na architekturę rozwiązania. W organizacji tightly-coupled (np. wyspecjalizowane zespoły zatrudnione przez jedno przedsiębiorstwo, znajdujące się w jednym miejscu realizują projekt) problemy są rozwiązywane przez interakcje face-to-face. Deweloperzy jednego modułu mają informację o konstrukcji innych modułów. Teraz, nawet jeśli nie jest to wyraźna decyzja projektowa, to moduły stają się wyraźne bardziej tightly-coupled. W organizacji loosely-copled (np. zespoły realizujące projekt są rozproszone) komunikacja face-to-face jest rzadka. Większość programistów nigdy się nie spotyka. Ograniczenia w komunikacji pomiędzy deweloperami dają w efekcie mniej połączeń pomiędzy modułami a architektura rozwiązania jest bardziej modularna.

Jeśli zależy nam na takiej lub innej architekturze danego rozwiązania lub całego środowiska, wtedy przede wszystkim należy skonstruować izomorficzną do tej architektury organizację pracy w zespołach projektujących i implementujących rozwiązanie. Wtedy (najprawdopodobniej) osiągniemy zamierzony rezultat architektoniczny. Innymi słowy możemy wpływać na projektowaną architekturę poprzez konstruowanie struktury organizacyjnej projektującego ją zespołu/zespołów.

Należy jeszcze dodatkowo pamiętać, że architektura rozwiązania powstaje na początku projektu a później może się zmienić. Prawo Conway’a mówi nam, że w takiej sytuacji powinniśmy również zmienić strukturę organizacji projektu.

Źródła:

• M.E. Conway, How do Committees Invent?, 1969, http://www.melconway.com/research/committees.html
• A. MacCormack, J. Rusnak, C. Baldwin, Exploring the Duality between Product and Organizational Architectures: A Test of the ‘Mirroring’ Hypothesis, 2007, http://www.hbs.edu/research/pdf/08-039.pdf
• N. Nagappan, B. Murphy, V. Basili, The Influence of Organizational Structure On Software Quality: An Empirical Case Study, 2008, http://research.microsoft.com/pubs/70535/tr-2008-11.pdf