Im Jahr 1968 gelangte der Informatiker Melvin Conway zu der Feststellung: “Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden”. Dieses nach seinem Schöpfer benannte Gesetz von Conway “basiert auf der Überlegung, dass für die Definition der Schnittstellen zwischen getrennten Softwaremodulen zwischenmenschliche Kommunikation notwendig ist. Daher haben die Kommunikationsstrukturen der Organisationen einen großen Einfluss auf die Strukturen dieser Schnittstellen”[1]Wikipedia[2]Vgl. dazu: “Im Idealfall gelingt es, ein Modul so zu gestalten, dass es über Schnittstellen weiterhin störungsfrei mit den alten Komponenten kommunizieren, interagieren kann. Die, wenn man so will, … Continue reading.
Das Gesetz von Conway wurde durch verschiedene Studien bestätigt. So konnten Rebecca M. Henderson und Kim B. Clark belegen, dass Produktinnovationen, welche die Architektur des Produktes ändern, eine Änderung der Wissensarchitektur und Firmenstruktur voraussetzen[3]Architectural Innovation. The Reconfiguration of Existing Product Technologies and the Failure of Established Firms[4]Vgl. dazu: Über den Stilwandel in der Softwareentwicklung.
Unabhängig davon machte Frederick P. Brooks ähnliche Beobachtungen, von denen er in seinem Buch The Mythical Man Month berichtet.
Laut Brooks entsteht ein großer Teil der Kosten durch die Kommunikation zwischen den Beteiligten. Ein System sollte daher von möglichst wenigen Köpfen gebaut werden. “Tatsächlich zeigen die meisten Erfahrungen mit großen Programmiersystemen, dass der Bruteforce-Ansatz kostspielig, langsam und ineffizient ist und Systeme hervorbringt, die konzeptionell nicht integriert sind. Das Dilemma ist ein grausames. Aus Gründen der Effizienz und der konzeptionellen Integrität zieht man es vor, wenn einige wenige gute Köpfe das Design und die Konstruktion übernehmen. Bei großen Systemen möchte man jedoch eine Möglichkeit haben, eine beträchtliche Menge von Arbeitskräften einzusetzen, damit das Produkt rechtzeitig erscheinen kann“[5]Vgl. dazu: Herbert A. Simon in Die Wissenschaft vom Künstlichen: “Bei der Organisation eines Entwurfprozesses ist ferner zu entscheiden, wie weit die Entwicklung möglicher Subsysteme vorangetrieben … Continue reading.
Der Schweizer Wirtschaftshistoriker David Gugerli hält mit Blick auf das gescheiterte Transformationsprojekt Union Bank Information System Concept (Ubisco) der damaligen Schweizerischen Bankgesellschaft fest: “Auf dem Weg in den digitalen Raum gab es, das zeigte Ubisco ebenso wie viele andere Großprojekte, keine Abkürzungen. Vielleicht hätte das Projekt eine Chance gehabt, wenn der Aufwand von Anfang an richtig eingeschätzt worden wäre. Ein Blick darauf, was andere Banken bei der Verlagerung ihrer Transaktionen in den digitalen Raum gelernt haben, weist jedoch in eine andere Richtung: Bankgeschäfte konnte man in den 1970er Jahren nur dann in einem umfassenden Sinn in den digitalen Raum verlagern, wenn die Grundstrukturen einer Bank neu überdacht wurden”[6]Wie die Bank in den Computer kam[7]Wegweisend ist auch der Beitrag A Relational Model of Data for Large Shared Data Banks von Edgar F. Codd. Danach setzte der Siegeszug der (relationalen) Datenbanken ein, der bis heute anhält. Das … Continue reading.
Anna-Lena Schwalm macht unter Verweis der Ergebnisse der Cloud Native Studie 2022 „Viel mehr als nur Technologie“ auf die Gültigkeit des Conway’schen Gesetzes aufmerksam: “Conways Law ist ein mächtiges Konzept, welches bislang noch von den wenigsten verinnerlicht wurde. Es beschreibt, wie tief die existierende Kommunikationsstruktur eines Unternehmens mit den Tätigkeiten oder dem Endprodukt des Unternehmens verbunden ist. Um nun also von einer flexiblen IT-Infrastruktur zu profitieren und Systeme schrittweise verändern zu können, müssen Unternehmen und deren Kommunikationsstrukturen ebenso schlank und anpassungsfähig aufgestellt sein. Bei Projektstart sollten die beteiligten Stakeholder sowie Schnittstellen klar identifiziert werden, sodass wirklich die Entscheidungen getroffen werden, die sicherstellen, dass im Ergebnis das richtige System entspringt”[8]Conways Law ─ oder warum die Unternehmensstruktur die IT-Infrastruktur determiniert.
References
| ↑1 | Wikipedia |
|---|---|
| ↑2 | Vgl. dazu: “Im Idealfall gelingt es, ein Modul so zu gestalten, dass es über Schnittstellen weiterhin störungsfrei mit den alten Komponenten kommunizieren, interagieren kann. Die, wenn man so will, Kür ist dann vollzogen, wenn Mikroservices und DevOps Hand in Hand gehen. DevOps bezeichnen den Zusammenschluss von Entwicklung und Betrieb. Die Verantwortung für Entwicklung und Betrieb fällt damit zusammen, die Abstimmung erfolgt schneller”, in: Über den Stilwandel in der Softwareentwicklung |
| ↑3 | Architectural Innovation. The Reconfiguration of Existing Product Technologies and the Failure of Established Firms |
| ↑4 | Vgl. dazu: Über den Stilwandel in der Softwareentwicklung |
| ↑5 | Vgl. dazu: Herbert A. Simon in Die Wissenschaft vom Künstlichen: “Bei der Organisation eines Entwurfprozesses ist ferner zu entscheiden, wie weit die Entwicklung möglicher Subsysteme vorangetrieben wird, bevor man den koordinierenden Gesamtentwurf entwickelt; oder umgekehrt, wie weit der globale Entwurf gediehen sein muss, bevor verschiedene Komponenten, oder mögliche Komponenten, entwickelt werden können. .. Vor denselben Entscheidungen steht ein Programmierer, wenn er sich von der globalen Struktur eines Programms zu den Subroutinen hinunter – oder von den Subroutinen zum koordinierenden Hauptentwurf hinaufarbeitet”. |
| ↑6 | Wie die Bank in den Computer kam |
| ↑7 | Wegweisend ist auch der Beitrag A Relational Model of Data for Large Shared Data Banks von Edgar F. Codd. Danach setzte der Siegeszug der (relationalen) Datenbanken ein, der bis heute anhält. Das Unternehmen Oracle, nach Microsoft der zweitgrößte Softwarehersteller der Welt, verdankt seinen Erfolg vorwiegend der Datenbanktechnologie. IBM, Arbeitgeber von Edgar F. Codd, zählt auf dem Gebiet der Datenbanktechnologie ebenfalls zu den führenden Anbietern.
Von großem Nutzen waren die relationalen Datenbanken für die Unternehmen: “Durch die Anwendung der neuen ars combinatoria, die von relationalen Datenbanken offeriert wurden, versprach der Computer nun auch die unternehmensinternen Transaktionskosten zu senken. Selbst dem mittleren Management konnten in absehbarer Zeit zu tiefen Abfragekosten Quervergleiche über Tabellen- und Abteilungsgrenzen hinweg möglich gemacht werden. Dass dieses Angebot in eine Zeit fiel, in der die Restrukturierung von ganzen Unternehmungen zum alltäglichen Problem geworden war, erhöhte die Attraktivität relationaler Datenbanktechnik in den späten 1970er und den frühen 1980er Jahren dramatisch, insbesondere als mit Oracle auch auf kleineren Rechnern relationale Datenbanksysteme implementierbar geworden waren”, in: Die Welt als Datenbank: Zur Relation von Softwareentwicklung, Abfragetechnik und Deutungsautonomie |
| ↑8 | Conways Law ─ oder warum die Unternehmensstruktur die IT-Infrastruktur determiniert |