Conway's Law
La Ley de Conway (Conway's Law) es una observación formulada por Melvin Conway en 1967 que establece que las organizaciones que diseñan sistemas están inevitablemente condicionadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones. En palabras sencillas: la arquitectura del software tiende a reflejar la estructura organizativa del equipo que lo construye.
Conway publicó la observación en el artículo "How Do Committees Invent?" (1967). Fred Brooks la popularizó citándola en The Mythical Man-Month (1975), donde la llamó "Ley de Conway".
Implicaciones prácticas
Si una organización tiene tres equipos de backend, dos de frontend y uno de QA, el sistema resultante tenderá a tener tres módulos de backend, dos de frontend y una capa de QA, reflejando las fronteras organizativas aunque no sea la arquitectura técnicamente óptima.
Las interfaces entre módulos del sistema tienden a corresponder a las interfaces de comunicación entre equipos: los puntos donde la comunicación es difícil o costosa son los mismos donde la integración técnica es difícil o costosa.
La Inverse Conway Maneuver
La consecuencia práctica de la Ley de Conway en el diseño de sistemas es lo que se conoce como la Inverse Conway Maneuver (maniobra de Conway inversa): en lugar de diseñar primero el sistema y luego organizar los equipos para construirlo, diseñar primero la estructura de equipos que se quiere tener y dejar que el sistema refleje esa estructura.
En el contexto de microservicios y arquitecturas distribuidas: si se quiere un sistema con servicios independientes y desplegables de forma autónoma, se necesitan equipos organizados de forma que puedan operar con autonomía real sobre sus servicios.
Relevancia en el escalado ágil
La Ley de Conway es central en los marcos de escalado ágil. SAFe, Nexus y LeSS proponen estructuras de equipos específicas precisamente porque entienden que la organización de los equipos determina la arquitectura del sistema resultante.
Error frecuente
Intentar cambiar la arquitectura sin cambiar la estructura organizativa. Los equipos pueden acordar una nueva arquitectura técnica, pero si la organización del trabajo y la comunicación no cambian, el código tenderá a regresar gradualmente a una estructura que refleje la organización real. La refactorización arquitectónica sin cambio organizativo es una batalla permanente contra la gravedad.
Referencias
- Conway, Melvin E. (1968). "How Do Committees Invent?". Datamation.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.