Articulo de referencia

Ley de Conway

La ley de Conway describe el vínculo entre la estructura de comunicación de las organizaciones y los sistemas que diseñan. Recibe su nombre del programador informático Melvin Co...

La ley de Conway describe el vínculo entre la estructura de comunicación de las organizaciones y los sistemas que diseñan. Recibe su nombre del programador informático Melvin Conway , quien introdujo la idea en 1967. [1] Su redacción original fue: [2] [3]

[L]as organizaciones que diseñan sistemas (en el sentido amplio utilizado aquí) están limitadas a producir diseños que son copias de las estructuras de comunicación de esas organizaciones.

—  Melvin E. Conway, ¿Cómo inventan los comités?

La ley se basa en el razonamiento de que para que un producto funcione, los autores y diseñadores de sus componentes deben comunicarse entre sí para garantizar la compatibilidad entre los componentes. Por lo tanto, la estructura técnica de un sistema reflejará los límites sociales de las organizaciones que lo produjeron, a través de los cuales la comunicación es más difícil. En términos coloquiales, significa que los productos complejos terminan "conformados" por la estructura organizacional en la que fueron diseñados o para la que fueron diseñados. La ley se aplica principalmente en el campo de la arquitectura de software, aunque Conway la dirigió de manera más amplia y sus supuestos y conclusiones se aplican a la mayoría de los campos técnicos.

Variaciones

Eric S. Raymond , un defensor del código abierto, reiteró la ley de Conway en The New Hacker's Dictionary , una obra de referencia basada en el Jargon File . La organización del software y la organización del equipo de software serán congruentes, afirmó. Resumiendo un ejemplo del artículo de Conway, Raymond escribió:

Si tienes cuatro grupos trabajando en un compilador, obtendrás un compilador de 4 pasadas. [4] [5]

Raymond presenta además la enmienda de Tom Cheatham a la Ley de Conway, expresada como:

Si un grupo de N personas implementa un compilador COBOL, habrá N−1 pases. Alguien del grupo tiene que ser el administrador. [4]

Yourdon y Constantine , en su libro de 1979 sobre Diseño Estructurado , dieron una variación más enérgica de la Ley de Conway:

La estructura de cualquier sistema diseñado por una organización es isomorfa a la estructura de la organización. [6]

James O. Coplien y Neil B. Harrison afirmaron en un libro de 2004 sobre los patrones organizativos del desarrollo de software ágil :

Si las partes de una organización (por ejemplo, equipos, departamentos o subdivisiones) no reflejan fielmente las partes esenciales del producto, o si las relaciones entre organizaciones no reflejan las relaciones entre las partes del producto, entonces el proyecto tendrá problemas... Por lo tanto: Asegúrese de que la organización sea compatible con la arquitectura del producto. [7]

Los comentaristas más recientes han señalado un corolario: para los proyectos de software con una larga vida útil de reutilización de código, como Microsoft Windows , la estructura del código refleja no solo la estructura de comunicación de la organización que creó la versión más reciente, sino también las estructuras de comunicación de cada equipo anterior que trabajó en ese código. [8]

También hay un viejo chiste de la industria automovilística: [9]

En el tablero puedes ver el organigrama de una empresa automovilística y también ver si el equipo del volante odia al equipo de la palanca de cambios.

Interpretaciones

La ley, en sentido estricto, sólo trata de correspondencia; no afirma que la estructura de la comunicación sea la causa de la estructura del sistema, simplemente describe la conexión. Diferentes comentaristas han tomado diversas posiciones sobre la dirección de la causalidad; que el diseño técnico hace que la organización se reestructure para encajar, [10] que la estructura organizacional dicta el diseño técnico, [11] o ambas cosas. [12] [13] [14] La ley de Conway fue concebida originalmente como una observación sociológica [ cita requerida ] , pero son posibles muchas otras interpretaciones. La entrada del New Hacker's Dictionary la utiliza en un contexto principalmente humorístico, [15] mientras que los participantes en el Simposio Nacional de Programación Modular de 1968 la consideraron lo suficientemente seria y universal como para denominarla "Ley de Conway". [6] Las opiniones también varían sobre la deseabilidad del fenómeno; algunos dicen que el patrón de reflejo es una característica útil de tales sistemas, mientras que otras interpretaciones dicen que es un resultado indeseable del sesgo organizacional. [ cita requerida ] Las posiciones intermedias lo describen como una característica necesaria del compromiso, indeseable en abstracto pero necesaria para manejar las limitaciones humanas. [8]

Evidencia de apoyo

Un ejemplo del impacto de la Ley de Conway se puede encontrar en el diseño de algunos sitios web de organizaciones. Nigel Bevan afirmó en un artículo de 1997, en relación con los problemas de usabilidad en los sitios web: "Las organizaciones a menudo producen sitios web con un contenido y una estructura que reflejan las preocupaciones internas de la organización en lugar de las necesidades de los usuarios del sitio". [16]

Un equipo de investigadores del Instituto Tecnológico de Massachusetts (MIT) y de la Escuela de Negocios de Harvard ha publicado pruebas que respaldan la ley de Conway . Utilizando la "hipótesis del reflejo" como término equivalente a la ley de Conway, han encontrado "pruebas sólidas que respaldan la hipótesis del reflejo" y que el "producto desarrollado por la organización débilmente acoplada es significativamente más modular que el producto de la organización fuertemente acoplada". Los autores destacan el impacto de las "decisiones de diseño organizacional en la estructura técnica de los artefactos que estas organizaciones desarrollan posteriormente". [17]

Nagappan, Murphy y Basili han llevado a cabo estudios de caso adicionales y de apoyo de la ley de Conway en la Universidad de Maryland en colaboración con Microsoft [18] , y Syeed y Hammouda en la Universidad Tecnológica de Tampere en Finlandia [19] .

Véase también

Referencias

  1. ^ Conway, Melvin. "Ley de Conway". Página de inicio de Mel Conway . Archivado desde el original el 2019-09-29 . Consultado el 2019-09-29 .
  2. ^ Conway, Melvin E. (abril de 1968). «¿Cómo inventan los comités?». Datamation . 14 (5): 28– 31. Archivado desde el original el 10 de octubre de 2019. Consultado el 10 de octubre de 2019. […] las organizaciones que diseñan sistemas […] se ven obligadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones.
  3. ^ Conway, Melvin (1968). "Cómo inventan los comités" (PDF) . Datamation : 28– 31.
  4. ^ de Raymond, Eric S. (octubre de 1996). The New Hacker's Dictionary (3.ª edición). Cambridge, Massachusetts: MIT Press. pág. 124. ISBN 978-0-262-68092-9Ley de Conway : prov. La regla […] originalmente se enunciaba así: «Si hay cuatro grupos trabajando en un compilador, se obtendrá un compilador de 4 pasadas». […] Enmienda de Tom Cheatham a la Ley de Conway: «Si un grupo de N personas implementa un compilador COBOL, habrá N-1 pasadas. Alguien del grupo tiene que ser el administrador».
  5. ^ Eric S. Raymond. "Ley de Conway". The Jargon File, versión 4.4.8 . Archivado desde el original el 26 de marzo de 2012. Consultado el 26 de marzo de 2012 .
  6. ^ ab Yourdon, Edward; Constantine, Larry L. (1979). Diseño estructurado: Fundamentos de una disciplina de diseño de programas y sistemas informáticos (2.ª ed.). Englewood Cliffs, NJ: Prentice Hall. ISBN 0138544719. OCLC  4503223. Ley de Conway: La estructura de un sistema refleja la estructura de la organización que lo construyó. La Ley de Conway se ha expresado con mayor fuerza aún: La estructura de cualquier sistema diseñado por una organización es isomorfa a la estructura de la organización.
  7. ^ Coplien y Harrison (julio de 2004). Patrones organizativos del desarrollo ágil de software . Pearson Prentice Hall. ISBN 978-0-13-146740-8.
  8. ^ de Muratori, Casey, La única ley inquebrantable , consultado el 21 de marzo de 2022
  9. ^ "¿Tesla es disruptiva?". Benedict Evans . 2018-09-01 . Consultado el 2024-01-24 .
  10. ^ Chandler, AD (1977). La mano visible: la revolución gerencial en los negocios estadounidenses. Harvard University Press, Cambridge, MA.
  11. ^ Henderson, RM y Clark, KB (1990). Innovación arquitectónica: la reconfiguración de las tecnologías de productos existentes y el fracaso de las empresas establecidas. Administrative science quarterly, 9-30.
  12. ^ Baldwin, CY y Clark, KB (2000). Design rules: The power of modularity (Vol. 1). Capítulo 7. MIT press. (Los capítulos 1 y 14 se consideran un estudio descriptivo de la industria).
  13. ^ Fixson, SK y Park, JK (2008). El poder de la integralidad: vínculos entre la arquitectura de productos, la innovación y la estructura de la industria. Research Policy, 37(8), 1296-1316.
  14. ^ "La hipótesis del reflejo: teoría, evidencia y excepciones", Lyra J. Colfer, Carliss Y. Baldwin https://www.hbs.edu/ris/Publication%20Files/16-124_7ae90679-0ce6-4d72-9e9d-828872c7af49.pdf
  15. ^ Raymond1996
  16. ^ Bevan, Nigel (noviembre de 1997). "Problemas de usabilidad en el diseño de sitios web" (PDF) . Diseño de sistemas informáticos: consideraciones sociales y ergonómicas . Actas de la Séptima Conferencia Internacional sobre Interacción Hombre-Ordenador (HCI International '97). Vol. 2. San Francisco, California, EE. UU.: Elsevier. págs.  803– 806.
  17. ^ MacCormack, Alan; Rusnak, John; Baldwin, Carliss Y. (2011). "Explorando la dualidad entre las arquitecturas de producto y organizacional: una prueba de la hipótesis del reflejo" (PDF) . Serie de documentos de trabajo de la SSRN . doi :10.2139/ssrn.1104745. ISSN  1556-5068. S2CID  16097528. Encontramos evidencia sólida para apoyar la hipótesis del reflejo. En todos los pares que examinamos, el producto desarrollado por la organización débilmente acoplada es significativamente más modular que el producto de la organización fuertemente acoplada. […] Nuestros resultados tienen implicaciones gerenciales significativas, al destacar el impacto de las decisiones de diseño organizacional en la estructura técnica de los artefactos que estas organizaciones desarrollan posteriormente.
  18. ^ Nagappan, Nachiappan; Murphy, Brendan; Basili, Victor (2008). "La influencia de la estructura organizacional en la calidad del software: un estudio de caso empírico". Actas de la 13.ª conferencia internacional sobre ingeniería de software - ICSE '08 . Nueva York, Nueva York, EE. UU.: ACM Press. pág. 521. doi :10.1145/1368088.1368160. ISBN 9781605580791. Número de identificación del sujeto  5048618.
  19. ^ Syeed, MM Mahbubul; Hammouda, Imed (2013). "Congruencia sociotécnica en proyectos OSS: exploración de la ley de Conway en FreeBSD". Software de código abierto: verificación de calidad . IFIP Avances en tecnología de la información y la comunicación. Vol. 404. págs.  109– 126. doi :10.1007/978-3-642-38928-3_8. ISBN 978-3-642-38927-6. Número de identificación del sujeto  39852208.

Lectura adicional

  • Alan MacCormack, John Rusnak y Carliss Baldwin, 2012, "Explorando la dualidad entre las arquitecturas de producto y organizacional: una prueba de la hipótesis del 'espejo'", Research Policy 41 :1309–1324 [anteriormente Harvard Business School Working Paper 08-039], véase [1] Archivado el 24 de enero de 2021 en Wayback Machine , consultado el 9 de marzo de 2015.
  • Lise Hvatum y Allan Kelly, Eds., "¿Qué pienso ahora sobre la Ley de Conway? Conclusiones de un grupo de debate de EuroPLoP 2005", Conferencia europea sobre lenguajes de patrones de programas, Kloster Irsee, Alemania, 16 de enero de 2006, véase [2], presentado el 9 de marzo de 2015.
  • Lyra Colfer y Carliss Baldwin. "La hipótesis del reflejo: teoría, evidencia y excepciones". Documento de trabajo de la Harvard Business School, n.º 16-124, abril de 2016. (Revisado en mayo de 2016). Véase [3], consultado el 2 de agosto de 2016.
Obtenido de "https://es.wikipedia.org/w/index.php?title=Ley_de_Conway&oldid=1250799382"