Conway's law

from Wikipedia, the free encyclopedia

The Conway Law is an observation named after the American computer scientist Melvin Edward Conway , that the structures of systems are predetermined by the communication structures of the organizations implementing them. It was formulated by Conway in 1968 as follows:

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

"Organizations that design systems [...] are forced to create designs that depict the communication structures of these organizations."

- Melvin E. Conway

Conway's Law is based on the idea that to define the interfaces between separate software modules, interpersonal communication is necessary. Therefore the communication structures of the organizations have a great influence on the structures of these interfaces.

Studies

A Harvard Business School study concluded that there was strong evidence to support the correctness of Conway's Law. In all of them examined 12 products from 5 different application areas (financial management, word processing, spreadsheet, operating system, database system), the coupling of the organizations developing them correlated with the modularity of the products.

Further studies could also prove a relationship between the architecture of a product and the characteristics of the organization implementing it:

  • A Microsoft research study calculated the complexity and error rate of Windows Vista from the complexity of the organizational units entrusted with the development of Microsoft Windows Vista.
  • Rebecca M. Henderson and Kim B. Clark were able to prove that product innovations that change the architecture of the product require a change in the knowledge architecture and company structure.
  • James D. Herbsleb and Rebecca E. Grinter concluded that the work on a modularized system should be distributed in such a way that the separation of the development corresponds to the division of the modules. Conversely, development should only be split up if the products (or product parts) to be developed are well understood, plans, processes and interfaces are established and stable.

Examples

Suppose a company is tasked with implementing a large software system. The contracted company has three developer groups, E1, E2 and E3, who work together on the project. Conway's law now states that the developed software system will probably consist of three large subsystems S1, S2 and S3, which are implemented in a different developer group. More importantly, the quality and type of interfaces between the subsystems (S1 – S2, S1 – S3, S2 – S3) are dependent on the quality and type of interpersonal communication between the respective developer groups (E1 – E2, E1 – E3, E2 – E3) correspond.

The same also applies on a smaller scale: Assume that software developer E1 has implemented class K1 for functionality F1. Functionality F1 is to be expanded later to include a similar functionality F2. If the software developer E1 implements this functionality, he will simply add this functionality to class K1. If a software developer E2 from another group implements this functionality, he will probably fear that the existing functionality will be broken and therefore implement functionality F2 in a (sub) class K2. The design of the application is therefore highly dependent on who implements the functionality.

Example of system failure

An example of the failure of a system that can be described by Conway's Law is the crash of the Mars Climate Orbiter . It was caused by the fact that the Lockheed Martin development team used the Anglo-American system of measurement in the navigation software , while the NASA development team used the international system of units for the calculations of the control of the probe to achieve the intended orbit around Mars. From NASA's side, however, the crash was less attributed to the error itself than to the failure of the control mechanisms.

Similar findings

Frederick P. Brooks offers in his book The Mythical Man Month in the chapter "Why did the (mythical) Tower of Babel Fail?" The analogy that despite a clear objective, sufficient personnel, raw materials and time, as well as mature technology, projects on communication problems and the resulting organizational changes can fail. Brooks also notes that a lack of communication between teams in software development results in functional or scheduling failures.

In their book Organizational Patterns of Agile Software Development, James O. Coplien and Neil B. Harrison take the view that a project is problematic to implement if the division of the organization implementing it (e.g. into teams, departments or subdivisions) does not match most important parts of the product to be implemented, and the relationships between the organizational parts do not correspond to the relationships between the product parts. That is why it is important to make the organization compatible with the product architecture.

Green meadow approach

In order to get suitable communication structures for the product to be implemented, and thus to get suitable product modules in accordance with Conway's law, Melvin Conway suggests the following "green meadow approach" ( English clean slate approach ):

  1. Define the company's mission statement .
  2. Identify the business processes .
  3. Adapt the business processes so that they fit the company's mission statement.
  4. Structure the IT organization in such a way that it supports the adapted business processes.

Quotes

Eric S. Raymond , one of the founders of the Open Source Initiative , writes in the New Hacker's Dictionary , the printed version of the jargon file , that if a compiler is developed by four groups, a 4-pass compiler will come out.

Individual evidence

  1. ^ Melvin E. Conway: How Do Committees Invent? In: FD Thompson Publications, Inc. (Ed.): Datamation . tape 14 , no. 5 , April 1968, p. 28-31 (English, melconway.com [accessed September 25, 2012]).
  2. ^ Alan MacCormack, John Rusnak, Carliss Baldwin: Exploring the Duality between Product and Organizational Architectures . A Test of the “Mirroring” Hypothesis. Ed .: Harward Business School. (English, hbs.edu [PDF; accessed September 25, 2012]).
  3. ↑ Nachiappan Nagappan, Brendan Murphy, Victor Basili: The Influence of Organizational Structure On Software Quality . An empirical case study. Ed .: Microsoft Research. Association for Computing Machinery, Inc., January 2008 ( microsoft.com [accessed September 25, 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 (Ed.): Administrative Sciences Quarterly . Technology, Organizations, and Innovation. tape 35 , no. 1 , March 1990, p. 9–30 (English, edegan.com [PDF; accessed October 5, 2012]). Architectural Innovation ( Memento of the original from March 4, 2016 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.  @1@ 2Template: Webachiv / IABot / www.edegan.com
  5. ↑ James. D. Herbsleb, Rebecca. E. Grinter: Splitting the Organization and Integrating the Code . Conway's Law Revisited. In: Bell Laboratories, Lucent Technologies (Ed.): ICSE '99 Proceedings of the 21st international conference on Software engineering . ACM, New York 1999, ISBN 1-58113-074-0 , pp. 85–95 , doi : 10.1145 / 302405.302455 (English, herbsleb.org [PDF; accessed on October 5, 2012]).
  6. ↑ Dieter Masak: IT alignment: IT architecture and organization , Springer-Verlag, Heidelberg 2006, page 239f.
  7. ↑ Youngsu Son, Jemin Jeon, Hyukjoon Lee, Gaeyoung Lee: Framework Engineering. Hillside Group, 2010 (PDF; 598 kB)
  8. ↑ MARS CLIMATE ORBITER TEAM FINDS LIKELY CAUSE OF LOSS (1999)
  9. ↑ Frederick P. Brooks: On the Myth of the Man Month . Essays on software engineering. Addison-Wesley, Bonn 1987, ISBN 3-925118-09-8 (English, original title: 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, May 1, 2002 (English, smu.edu [PDF; accessed November 12, 2012]). Conway's Law Revisited ( Memento of the original dated May 14, 2016 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.  @1@ 2Template: Webachiv / IABot / lyle.smu.edu
  12. ↑ Eric S. Raymond: New Hacker's Dictionary . 3. Edition. MIT Press, 1996, ISBN 978-0-262-68092-9 (English, catb.org [accessed October 7, 2012]).