La ley de Conway describe el vínculo entre la estructura de comunicación de las organizaciones y los sistemas que diseñan. Lleva el 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 obligadas a producir diseños que sean copias de las estructuras de comunicación de estas 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á las fronteras sociales de las organizaciones que lo produjeron, a través de las cuales la comunicación es más difícil. En términos coloquiales, significa que los productos complejos terminan "con la forma" de la estructura organizacional para 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.
Eric S. Raymond , un defensor del código abierto, reformuló 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 tiene cuatro grupos trabajando en un compilador, obtendrá 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 firme 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 proyectos de software con una larga vida útil de reutilización de código, como Microsoft Windows , la estructura del código refleja no sólo 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]
Puede ver el organigrama de una empresa de automóviles en el tablero y también ver si el equipo del volante odia al equipo de la palanca de cambios.
La ley, en sentido estricto, se refiere únicamente a la correspondencia; no afirma que la estructura de comunicación sea la causa de la estructura del sistema, simplemente describe la conexión. Diferentes comentaristas han adoptado diversas posiciones sobre la dirección de la causalidad; que el diseño técnico hace que la organización se reestructure para adaptarse, [10] que la estructura organizacional dicta el diseño técnico, [11] o ambos. [12] [13] [14] La ley de Conway fue pensada originalmente como una observación sociológica [ cita necesaria ] , 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 sobre 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 conveniencia del fenómeno; algunos dicen que el patrón de duplicación es una característica útil de tales sistemas, mientras que otras interpretaciones dicen que es un resultado indeseable del sesgo organizacional. [ cita necesaria ] Las posiciones intermedias lo describen como una característica necesaria del compromiso, indeseable en abstracto pero necesario para manejar las limitaciones humanas. [8]
Un ejemplo del impacto de la Ley de Conway se puede encontrar en el diseño de los sitios web de algunas organizaciones. Nigel Bevan afirmó en un artículo de 1997, sobre cuestiones de usabilidad en sitios web: "Las organizaciones a menudo producen sitios web con un contenido y una estructura que reflejan las preocupaciones internas de la organización más que 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 evidencia que respalda la ley de Conway quienes, utilizando "la hipótesis del reflejo" como término equivalente para la ley de Conway, encontraron "evidencia sólida que respalda 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 estrechamente 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 en la Universidad de Maryland en colaboración con Microsoft [ 18] y Syeed y Hammouda en la Universidad Tecnológica de Tampere en Finlandia han realizado estudios de casos adicionales y de apoyo de la ley de Conway . [19]
[…] las organizaciones que diseñan sistemas […] están obligadas a producir diseños que sean copias de las estructuras de comunicación de estas organizaciones.
Ley de Conway: prov. La regla […] originalmente decía: "Si tienes cuatro grupos trabajando en un compilador, obtendrás un compilador de 4 pasadas". […] La enmienda de Tom Cheatham a la Ley de Conway: "Si un grupo de N personas implementa un compilador COBOL, habrá N-1 pases. Alguien en el grupo tiene que ser el administrador".
Ley de Conway: La estructura de un sistema refleja la estructura de la organización que lo construyó. La Ley de Conway se ha afirmado aún con más fuerza: la estructura de cualquier sistema diseñado por una organización es isomorfa a la estructura de la organización.
Encontramos pruebas sólidas que respaldan 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 estrechamente acoplada. […] Nuestros resultados tienen importantes implicaciones gerenciales, al resaltar el impacto de las decisiones de diseño organizacional en la estructura técnica de los artefactos que estas organizaciones desarrollan posteriormente.