En 1968, Melvin Conway enunció una verdad que hoy, en la era de la IA y los microservicios, es más relevante que nunca: «Las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones».
Nota: Si tienes tres equipos trabajando en un compilador, acabarás teniendo un compilador de tres fases. No es una coincidencia, es una restricción sistémica. Como Jefe de Proyectos, si intentas forzar una arquitectura de microservicios en un equipo monolítico y centralizado, el sistema fallará por pura fricción comunicativa.
La Maniobra Inversa de Conway
No esperes a que el software dicte los problemas de comunicación. Haz lo contrario: diseña la organización que deseas para obtener la arquitectura que necesitas. Esto es la Maniobra Inversa de Conway.
- Para Monolitos Eficientes: Equipos grandes y multidisciplinares con comunicación fluida y síncrona.
- Para Microservicios/IA: Equipos pequeños, autónomos y con APIs de comunicación claras entre ellos (contratos de equipo).
Impacto en Proyectos de IA
En sistemas de IA, la ley de Conway se manifiesta en el aislamiento del dato. Si el equipo de Data Engineering está separado por silos del equipo de ML Ops, el resultado será un pipeline de datos frágil y desacoplado. La solución no es más software, es reestructurar el flujo de reuniones y responsabilidades.
Recurso Gratis: Plantilla de Diseño de Topología de Equipos
He preparado una guía visual basada en el framework Team Topologies para que identifiques si la estructura de tus equipos está remando a favor o en contra de tu arquitectura técnica.
Nota adicional: Muchos PMs creen que «ser ágiles» es poner a todos a hablar con todos (comunicación total). En sistemas complejos, la comunicación total es ruido. La buena topología de equipos busca la comunicación mínima necesaria mediante interfaces claras. No busques equipos que se lleven bien; busca equipos que no necesiten interrumpirse.
Preguntas que te podrías estar haciendo
Es la estrategia de organizar los equipos de trabajo de una empresa de modo que su estructura de comunicación refleje la arquitectura de software que se desea obtener (por ejemplo, equipos autónomos para lograr microservicios).
El trabajo remoto tiende a favorecer comunicaciones asíncronas y documentadas, lo cual facilita arquitecturas desacopladas. Sin embargo, si no hay herramientas de orquestación claras, el sistema puede volverse fragmentado e inconsistente.
No. Es una ley sociológica de los sistemas. La única opción es trabajar con ella a favor mediante el diseño organizacional consciente, en lugar de luchar contra el flujo natural de la información.
Referencias Bibliográficas
- Conway, M. E. (1968). «How do committees invent?». Datamation.
- Skelton, M., & Pais, M. (2019). «Team Topologies: Organizing Business and Technology Teams for Fast Flow». IT Revolution Press.
