Im Jahr 1968 gelang­te der Infor­ma­ti­ker Mel­vin Con­way zu der Fest­stel­lung: “Orga­ni­sa­tio­nen, die Sys­te­me ent­wer­fen, […] sind gezwun­gen, Ent­wür­fe zu erstel­len, die die Kom­mu­ni­ka­ti­ons­struk­tu­ren die­ser Orga­ni­sa­tio­nen abbil­den”. Die­ses nach sei­nem Schöp­fer benann­te Gesetz von Con­way “basiert auf der Über­le­gung, dass für die Defi­ni­ti­on der Schnitt­stel­len zwi­schen getrenn­ten Soft­ware­mo­du­len zwi­schen­mensch­li­che Kom­mu­ni­ka­ti­on not­wen­dig ist. Daher haben die Kom­mu­ni­ka­ti­ons­struk­tu­ren der Orga­ni­sa­tio­nen einen gro­ßen Ein­fluss auf die Struk­tu­ren die­ser Schnitt­stel­len”^[1]Wiki­pe­dia^[2]Vgl. dazu: “Im Ide­al­fall gelingt es, ein Modul so zu gestal­ten, dass es über Schnitt­stel­len wei­ter­hin stö­rungs­frei mit den alten Kom­po­nen­ten kom­mu­ni­zie­ren, inter­agie­ren kann. Die, wenn man so will, … Con­ti­nue rea­ding.

Das Gesetz von Con­way wur­de durch ver­schie­de­ne Stu­di­en bestä­tigt.  So konn­ten Rebec­ca M. Hen­der­son und Kim B. Clark bele­gen, dass Pro­dukt­in­no­va­tio­nen, wel­che die Archi­tek­tur des Pro­duk­tes ändern, eine Ände­rung der Wis­sens­ar­chi­tek­tur und Fir­men­struk­tur vor­aus­set­zen^[3]Archi­tec­tu­ral Inno­va­ti­on. The Recon­fi­gu­ra­ti­on of Exis­ting Pro­duct Tech­no­lo­gies and the Fail­ure of Estab­lished Firms^[4]Vgl. dazu: Über den Stil­wan­del in der Soft­ware­ent­wick­lung.

Unab­hän­gig davon mach­te Fre­de­rick P. Brooks ähn­li­che Beob­ach­tun­gen, von denen er in sei­nem Buch The Mythi­cal Man Month berichtet.

Laut Brooks ent­steht ein gro­ßer Teil der Kos­ten durch die Kom­mu­ni­ka­ti­on zwi­schen den Betei­lig­ten. Ein Sys­tem soll­te daher von mög­lichst weni­gen Köp­fen gebaut wer­den. “Tat­säch­lich zei­gen die meis­ten Erfah­run­gen mit gro­ßen Pro­gram­mier­sys­te­men, dass der Bru­teforce-Ansatz kost­spie­lig, lang­sam und inef­fi­zi­ent ist und Sys­te­me her­vor­bringt, die kon­zep­tio­nell nicht inte­griert sind. Das Dilem­ma ist ein grau­sa­mes. Aus Grün­den der Effi­zi­enz und der kon­zep­tio­nel­len Inte­gri­tät zieht man es vor, wenn eini­ge weni­ge gute Köp­fe das Design und die Kon­struk­ti­on über­neh­men. Bei gro­ßen Sys­te­men möch­te man jedoch eine Mög­lich­keit haben, eine beträcht­li­che Men­ge von Arbeits­kräf­ten ein­zu­set­zen, damit das Pro­dukt recht­zei­tig erschei­nen kann“^[5]Vgl. dazu: Her­bert A. Simon in Die Wis­sen­schaft vom Künst­li­chen: “Bei der Orga­ni­sa­ti­on eines Ent­wurf­pro­zes­ses ist fer­ner zu ent­schei­den, wie weit die Ent­wick­lung mög­li­cher Sub­sys­te­me vor­an­ge­trie­ben … Con­ti­nue rea­ding.

Der Schwei­zer Wirt­schafts­his­to­ri­ker David Guger­li hält mit Blick auf das geschei­ter­te Trans­for­ma­ti­ons­pro­jekt Uni­on Bank Infor­ma­ti­on Sys­tem Con­cept (Ubis­co) der dama­li­gen Schwei­ze­ri­schen Bank­ge­sell­schaft fest: “Auf dem Weg in den digi­ta­len Raum gab es, das zeig­te Ubis­co eben­so wie vie­le ande­re Groß­pro­jek­te, kei­ne Abkür­zun­gen. Viel­leicht hät­te das Pro­jekt eine Chan­ce gehabt, wenn der Auf­wand von Anfang an rich­tig ein­ge­schätzt wor­den wäre. Ein Blick dar­auf, was ande­re Ban­ken bei der Ver­la­ge­rung ihrer Trans­ak­tio­nen in den digi­ta­len Raum gelernt haben, weist jedoch in eine ande­re Rich­tung: Bank­ge­schäf­te konn­te man in den 1970^er Jah­ren nur dann in einem umfas­sen­den Sinn in den digi­ta­len Raum ver­la­gern, wenn die Grund­struk­tu­ren einer Bank neu über­dacht wur­den”^[6]Wie die Bank in den Com­pu­ter kam^[7]Weg­wei­send ist auch der Bei­trag A Rela­tio­nal Model of Data for Lar­ge Shared Data Banks von Edgar F. Codd. Danach setz­te der Sie­ges­zug der (rela­tio­na­len) Daten­ban­ken ein, der bis heu­te anhält. Das … Con­ti­nue rea­ding.

Anna-Lena Schwalm macht unter Ver­weis der Ergeb­nis­se der Cloud Nati­ve Stu­die 2022 „Viel mehr als nur Tech­no­lo­gie“ auf die Gül­tig­keit des Conway’schen Geset­zes auf­merk­sam: “Con­ways Law ist ein mäch­ti­ges Kon­zept, wel­ches bis­lang noch von den wenigs­ten ver­in­ner­licht wur­de. Es beschreibt, wie tief die exis­tie­ren­de Kom­mu­ni­ka­ti­ons­struk­tur eines Unter­neh­mens mit den Tätig­kei­ten oder dem End­pro­dukt des Unter­neh­mens ver­bun­den ist. Um nun also von einer fle­xi­blen IT-Infra­struk­tur zu pro­fi­tie­ren und Sys­te­me schritt­wei­se ver­än­dern zu kön­nen, müs­sen Unter­neh­men und deren Kom­mu­ni­ka­ti­ons­struk­tu­ren eben­so schlank und anpas­sungs­fä­hig auf­ge­stellt sein. Bei Pro­jekt­start soll­ten die betei­lig­ten Stake­hol­der sowie Schnitt­stel­len klar iden­ti­fi­ziert wer­den, sodass wirk­lich die Ent­schei­dun­gen getrof­fen wer­den, die sicher­stel­len, dass im Ergeb­nis das rich­ti­ge Sys­tem ent­springt”^[8]Con­ways Law ─ oder war­um die Unter­neh­mens­struk­tur die IT-Infra­struk­tur deter­mi­niert.