El software sale con la forma de la organización
Conway lo observó en 1967 y sigue siendo la explicación más económica de por qué los sistemas terminan como terminan: las interfaces de un sistema copian las líneas de comunicación de quienes lo construyen, se quiera o no.
Tres equipos construyen un compilador; el compilador sale con tres pasadas. Un equipo de frontend y uno de backend construyen un producto; el producto sale con una separación tajante entre pantallas y API, aunque para el usuario sea una sola cosa.
Melvin Conway lo escribió en 1967: las organizaciones diseñan sistemas que copian sus propias estructuras de comunicación. No es una maldición ni una metáfora: es la consecuencia práctica de que es mucho más fácil coordinar dentro de un equipo que entre equipos.
Por qué pasa
No hace falta creer en ninguna fuerza misteriosa. El mecanismo es cotidiano:
Cómo se produce, paso a paso
- Dentro de un equipo, acordar cuesta poco. Una conversación de cinco minutos y el cambio se hace en los dos lados a la vez.
- Entre equipos, acordar cuesta mucho. Hay que coordinar prioridades, esperar, negociar plazos y a veces convencer a un tercero.
- La gente elige el camino barato. Ante un problema, se prefiere la solución que se resuelve adentro antes que la que requiere ponerse de acuerdo con otro equipo.
- Esa preferencia, repetida mil veces, se solidifica en la arquitectura. Las fronteras del software terminan donde estaban las fronteras de la conversación.
Cómo se ve en la práctica
| Organización | Sistema que produce |
|---|---|
| Equipos de frontend y backend separados | APIs que exponen la estructura de la base de datos en vez de lo que la pantalla necesita |
| Un equipo por cliente grande | Una bifurcación del producto por cliente, imposible de actualizar junta |
| Un equipo de base de datos centralizado | Un esquema compartido que nadie puede cambiar sin coordinar con todos |
| Equipos por país o región | Lógica duplicada, con diferencias que nadie recuerda por qué existen |
| Un equipo dueño de un módulo de punta a punta | Un módulo con interfaz clara y despliegue independiente |
Antes de seguir, predecí
Usarlo a favor
La consecuencia práctica es lo que se conoce como maniobra inversa de Conway: si sabés qué arquitectura querés, organizá los equipos con esa forma y la arquitectura tiende a seguirla.
Cómo se aplica
- Dibujá la arquitectura objetivo primero. Qué piezas, con qué interfaces entre ellas.
- Mirá si tus equipos tienen esa forma. Si querés tres servicios independientes y tenés un equipo por capa, no vas a llegar.
- Reorganizá antes de migrar, no después. Es el paso que se omite siempre y el que más determina el resultado.
- Verificá con una pregunta. ¿Puede cada equipo desplegar su parte sin esperar a otro? Si la respuesta es no, todavía no están separados.
Más a fondo · nivel seniorCuando no se puede reorganizar
Muy seguido no está en tu mano cambiar la estructura de equipos. Ahí quedan tres palancas más chicas y reales. La primera es hacer explícitas las interfaces entre equipos y tratarlas como contratos con versión: si la frontera va a existir igual, que al menos esté bien definida. La segunda es reducir la frecuencia de coordinación, convirtiendo pedidos recurrentes en algo autogestionado. La tercera es asignar dueños por dominio dentro de un mismo equipo, que reproduce la separación deseada sin mover a nadie de lugar.
Ninguna de las tres es tan potente como alinear la organización. Todas son mejores que diseñar una arquitectura que la organización no puede sostener y ver cómo se erosiona durante dos años.
El organigrama y la arquitectura, uno al lado del otro
Una organización clásica por especialidad: frontend, backend, datos. Cada uno con su jefatura y su reunión.
Lo que preguntan sobre esto
Cierre
Autoevaluación
¿Lo entendiste?
Práctica