traducido por I. A.
Durante mi trabajo como Gestor de Configuración / DevOps para grandes proyectos web, he observado cómo las empresas hacían caso omiso de la Ley de Conway y fracasaban estrepitosamente. Ese fracaso a menudo se traducía en importantes sobrecostes presupuestarios y plazos incumplidos.
La infraestructura interna en la colaboración del proyecto se modeló exactamente según las estructuras organizativas internas y todas las experiencias y normas establecidas se “doblaron” para adaptarlas a la organización interna. Esto dio lugar a problemas que hicieron que las canalizaciones de CI/CD fueran especialmente engorrosas y provocaron largos tiempos de ejecución. Pero además, los ajustes sólo podían hacerse con mucho esfuerzo. En lugar de simplificar los procesos existentes y adaptarlos a los estándares establecidos, se pusieron excusas para mantener todo como estaba. Veamos qué es la Ley de Conway y por qué hay que respetarla.
El investigador y programador estadounidense Melvin E. Conway se doctoró en la Case Western Reserve University en 1961. Su especialidad son los lenguajes de programación y el diseño de compiladores.
En 1967, presentó su artículo “How Do Committees Invent?” (¿Cómo inventan los comités?) en The Harvard Business Review. (Engl.: ¿Cómo inventan los comités?) y fue rechazado. La razón aducida fue que su tesis no estaba fundamentada. Sin embargo, Datamation, la mayor revista de informática de la época, aceptó su artículo y lo publicó en abril de 1968. Y este artículo es ahora ampliamente citado. La afirmación central es:
Cualquier organización que diseñe un sistema (en el sentido más amplio) creará un diseño cuya estructura sea una copia de la estructura de comunicación de la organización.
Conway, Melvin E. “How do Committees Invent?” 1968, Datamation, vol. 14, num. 4, pp. 28–31
Cuando Fred Brooks citó el ensayo en su legendario libro de 1975 “The Mythical Man-Month”, llamó a esta afirmación central Ley de Conway. Brooks reconoció la conexión entre la Ley de Conway y la teoría de la gestión. En el artículo encontramos el siguiente ejemplo:
Dado que el diseño elegido en primer lugar casi nunca es el mejor posible, el sistema imperante puede necesitar cambiar conceptos del sistema. Por ello, la flexibilidad de la organización es importante para un diseño eficaz.
Un ejemplo a menudo citado del tamaño “ideal” de un equipo en términos de la Ley de Conway es la regla de las dos pizzas de Amazon, que establece que los equipos de proyectos individuales no deben tener más miembros de los que dos pizzas puedan llenar en una reunión. Sin embargo, el factor más importante que hay que tener en cuenta en la alineación de equipos es la capacidad de trabajar entre equipos y no vivir en silos.
La Ley de Conway no pretendía ser un chiste ni un koan zen, sino una observación sociológica válida. Fijémonos en las estructuras de las administraciones públicas y su implantación digital. Pero también los procesos de las grandes empresas han sido emulados por sistemas informáticos. Estas aplicaciones se consideran muy engorrosas y complicadas, por lo que encuentran poca aceptación entre los usuarios, que prefieren recurrir a alternativas. Por desgracia, a menudo es casi imposible simplificar los procesos en las grandes estructuras organizativas por motivos políticos.
Entre otras cosas, hay un detallado artículo de Martin Fowler, que trata explícitamente de las arquitecturas de software y elabora la importancia del acoplamiento de objetos y módulos. La comunicación entre desarrolladores desempeña un papel esencial para lograr los mejores resultados posibles. Este hecho sobre la importancia de la comunicación también fue recogido por el desarrollo ágil de software e implementado como un punto esencial. Especialmente cuando equipos distribuidos trabajan en un proyecto conjunto, la diferencia horaria es un factor limitante en la comunicación del equipo. Por tanto, ésta debe organizarse de forma especialmente eficaz.
En 2010, Jonny Leroy y Matt Simons acuñaron el término Inverse Conway Maneuver en el artículo “Dealing with creaky legacy platforms”:
La Ley de Conway… puede resumirse así: “Las organizaciones disfuncionales tienden a crear aplicaciones disfuncionales”. Parafraseando a Einstein: No se puede solucionar un problema desde la misma mentalidad que lo creó. Por lo tanto, a menudo merece la pena investigar si la reestructuración de su organización o equipo evitaría que la nueva aplicación tuviera las mismas disfunciones estructurales que la original. En una especie de “maniobra Conway a la inversa”, se puede empezar por romper los silos que limitan la capacidad del equipo para trabajar juntos con eficacia.
Desde la década de 2010, un nuevo estilo arquitectónico ha entrado en la industria del software. Son los llamados microservicios, creados por pequeños equipos ágiles. El criterio más importante de un microservicio en comparación con un monolito modular es que un microservicio puede verse como un módulo o subsistema independientemente viable. Por un lado, esto permite reutilizar el microservicio en otras aplicaciones. Por otro lado, existe un fuerte encapsulamiento del dominio funcional, lo que abre una flexibilidad muy elevada para las adaptaciones.
La ley de Conway también puede aplicarse a muchos otros ámbitos y no se limita exclusivamente a la industria del software. Esto es lo que hace que el trabajo sea tan valioso.
Resourcen
