Gesetz von Conway

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

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

“Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”

„Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“

– Melvin E. Conway[1]

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[Bearbeiten | Quelltext bearbeiten]

Eine Studie der Harvard Business School kam zu dem Schluss, dass es starke Hinweise für die 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 der sie entwickelnden Organisationen mit der Modularität der Produkte.[2]

Weitere Studien konnten ebenso eine 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.[3]
  • 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.[4]
  • 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.[5]

Beispiele[Bearbeiten | Quelltext bearbeiten]

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 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[Bearbeiten | Quelltext bearbeiten]

Ein Beispiel für das Scheitern eines Systems, das durch das Gesetz von Conway beschrieben werden kann, ist der Absturz des Mars Climate Orbiters. Er wurde dadurch verursacht, dass das Entwicklungsteam von Lockheed Martin in der Navigationssoftware das angloamerikanische Maßsystem, das NASA-Entwicklungsteam hingegen das internationale Einheitensystem für die Berechnungen der Steuerung der Sonde zur Erreichung der vorgesehenen Umlaufbahn um den Mars verwendete.[6][7] Von NASA-Seite wurde der Absturz allerdings weniger dem Fehler selbst, als dem Versagen der Kontrollmechanismen zugeschrieben.[8]

Ähnliche Erkenntnisse[Bearbeiten | Quelltext bearbeiten]

Frederick P. Brooks bietet in seinem Buch The Mythical Man Month im Kapitel „Why did the (mythical) 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.[9]

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.[10]

Grüne-Wiese-Ansatz[Bearbeiten | Quelltext bearbeiten]

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“ (englisch clean slate approach) vor:[11]

  1. Definiere das Unternehmensleitbild.
  2. Ermittle die Geschäftsprozesse.
  3. Adaptiere die Geschäftsprozesse, damit sie zum Unternehmensleitbild passen.
  4. Strukturiere die IT-Organisation so, dass sie die angepassten Geschäftsprozesse unterstützt.

Zitate[Bearbeiten | Quelltext bearbeiten]

Eric S. Raymond, einer der Gründer der Open Source Initiative, schreibt im New Hacker’s Dictionary, der gedruckten Version des Jargon Files, dass bei der Entwicklung eines Compilers durch vier Gruppen ein 4-pass-Compiler herauskommen wird.[12]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. ↑ Melvin E. Conway: How Do Committees Invent? In: F. D. Thompson Publications, Inc. (Hrsg.): Datamation. Band 14, Nr. 5, April 1968, S. 28–31 (englisch, melconway.com [abgerufen am 25. September 2012]).
  2. ↑ Alan MacCormack, John Rusnak, Carliss Baldwin: Exploring the Duality between Product and Organizational Architectures. A Test of the “Mirroring” Hypothesis. Hrsg.: Harward Business School. (englisch, hbs.edu [PDF; abgerufen am 25. September 2012]).
  3. ↑ Nachiappan Nagappan, Brendan Murphy, Victor Basili: The Influence of Organizational Structure On Software Quality. An Empirical Case Study. Hrsg.: Microsoft Research. Association for Computing Machinery, Inc., Januar 2008 (englisch, microsoft.com [abgerufen am 25. September 2012]).
  4. ↑ Rebecca M. Henderson, Kim B. Clark: Architectural Innovation. The Reconfiguration of Existing Product Technologies and the Failure of Established Firms. In: Cornell University (Hrsg.): Administrative Sciences Quarterly. Technology, Organizations, and Innovation. Band 35, Nr. 1, März 1990, S. 9–30 (englisch, web.archive.org [PDF; 2,5 MB; abgerufen am 1. November 2021]).
  5. ↑ James. D. Herbsleb, Rebecca. E. Grinter: Splitting the Organization and Integrating the Code. Conway’s Law Revisited. In: Bell Laboratories, Lucent Technologies (Hrsg.): ICSE '99 Proceedings of the 21st international conference on Software engineering. ACM, New York 1999, ISBN 1-58113-074-0, S. 85–95, doi:10.1145/302405.302455 (englisch, herbsleb.org [PDF; abgerufen am 5. Oktober 2012]).
  6. ↑ Dieter Masak: IT-Alignment: IT-Architektur und Organisation. Springer Science & Business Media, 2006, ISBN 978-3-540-31153-9 (google.fr [abgerufen am 14. September 2022]).
  7. ↑ Framework Engineering. Abgerufen am 14. September 2022.
  8. ↑ Mars Climate Orbiter Team Finds Likely Cause Of Loss. 24. August 2006, archiviert vom Original am 24. August 2006; abgerufen am 14. September 2022.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/mars.jpl.nasa.gov
  9. ↑ Frederick P. Brooks: Vom Mythos des Mann-Monats. Essays über Software-Engineering. Addison-Wesley, Bonn 1987, ISBN 3-925118-09-8 (englisch, Originaltitel: The Mythical Man Month: Essays on Software Engineering.).
  10. ↑ James O. Coplien, Neil B. Harrison: Organizational Patterns of Agile Software Development. Prentice Hall International, 2004, ISBN 978-0-13-146740-8.
  11. ↑ David Dikel, David Kane: Conway’s Law Revisited. Successfully Aligning Enterprise Architecture. In: informIT. Prentice Hall PTR, 1. Mai 2002 (englisch, smu.edu [PDF; abgerufen am 12. November 2012]). Conway’s Law Revisited (Memento vom 14. Mai 2016 im Internet Archive)
  12. ↑ Eric S. Raymond: New Hacker’s Dictionary. 3. Auflage. MIT Press, 1996, ISBN 978-0-262-68092-9 (englisch, catb.org [abgerufen am 7. Oktober 2012]).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Gesetz_von_Conway&oldid=238711792“