Harvard Business Review hylkäsi hänen alkuperäisen artikkelinsa sillä perusteella, että hän ei ollut todistanut hypoteesiaan. Siitä huolimatta tämä havainto on tullut tunnetuksi Conwayn lakina, ja sekä kollegoideni että minun kollektiiviset kokemukset ovat kerta toisensa jälkeen vahvistaneet tämän väitteen totuudenmukaisuutta. Mutta sinun ei tarvitse uskoa sanaamme!
The Harvard Business Schoolin tutkimuksessa ”Exploring the Duality between Product and Organizational Architectures” (Tutkitaan tuote- ja organisaatioarkkitehtuurien välistä kaksinaisuutta) analysoitiin erilaisia koodikantoja sen selvittämiseksi, pystyttiinkö Conwayn alkuperäinen hypoteesi todistamaan ohjelmistojärjestelmiin sovellettuna. Tutkimuksessa otettiin useita esimerkkejä ohjelmistoista, jotka oli luotu samaa tarkoitusta varten (esimerkiksi tekstinkäsittely-, taloushallinto- ja tietokantaohjelmistot), ja verrattiin avoimen lähdekoodin tiimien luomia koodipohjia löyhästi kytkeytyneisiin ja tiukasti kytkeytyneisiin tiimeihin. Heidän tutkimuksessaan havaittiin, että usein samaan paikkaan sijoitetut, keskittyneet tuotetiimit loivat ohjelmistoja, joilla oli enemmän taipumusta tiukasti kytkettyihin, monoliittisiin koodipohjiin. Kun taas avoimen lähdekoodin projektit tuottivat enemmän modulaarisia, hajanaisia koodipohjia.
Organisaatiot ovat jo muutaman vuoden ajan ymmärtäneet tämän yhteyden organisaatiorakenteen ja luomiensa ohjelmistojen välillä, ja ne ovat ottaneet käyttöön uusia rakenteita saavuttaakseen haluamansa lopputuloksen. Esimerkiksi Netflix ja Amazon rakentuvat useiden pienten tiimien ympärille, joista kukin vastaa pienestä osasta kokonaisjärjestelmää. Nämä itsenäiset tiimit voivat omistaa luomiensa palveluiden koko elinkaaren, mikä antaa niille suuremman autonomian kuin suuremmille tiimeille, joilla on monoliittisempi koodipohja. Nämä itsenäiset palvelut voivat muuttua ja kehittyä toisistaan erillään, minkä ansiosta muutokset voidaan toimittaa tuotantoon nopeammin. Jos nämä organisaatiot olisivat ottaneet käyttöön suurempia tiimikokoja, syntyneet suuremmat monoliittiset järjestelmät eivät olisi antaneet niille samanlaista kykyä kokeilla, sopeutua ja lopulta pitää asiakkaat tyytyväisinä.
Osaatte ehkä havaita omassa organisaatiossanne jännitteitä, joissa rakenne ja ohjelmistot eivät ole linjassa keskenään. Olet ehkä nähnyt esimerkiksi haasteita, joita liittyy siihen, kun hajautetut tiimit yrittävät työskennellä saman monoliittisen koodipohjan parissa. Tässä Conwayn mainitsemat viestintäväylät ovat ristiriidassa itse koodin kanssa, jossa yhtenäinen koodipohja vaatii hienojakoista viestintää, mutta hajautettu tiimi kykenee vain karkearakeiseen viestintään. Kun tällaisia jännitteitä ilmenee, etsimällä mahdollisuuksia monoliittisten järjestelmien jakamiseen organisaatiorajojen ympärille saadaan usein merkittäviä etuja.
Edellisissä Teknologiatutkat-tutkimuksissa olemme korostaneet mikropalveluiden kasvavaa suosiota, sillä yhä useammat organisaatiot ottavat ne käyttöönsä halutessaan parantaa tiimiensä autonomiaa ja lisätä muutoksen nopeutta. Martin Fowlerin ja James Lewisin artikkelissa syvennytään aiheeseen syvällisemmin ja korostetaan, että nämä arkkitehtuurit antavat organisaatioille paljon enemmän joustavuutta sovittaa järjestelmiensä arkkitehtuuri tiimiensä rakenteeseen, jotta Conwayn laki toimisi. Tech Radarin seuraavassa numerossa käsittelemme mikropalveluiden kasvavan vaikutuksen heijastumista Packerin tai Dockerin kaltaisesta infrastruktuuriteknologiasta Consulin kaltaiseen palveluhavaintotyökaluun tai suositun DropWizardin tai melko uuden SpringBootin kaltaisiin mikrokontteihin. Keskustelemme myös kääntöpuolesta – organisaatioista, jotka muuttavat tiimirakennettaan IT-järjestelmiinsä sopivaksi.
Odotamme täysin, että mikropalveluarkkitehtuurien mahdollistamiseksi syntyy lisää tekniikoita ja niitä tukevaa teknologiaa, ja tulemme seuraamaan näitä tulevina kuukausina. Sillä välin, jos haluat tietää lisää, tilaa uusin Tech Radar, tutustu Martinin ja Jamesin mikropalveluja käsittelevään artikkeliin tai O’Reillyn kirjaan Building Microservices.