La ley de Conway y la forma de las organizaciones

Lo que Conway dijo realmente

En abril de 1968 la revista Datamation publicó "How Do Committees Invent?" de Melvin Conway, programador y consultor informático. Su conclusión es la frase conocida hoy como ley de Conway: las organizaciones que diseñan sistemas están obligadas a producir diseños que son copias de las estructuras de comunicación de esas organizaciones. El nombre llegó después: Fred Brooks citó el artículo en The Mythical Man-Month (1975) y llamó a la idea ley de Conway.

El argumento de Conway es más preciso que el eslogan. Un sistema está formado por subsistemas conectados mediante interfaces. Para que dos subsistemas se conecten, las personas que los diseñan tienen que haber negociado y acordado esa interfaz, así que tienen que haberse comunicado. Si los diseñadores de dos subsistemas no se comunican, no hay ninguna interfaz que acordar. Existe, por tanto, una correspondencia que preserva la estructura (Conway usó el término matemático homomorfismo) entre el grafo del sistema y el grafo de la organización que lo diseñó. Su ejemplo: una organización de investigación por contrato tenía ocho personas para escribir un compilador de COBOL y otro de ALGOL. Cinco se asignaron a COBOL y tres a ALGOL. El compilador de COBOL funcionaba en cinco fases; el de ALGOL, en tres.

Dos puntos más del artículo suelen olvidarse. Primero, Conway dejó claro que "sistema" se entiende en sentido amplio: se aplica a cualquier cosa diseñada, no solo al software. Segundo, su conclusión práctica se refería a la flexibilidad. Como el primer diseño rara vez es el mejor, y como una organización tiende a fijar su estructura pronto (una vez formados los equipos, el diseño ya está decidido en parte), sostuvo que las organizaciones de diseño deben mantenerse ligeras y flexibles, y organizarse según la comunicación que el diseño realmente necesita.

La evidencia: la hipótesis del espejo

Durante décadas, la ley de Conway se apoyó sobre todo en anécdotas. Desde la década de 2000 los investigadores la han puesto a prueba, normalmente con el nombre de hipótesis del espejo (mirroring hypothesis): las dependencias técnicas de un producto coincidirán con los vínculos organizativos (comunicación, ubicación compartida, relación laboral) entre las personas que lo construyen.

El estudio más conocido sobre software es el de Alan MacCormack, Carliss Baldwin y John Rusnak, publicado en Research Policy en 2012 como "Exploring the duality between product and organizational architectures: a test of the mirroring hypothesis". Compararon pares equivalentes de productos con funciones similares, uno construido por una organización fuertemente acoplada (una empresa comercial con un equipo en un mismo lugar) y otro por una organización débilmente acoplada (una comunidad de código abierto distribuida): por ejemplo, dos paquetes de gestión financiera, dos procesadores de texto, dos bases de datos, y Linux frente a núcleos de sistemas operativos comerciales. Midieron la modularidad mediante el costo de propagación, la proporción media de los archivos de un sistema a los que un cambio en un archivo puede afectar directa o indirectamente. En todos los pares, el producto de la organización débilmente acoplada era más modular, y en el par más extremo la diferencia era de varias veces. Los autores lo interpretan como evidencia de que los equipos distribuidos, que no pueden coordinarse con facilidad, se ven empujados hacia diseños que necesitan menos coordinación.

Un estudio de Microsoft Research sobre Windows Vista, de Nachiappan Nagappan, Brendan Murphy y Victor Basili (2008), abordó la cuestión desde el lado de la calidad. Las métricas que describían la organización que construyó cada binario (cuántos ingenieros lo tocaron, cuántos se habían ido, a qué distancia en la jerarquía de gestión estaban los contribuyentes) predecían qué binarios eran propensos a fallos mejor que las métricas de código convencionales, como la rotación de código (churn), la complejidad, la cobertura y las dependencias.

La evidencia no es unánime, y el resumen honesto importa. Una revisión de 2016 de 142 estudios empíricos, de Lyra Colfer y Carliss Baldwin, encontró que el reflejo era común en los estudios de industrias y empresas, pero no universal, y que los estudios de proyectos colaborativos abiertos a menudo no lo respaldaban, probablemente porque los repositorios de código compartidos, los gestores de incidencias y el debate abierto permiten a los contribuyentes distribuidos coordinarse sin los vínculos organizativos habituales. El reflejo es una tendencia fuerte, no una ley de la física, y unas buenas herramientas y prácticas pueden romperlo en parte.

Las vías de comunicación y por qué importa el tamaño del equipo

Un grupo de n personas tiene n(n − 1) / 2 posibles vías de comunicación de persona a persona. El número crece aproximadamente con el cuadrado del grupo: duplicar el equipo cuadruplica las vías. Brooks usó la misma aritmética para explicar por qué añadir personas a un proyecto retrasado lo retrasa aún más: cada recién llegado debe recibir formación y añade nuevas vías que todos deben mantener.

Desde el punto de vista arquitectónico, la aritmética explica dos cosas. Primero, un solo equipo no puede crecer indefinidamente y seguir manteniendo una comprensión compartida de su código; a partir de cierto tamaño se fragmenta en subgrupos informales y, por la ley de Conway, el código se fragmenta por las mismas líneas, tanto si alguien diseñó esas costuras como si no. Segundo, el número de vías entre equipos importa tanto como dentro de ellos: si cada equipo tiene que hablar con todos los demás para entregar un cambio, la estructura del sistema es, en la práctica, una única unidad grande y acoplada, por muchos servicios que tenga.

La maniobra inversa de Conway

Si las organizaciones tienden a producir sistemas que reflejan su estructura, puedes usar esa tendencia de forma deliberada: diseña la estructura de equipos y las vías de comunicación para la arquitectura que quieres, y deja que el sistema crezca con esa forma. Jonny LeRoy y Matt Simons llamaron a esto maniobra inversa de Conway en un artículo del Cutter IT Journal de diciembre de 2010, y desde entonces se ha convertido en una técnica habitual en los programas de microservicios y de plataforma.

En la práctica, significa decidir primero los límites previstos (por ejemplo, pedidos, pagos, seguimiento de entregas y alta de restaurantes como servicios separados), después formar un equipo estable en torno a cada uno, darle la propiedad del código, los datos y el pipeline de despliegue, y hacer que los equipos interactúen principalmente mediante API y eventos publicados, en lugar de código compartido o bases de datos compartidas. Donde el contacto entre equipos sea realmente necesario, hazlo explícito: un equipo de plataforma que ofrece un producto de autoservicio, un equipo facilitador que ayuda durante un tiempo limitado.

La maniobra tiene límites. Solo funciona lentamente a favor de la veta de un sistema existente: reorganizar los equipos no reestructura un código fuertemente acoplado y, durante un tiempo, los nuevos equipos estarán luchando contra la arquitectura antigua. Martin Fowler señala que no puede arreglar rápidamente un sistema existente rígido. También supone que conoces los límites correctos; si los trazas mal y luego los consolidas en estructuras de equipo, la ley de Conway reproducirá fielmente el error y hará que sea caro cambiarlo. Por eso los equipos suelen empezar con un monolito modular y mover los límites antes de convertirlos en organizativos.

Carga cognitiva del equipo

La ley de Conway te dice que los límites de los equipos se convierten en límites del sistema. Una segunda restricción te dice qué tamaño puede tener la parte de cada equipo. La carga cognitiva del equipo, un concepto que Matthew Skelton y Manuel Pais llevaron al diseño de organizaciones de software en Team Topologies (2019; segunda edición en 2025), es la cantidad total que un equipo debe tener en la cabeza para construir, operar y cambiar lo que posee: el dominio de negocio, el código, la infraestructura, las herramientas, las guardias.

Toman de la psicología la distinción entre la carga intrínseca (la dificultad inherente de la tarea, como entender el dominio), la carga extrínseca (el esfuerzo que impone el entorno, como un procedimiento de despliegue manual o una compilación oscura) y la carga pertinente (el esfuerzo de aprendizaje que mejora el trabajo futuro). El objetivo de diseño es minimizar la carga extrínseca, por ejemplo mediante plataformas y automatización, para que la capacidad se dedique a las de tipo intrínseco y pertinente.

Para los arquitectos, la consecuencia es directa. El límite de un servicio o componente debe dar al equipo que lo posee una parte del sistema que pueda entender por completo. Si un equipo posee doce servicios repartidos en cuatro dominios, el equipo está sobrecargado y se resentirán la calidad, la velocidad o la salud de las guardias, por limpio que sea el código de cada servicio. A la inversa, un dominio tan complicado que ningún equipo alineado al flujo puede absorberlo (un motor de precios con modelos actuariales, un códec de video) puede justificar un equipo especializado y un límite claro en torno a su subsistema.

Dejar que la estructura de equipos dé forma a los límites

En conjunto, estas ideas ofrecen a los arquitectos un conjunto de reglas de trabajo:

Alinea los límites con la propiedad de los equipos. Cada módulo, servicio, almacén de datos y pipeline debe tener un único equipo propietario. La propiedad compartida, en la práctica, significa ausencia de propiedad, y el código reflejará lo que necesitara el último que contribuyó.

Minimiza la comunicación que necesita cada cambio. Un límite está en el lugar correcto si la mayoría de los cambios en una capacidad de negocio puede hacerlos, probarlos y desplegarlos un solo equipo. Vigila los cambios que habitualmente necesitan que se coordinen tres equipos: muestran que la estructura del sistema y la estructura de equipos no coinciden.

Haz que las interfaces entre equipos sean explícitas y estables. Las interfaces entre equipos merecen versionado, documentación y pruebas de contrato; las interfaces dentro de un equipo pueden seguir siendo informales y cambiar libremente.

Revisa ambas cosas a la vez. Las reorganizaciones son decisiones de arquitectura; las decisiones de arquitectura son decisiones organizativas. Un arquitecto al que no se consulta sobre los cambios de equipos, o un responsable que reorganiza sin tener en cuenta el código, está ignorando una fuerza que actuará de todos modos.

Los patrones de tipos de equipo y modos de interacción, y cómo hacerlos evolucionar, se tratan en Team Topologies y diseño sociotécnico.