La ley de Conway es una observación de que el diseño de cualquier sistema se ve afectado significativamente por la estructura de comunicaciones de la organización que lo desarrolla. La ley se asocia comúnmente con el desarrollo de software, pero se considera aplicable a sistemas y organizaciones de todo tipo.
Melvin Conway, un informático y programador, desarrolló su teoría en 1967 como base para un artículo, “How Do Committees Invent?” que estaba enviando a Harvard Business Review (HBR). Aquí está la formación original:
Cualquier organización que diseñe un sistema (definido ampliamente) producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización.
Melvin Conway
HBR rechazó el artículo alegando que Conway no había probado su tesis; el artículo fue publicado en abril de 1968 en Datamation, la revista informática líder de la época. Fred Brooks citó la observación en su artículo, “The Mythical Man-Month” y se refirió a ella como la ley de Conway.
Posteriormente, la Escuela de Negocios de Harvard llevó a cabo un estudio, “Explorando la dualidad entre arquitecturas de producto y organizacionales”, para intentar probar la tesis de Conway. Los investigadores compararon las bases de código de múltiples aplicaciones del mismo tipo que habían sido creadas por equipos de desarrollo de código abierto poco acoplados y equipos estrechamente acoplados. Descubrieron que los equipos estrechamente acoplados tendían a desarrollar bases de código monolíticas, mientras que los equipos poco acoplados tendían a crear bases de código más modulares. De manera similar, se ha observado que si varios equipos están trabajando en los módulos del programa y la comunicación entre equipos es deficiente, las interfaces del programa reflejarán ese hecho.
Antes de explicarte de qué trata, me gustaría que reflexionaras un poco. ¿Has llegado a vivir proyectos en los que a nivel cultural la empresa tenía problemas, había barreras de comunicación entre equipos? Tal vez, ¿cierta necesidad por ocultar cierta información al resto de compañeros?
Y por otro lado, ¿conoces empresas con equipos de personas que se llevan bien, trabajan con un objetivo en común, o en las que la transferencia de conocimiento es algo asumido en la propia cultura?
Si es así, ¿notas alguna relación entre dichos aspectos y la forma en la que el software está diseñado, la arquitectura, las dependencias entre componentes? En mi experiencia sí que he encontrado cierta relación:
- He visto equipos con muy buena comunicación que son capaces de gestionar una arquitectura de microservicios sin problemas.
- Empresas tan orgullosas de su código, tan animadas a difundir el conocimiento y colaborar entre sí, que liberan ciertas partes de sus frameworks en Github.
- También empresas muy ocultistas de información entre compañeros, en las que preguntas y nadie sabe como funcionan ciertas partes de la aplicación, y como consecuencia aparecen problemas a la hora de integrar componentes de software.
- O empresas cuya aplicación es muy enrevesada, con muchos parches, y en las que luego te das cuenta de que su cultura es ir rápido como sea, “como pollos sin cabeza”, sin pararse a pensar ante ciertos problemas.
Qué dice la Ley De Conway
Todo lo dicho anteriormente tiene una base sociológica, que Melvin Conway reflejó en 1968 en How Do Committees Invent? de la siguiente manera:
“Cualquier organización que diseñe un sistema producirá un diseño que copia la estructura de comunicación de dicha organización.”
Conway no dijo esta afirmación como una broma, sino con una justificación real por detrás. Este hecho es causado porque dos componentes de software (p.e A y B), no pueden conectarse correctamente a menos que quien diseña y quien implementa el módulo A se comunique con quien diseñe e implemente el módulo B. Así, este problema en la forma de comunicación de la empresa se refleja en el software, ya que el desarrollo es una actividad intelectual que depende mucho de las propias personas que lo desarrollan.
Para que te des cuenta de forma más visual de esta teoría, Manu Cornet en su web creó las siguientes ilustraciones, donde se muestran las estructuras de comunicación, la forma de organización de empresas como Google, Facebook, Amazon, Microsoft…
Si no te hubiera dicho que son estructuras de comunicación de dichas empresas, ¿hubieras pensado que esos diagramas podrían corresponder a bocetos muy generales de las arquitecturas del software que desarrollan? Yo sí.
¿Las empresas de software aplican esto en su día a día?
La ley de Conway se menciona a menudo en referencia a la tendencia DevOps, que se basa en una comunicación y colaboración efectivas entre los equipos de desarrollo y operaciones.
Netflix, Amazon y Spotify, se organizan con varios equipos pequeños, donde cada uno de ellos es responsable de una pequeña parte de todo el sistema.
Estos equipos son ágiles, autónomos y multifuncionales, con la suficiente independencia como para poder desarrollar funcionalidades en dicho componente de principio a fin, y desplegar versiones de código más rápido, sin afectar a ningún otro equipo.
Probablemente, con una comunicación más procedimental y equipos con más personas, no hubieran llegado a evolucionar su arquitectura hacia tener pequeños componentes independientes.
Y Github por ejemplo, al tener un espíritu open source, con gente de distintos países, distintas zonas horarias, que no están en la misma sala, tiene una arquitectura distribuida.
Por lo tanto, el truco está en ir cambiando y evolucionando las estructuras organizativas para que cuadren con la arquitectura de software que quieres llevar a cabo. Así, poco a poco, los distintos equipos irán evolucionando la arquitectura y el diseño del software, reflejando la forma en la que están organizados.