Hay una frase atribuida a un conocido político argentino que dice:
"Si querés que algo no se haga, creá una comisión."
La Ley de Conway en acción
Más o menos en la misma época en que ese político estaba en el poder, Melvin E. Conway publicó su paper "How Do Committees Invent?". Ahí introdujo lo que hoy conocemos como la Ley de Conway:
"Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure."
¿Alguna vez viste una home que parecía más una lucha de poder entre unidades de negocio que una buena experiencia de usuario?
Eso es la Ley de Conway en su estado puro. Los equipos terminan haciendo delivery del organigrama.
Cómo la estructura de equipos impacta en la entrega de producto
¿Alguna vez viste equipos frenados esperando a otros equipos? ¿O servicios nombrados por su implementación interna en lugar del modelo de negocio al que sirven? Otra vez Conway: tu producto termina siendo un espejo de los patrones de comunicación de tu organización.
Consciente o inconscientemente, las empresas diseñan sistemas que reflejan cómo se comunican internamente, o se la dan contra la pared intentando ir en contra.
El auge del trabajo remoto solo amplificó estos desafíos, haciendo que las estructuras claras de comunicación sean más críticas que nunca.
Muchas empresas intentan superponer frameworks "ágiles" sobre silos y jerarquías rígidas, pero ningún diseño de software puede arreglar estructuras organizacionales que introducen fricción y demoras.
Modernizar arquitecturas no es solo un esfuerzo técnico; requiere alinear la comunicación del equipo con los objetivos del producto. Por ejemplo, migrar a microservices no va a ayudar si tu equipo opera como una sola unidad grande.
Supongamos que contratás una agencia que te ofrece cuatro equipos de desarrolladores frontend y backend, y un DBA centralizado para manejar los cambios en la base de datos (esto viene de un ejemplo de Team Topologies):
Esta estructura va a llevar naturalmente a componentes separados de frontend y backend, y a una base de datos compartida:
Un DBA compartido fomenta una base de datos única, y separar los roles de frontend y backend lleva a capas separadas. Si tu objetivo es ownership descentralizado de los datos, esta estructura va a jugar en tu contra.
La Maniobra Inversa de Conway
Si tus equipos moldean tu arquitectura, ¿qué pasa cuando necesitás una arquitectura diferente? Acá es donde entra la Maniobra Inversa de Conway: en lugar de dejar que la estructura de los equipos dicte el diseño del software, se reorganizan los equipos para que coincidan con la arquitectura deseada.
Esta estrategia, destacada en el libro Accelerate, implica alinear los equipos con una arquitectura que soporte entregas rápidas e independientes. Cuando tus equipos están organizados para minimizar dependencias y cuellos de botella, pueden desplegar más rápido y con menos problemas de coordinación.
Por ejemplo, si apuntás a microservices con ownership descentralizado de datos, los límites de los equipos deberían reflejar los límites de los servicios, con cada equipo siendo dueño de una porción del producto y sus datos. Una estructura de equipo cohesiva y autónoma reduce la necesidad de comunicación constante, crucial para escalar sin fricción.
Esto no significa que una startup deba empezar con microservices. Típicamente sería sobrediseño y los servicios probablemente tendrían la granularidad equivocada. Al principio, todavía no se entiende lo suficiente la cohesión y el acoplamiento entre las entidades del negocio como para saber dónde están los límites.
Dividir el software en piezas autónomas que corren por separado hace que casi todo sea más difícil: debuggear, diagnosticar problemas, entender el sistema, manejar la latencia y los errores, entre otras cosas.
Es mejor conquistar primero y dividir después. Empezá con un monolito modular: un solo deployment con límites internos, donde los módulos son dueños de sus datos y se comunican a través de interfaces definidas. Usalo para entender qué partes del negocio pertenecen juntas y cuáles tienden a separarse.
Una vez que entendés esos límites, podés dividir el sistema en microservices donde realmente sirva hacerlo. Los límites de los módulos se convierten en puntos de extracción y el Strangler Fig Pattern te permite separarlos gradualmente.
El orden importa. Primero entendé la forma del negocio y del software. Después decidí qué partes necesitan equipos y deployments independientes. La Ley de Conway sigue aplicando; simplemente esperás hasta entender alrededor de qué te estás organizando.
