Ley de Conway

Cualquier organización que diseña un sistema produce un diseño cuya estructura es una copia de la estructura de comunicación de la organización.

Origen

Lo escribió el programador Melvin Conway en 1967, en el paper “How Do Committees Invent?”, después de que la revista Harvard Business Review lo rechazara por no tener “datos suficientes”. Conway había observado que un compilador hecho por cinco equipos termina teniendo cinco pasadas; un sistema operativo escrito por dos divisiones de la empresa termina partido en dos kernels. La frontera del diagrama de cajas del producto coincide casi siempre con la frontera del organigrama.

Ejemplo: microservicios y “two-pizza teams”

El caso moderno más citado es Amazon: a principios de los 2000, Bezos exigió que toda comunicación entre equipos fuera por API y que ningún equipo pudiera ser más grande de lo que se alimenta con dos pizzas. La consecuencia directa, vista en retrospectiva, es la arquitectura de microservicios de AWS: si ningún equipo puede pasar de ~8 personas y los equipos sólo se hablan por API, los servicios necesariamente quedan acoplados débilmente, desplegables por separado, con interfaces explícitas. Conway al revés: rediseñaron la organización para forzar la arquitectura que querían.

El uso operacional se llama “Inverse Conway Maneuver”: si querés un sistema modular, primero hacé equipos modulares; si querés un monolito mantenible, hacé un solo equipo con dueños claros. El antipatrón es el opuesto: 14 equipos compartiendo una base de datos y peleándose por el modelo de datos en cada review.