imported>SchlurcherBot: Bot: http → https

2025-03-13T21:17:13Z

Bot: http → https

Neue Seite

Das '''Gesetz von Conway''' ist eine nach dem US-amerikanischen [[Informatiker]] [[Melvin Conway|Melvin Edward Conway]] benannte Beobachtung, dass die Arbeitsergebnisse von Systemen durch die [[Kommunikationsstruktur]]en der sie umsetzenden Organisationen vorbestimmt sind. Es wurde von Conway 1968 folgendermaßen formuliert:

{{Zitat
|Text=Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.
|Sprache=en
|Autor=Melvin E. Conway
|Quelle=
|Übersetzung=Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.
|ref=<ref name="Conway">{{Literatur |Autor=Melvin E. Conway |Hrsg=F. D. Thompson Publications, Inc. |Titel=How Do Committees Invent? |Sammelwerk=Datamation |Band=14 |Nummer=5 |Datum=1968-04 |Seiten=28–31 |Sprache=en |Online=https://www.melconway.com/research/committees.html |Abruf=2012-09-25}}</ref>}}

Das 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.

== Studien ==
Eine Studie der [[Harvard Business School]] kam zu dem Schluss, dass es starke Hinweise für die [[Korrektheit (Logik)|Korrektheit]] des Gesetzes von Conway gibt. Bei allen von ihnen untersuchten 12 Produkten aus 5 unterschiedlichen Anwendungsgebieten (Finanzmanagement, Textverarbeitung, Tabellenkalkulation, Betriebssystem, Datenbanksystem) korrelierte die [[Kopplung (Organisationstheorie)|Kopplung]] der sie entwickelnden Organisationen mit der [[Modularität]] der Produkte.<ref>{{Literatur |Autor=Alan MacCormack, John Rusnak, Carliss Baldwin |Hrsg=Harward Business School |Titel=Exploring the Duality between Product and Organizational Architectures |TitelErg=A Test of the “Mirroring” Hypothesis |Datum= |Sprache=en |Online=https://www.hbs.edu/research/pdf/08-039.pdf |Abruf=2012-09-25}}</ref>

Weitere Studien konnten ebenso eine [[Relation (Philosophie)|Relation]] zwischen der Architektur eines Produktes und den Charakteristiken der es umsetzenden Organisation belegen:
* Eine Microsoft-Research-Studie errechnete aus der Komplexität der mit der Entwicklung von [[Microsoft Windows Vista]] betrauten Organisationseinheiten von Microsoft die Komplexität und Fehlerquote von Windows Vista.<ref>{{Literatur |Autor=Nachiappan Nagappan, Brendan Murphy, Victor Basili |Hrsg=Microsoft Research |Titel=The Influence of Organizational Structure On Software Quality |TitelErg=An Empirical Case Study |Verlag=Association for Computing Machinery, Inc. |Datum=2008-01 |Sprache=en |Online=https://research.microsoft.com/apps/pubs/default.aspx?id=70535 |Abruf=2012-09-25}}</ref>
* Rebecca M. Henderson und Kim B. Clark konnten belegen, dass Produktinnovationen, welche die Architektur des Produktes ändern, eine Änderung der Wissensarchitektur und Firmenstruktur benötigen.<ref>{{Literatur |Autor=Rebecca M. Henderson, Kim B. Clark |Hrsg=Cornell University |Titel=Architectural Innovation |TitelErg=The Reconfiguration of Existing Product Technologies and the Failure of Established Firms |Sammelwerk=Administrative Sciences Quarterly |WerkErg=Technology, Organizations, and Innovation |Band=35 |Nummer=1 |Datum=1990-03 |Seiten=9–30 |Sprache=en |Online=[https://web.archive.org/web/20160304211248/http://www.edegan.com/pdfs/Henderson%20Clark%20%281990%29%20-%20Architectural%20Innovation.pdf web.archive.org] |Format=PDF |KBytes=2500 |Abruf=2021-11-01}}</ref>
* James D. Herbsleb und Rebecca E. Grinter kamen zu dem Schluss, dass die Arbeit an einem modularisierten System derart verteilt werden sollte, dass die Trennung der Entwicklung der Aufteilung der Module entspricht. Umgekehrt sollte die Entwicklung nur dann aufgeteilt werden, wenn die zu entwickelnden Produkte (oder Produktteile) gut verstanden werden, Pläne, Prozesse und Schnittstellen etabliert und stabil sind.<ref>{{Literatur |Autor=James. D. Herbsleb, Rebecca. E. Grinter |Hrsg=Bell Laboratories, Lucent Technologies |Titel=Splitting the Organization and Integrating the Code |TitelErg=Conway’s Law Revisited |Sammelwerk=ICSE '99 Proceedings of the 21st international conference on Software engineering |Verlag=ACM |Ort=New York |Datum=1999 |ISBN=1-58113-074-0 |Seiten=85–95 |Sprache=en |Online=https://herbsleb.org/web-pubs/pdfs/herbsleb-splitting-1999.pdf |Abruf=2012-10-05 |DOI=10.1145/302405.302455}}</ref>

== Beispiele ==
Angenommen, ein Unternehmen wird mit der Umsetzung eines großen Softwaresystems beauftragt. Das beauftragte Unternehmen hat drei Entwicklergruppen, E1, E2 und E3, die in dem Projekt zusammenarbeiten. Das Gesetz von Conway besagt nun, dass das entwickelte Softwaresystem wahrscheinlich aus drei großen Subsystemen S1, S2 und S3 bestehen wird, die in einer jeweils anderen Entwicklergruppe umgesetzt werden. Wichtiger noch, die Qualität und Art der Schnittstellen zwischen den Subsystemen (S1–S2, S1–S3, S2–S3) werden der Qualität und Art der zwischenmenschlichen Kommunikation zwischen den entsprechenden Entwicklergruppen (E1–E2, E1–E3, E2–E3) entsprechen.

Dasselbe gilt auch im kleineren Rahmen: Angenommen, der Softwareentwickler E1 hat die [[Klasse (Programmierung)|Klasse]] K1 für die Funktionalität F1 umgesetzt. Später soll die Funktionalität F1 um eine ähnliche Funktionalität F2 erweitert werden. Setzt der Softwareentwickler E1 diese Funktionalität um, so wird er einfach die Klasse K1 um diese Funktionalität erweitern. Setzt ein Softwareentwickler E2 aus einer anderen Gruppe diese Funktionalität um, so wird er wahrscheinlich befürchten, die bestehende Funktionalität zu beeinträchtigen, und daher die Funktionalität F2 in einer (Sub-)Klasse K2 umsetzen. Das Design der Applikation ist daher hochgradig davon abhängig, wer die Funktionalität umsetzt.

=== Beispiel für Systemversagen ===
Ein Beispiel für das Scheitern eines Systems, das durch das Gesetz von Conway beschrieben werden kann, ist der Absturz des [[Mars Climate Orbiter]]s. Er wurde dadurch verursacht, dass das Entwicklungsteam von [[Lockheed Martin]] in der Navigationssoftware das [[Angloamerikanisches Maßsystem|angloamerikanische Maßsystem]], das [[National Aeronautics and Space Administration|NASA]]-Entwicklungsteam hingegen das [[Internationales Einheitensystem|internationale Einheitensystem]] für die Berechnungen der Steuerung der Sonde zur Erreichung der vorgesehenen Umlaufbahn um den Mars verwendete.<ref>{{Literatur |Autor=Dieter Masak |Titel=IT-Alignment: IT-Architektur und Organisation |Verlag=Springer Science & Business Media |Datum=2006-07-18 |ISBN=978-3-540-31153-9 |Online=https://books.google.fr/books?id=CCXK0R5B_uoC&pg=PA239&dq=%22Conway%27s+law%22+mars&hl=da&sa=X&ei=gSKaULflNYOp0AXvjIGwCQ&redir_esc=y |Abruf=2022-09-14}}</ref><ref>{{Internetquelle |url=https://hillside.net/plop/2010/papers/son.pdf |titel=Framework Engineering |abruf=2022-09-14}}</ref> Von NASA-Seite wurde der Absturz allerdings weniger dem Fehler selbst, als dem Versagen der Kontrollmechanismen zugeschrieben.<ref>{{Internetquelle |url=http://mars.jpl.nasa.gov/msp98/news/mco990930.html |titel=Mars Climate Orbiter Team Finds Likely Cause Of Loss |datum=2006-08-24 |abruf=2022-09-14 |archiv-url=https://web.archive.org/web/20060824032413/http://mars.jpl.nasa.gov/msp98/news/mco990930.html |archiv-datum=2006-08-24 |offline= |archiv-bot=2022-11-08 01:34:07 InternetArchiveBot }}</ref>

== Ähnliche Erkenntnisse ==
[[Frederick P. Brooks]] bietet in seinem Buch ''[[Vom Mythos des Mann-Monats|The Mythical Man Month]]'' im Kapitel „Why did the (mythical) [[Turmbau zu Babel|Tower of Babel]] Fail?“ die Analogie, dass trotz klarer Zielvorstellung, genügend Personal, Rohstoffen und Zeit, sowie ausgereifter Technologie, Projekte an Kommunikationsproblemen und den daraus resultierenden Organisationsveränderungen scheitern können. Brooks stellt weiter fest, dass sich bei mangelnder Kommunikation zwischen Teams in der Softwareentwicklung funktionelle oder terminliche Misserfolge ergeben.<ref>{{Literatur |Autor=Frederick P. Brooks |Titel=Vom Mythos des Mann-Monats |TitelErg=Essays über Software-Engineering |Verlag=Addison-Wesley |Ort=Bonn |Datum=1987 |ISBN=3-925118-09-8 |Sprache=en |Originaltitel=The Mythical Man Month: Essays on Software Engineering}}</ref>

James O. Coplien und Neil B. Harrison vertreten in ihrem Buch ''Organizational Patterns of Agile Software Development'' die Ansicht, dass ein Projekt problematisch umzusetzen sei, wenn die Aufteilung der es umsetzenden Organisation (z. B. in Teams, Abteilungen oder Unterabteilungen) nicht den wichtigsten Teilen des umzusetzenden Produktes, und die Beziehungen zwischen den Organisationsteilen nicht den Beziehungen zwischen den Produktteilen entsprächen. Darum sei es wichtig, die Organisation kompatibel mit der Produktarchitektur zu machen.<ref>{{Literatur |Autor=James O. Coplien, Neil B. Harrison |Titel=Organizational Patterns of Agile Software Development |Verlag=Prentice Hall International |Datum=2004 |ISBN=978-0-13-146740-8}}</ref>

== Grüne-Wiese-Ansatz ==
Um für das umzusetzende Produkt geeignete Kommunikationsstrukturen zu bekommen, und dadurch gemäß dem Gesetz von Conway geeignete Produktmodule zu bekommen, schlägt Melvin Conway folgenden „Grüne-Wiese-Ansatz“ ({{enS|clean slate approach}}) vor:<ref>{{Literatur |Autor=David Dikel, David Kane |Titel=Conway’s Law Revisited |TitelErg=Successfully Aligning Enterprise Architecture |Sammelwerk=informIT |Verlag=Prentice Hall PTR |Datum=2002-05-01 |Sprache=en |Online=http://lyle.smu.edu/~coyle/cse7319/ConwaysLaw..pdf |Abruf=2012-11-12}} {{Webarchiv |url=http://lyle.smu.edu/~coyle/cse7319/ConwaysLaw..pdf |text=Conway’s Law Revisited |wayback=20160514082121}}</ref>
# Definiere das [[Unternehmensleitbild]].
# Ermittle die [[Geschäftsprozess]]e.
# [[Re-Engineering|Adaptiere]] die Geschäftsprozesse, damit sie zum Unternehmensleitbild passen.
# Strukturiere die IT-Organisation so, dass sie die angepassten Geschäftsprozesse unterstützt.

== Zitate ==
[[Eric S. Raymond]], einer der Gründer der [[Open Source Initiative]], schreibt im ''New Hacker’s Dictionary'', der gedruckten Version des [[Jargon File]]s, dass bei der Entwicklung eines [[Compiler]]s durch vier Gruppen ein [[Compiler#Einordnung verschiedener Compiler-Arten|4-pass-Compiler]] herauskommen wird.<ref>{{Literatur |Autor=Eric S. Raymond |Titel=New Hacker’s Dictionary |Auflage=3 |Verlag=MIT Press |Datum=1996 |ISBN=978-0-262-68092-9 |Sprache=en |Online=http://catb.org/~esr/jargon/html/C/Conways-Law.html |Abruf=2012-10-07}}</ref>

== Einzelnachweise ==
<references />

[[Kategorie:Softwarearchitektur]]
[[Kategorie:Softwaretechnik]]

Gesetz von Conway - Versionsgeschichte

imported>SchlurcherBot: Bot: http → https