La Ley de Conway y las estructuras organizacionales

En 1967, Melvin Conway publicó una observación que la industria tardó décadas en tomar en serio:

“Las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de esas organizaciones.”

No es una teoría. Es una descripción de algo que ocurre independientemente de si lo buscas o no. Cada vez que una empresa divide equipos, define responsabilidades o construye fronteras organizacionales, está tomando decisiones de arquitectura de software — aunque nadie en la sala lo llame así.

La Ley de Conway no es una advertencia. Es un mecanismo. Y como todo mecanismo, puede usarse a favor o en contra.

Por qué la ley se cumple siempre

La razón es estructural: el software es, en su forma más profunda, un sistema de comunicación. Los módulos se comunican a través de interfaces. Los servicios se comunican a través de APIs. Los equipos se comunican a través de reuniones, tickets, canales de Slack, y documentos.

Cuando dos equipos distintos son dueños de dos componentes distintos, esos componentes tienden a comunicarse de la misma manera que los equipos: con contratos formales, poca confianza implícita, y mucha documentación defensiva.

Cuando un solo equipo es dueño de dos componentes, esos componentes tienden a comunicarse de manera informal: llamadas directas, estado compartido, dependencias implícitas que solo el equipo conoce.

La estructura organizacional crea los canales de comunicación. El software reproduce esos canales.

Organización con tres equipos verticales (Frontend, Backend, Datos):
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   Frontend   │────▶│   Backend    │────▶│    Datos     │
│    Team      │     │    Team      │     │    Team      │
└──────────────┘     └──────────────┘     └──────────────┘
        │                   │                    │
        ▼                   ▼                    ▼
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   SPA / UI   │────▶│  REST API    │────▶│   DB + ETL   │
│   (capa)     │     │   (capa)     │     │   (capa)     │
└──────────────┘     └──────────────┘     └──────────────┘

Resultado: arquitectura en capas horizontales, aunque el negocio
sea vertical. Los cambios de negocio tocan los tres equipos.

Este es el caso clásico: una organización dividida por capas técnicas produce inevitablemente una arquitectura en capas. No porque sea la mejor opción — sino porque es la que refleja cómo se comunican las personas.

El diseño de arquitectura como consecuencia organizacional

Si observas la arquitectura de un sistema durante suficiente tiempo, puedes reconstruir el organigrama de la empresa que lo construyó. Los límites entre módulos marcan los límites entre equipos. Las interfaces más formales y documentadas separan a los equipos con más fricción de comunicación. Los acoplamientos más fuertes unen a las personas que trabajan en la misma sala.

Esto tiene consecuencias directas en las decisiones técnicas:

Microservicios sin reorganización son un error predecible. Muchas empresas adoptan microservicios buscando independencia de despliegue y escalabilidad. Pero si los equipos siguen organizados de la misma forma, los servicios reproducen las mismas dependencias que tenían los módulos del monolito. El resultado es un monolito distribuido — con toda la complejidad de los microservicios y ninguna de sus ventajas.

Los bounded contexts de DDD son límites organizacionales, no solo técnicos. Un Contexto Delimitado no es solo un paquete de código. Es el dominio de responsabilidad de un equipo. Si el límite técnico no coincide con el límite organizacional, uno de los dos cederá — y generalmente cede el técnico.

La latencia de coordinación se convierte en latencia de sistema. Si dos servicios pertenecen a equipos distintos que coordinan a través de tickets y reuniones semanales, los cambios que cruzan esa frontera toman semanas. La arquitectura del sistema hereda el ciclo de entrega de la organización.

La pregunta que todo arquitecto debería hacerse antes de diseñar un sistema no es “¿qué módulos necesitamos?” sino “¿qué equipos los van a mantener, y cómo van a comunicarse?”

La Maniobra Inversa de Conway

Si la Ley de Conway describe cómo la organización moldea la arquitectura, la Maniobra Inversa de Conway (Inverse Conway Maneuver) propone lo contrario: diseña primero la arquitectura que quieres, y luego organiza los equipos para que la produzcan naturalmente.

El concepto fue popularizado por Thoughtworks en su Technology Radar, y es la base del enfoque de Team Topologies (Matthew Skelton y Manuel Pais, 2019).

La idea es deceptivamente simple: si quieres una arquitectura de servicios independientes, necesitas equipos que puedan trabajar de forma independiente. Si quieres un sistema con límites claros entre dominios, necesita equipos que tengan límites claros de responsabilidad.

No es suficiente con dibujar la arquitectura ideal en un pizarrón. Hay que construir la organización que la va a producir.

Maniobra Inversa de Conway: definir la arquitectura objetivo
y organizar equipos para producirla naturalmente.

Arquitectura deseada: servicios por dominio de negocio
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│   Pedidos   │  │   Pagos     │  │  Inventario │
│  (dominio)  │  │  (dominio)  │  │  (dominio)  │
└─────────────┘  └─────────────┘  └─────────────┘

Organización que la produce:
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│  Team       │  │  Team       │  │  Team       │
│  Pedidos    │  │  Pagos      │  │  Inventario │
│ (full-stack)│  │ (full-stack)│  │ (full-stack)│
└─────────────┘  └─────────────┘  └─────────────┘

Cada equipo es dueño completo de su dominio.
Los cambios de negocio viven dentro de un solo equipo.

Cómo Conway moldea la documentación

La documentación de un sistema refleja, con precisión casi perfecta, las fronteras organizacionales.

Los documentos más completos y actualizados describen las interfaces entre equipos — porque esas interfaces tienen dueños que dependen de que otros las entiendan. Las interfaces internas de un mismo equipo rara vez tienen documentación: el conocimiento vive en las conversaciones, en el código, o en la cabeza de las personas.

Esto explica un patrón que se repite en casi todas las organizaciones:

La documentación externa está relativamente bien. Las APIs públicas tienen Open API Specification (OAS). Los contratos entre servicios de distintos equipos tienen especificaciones. Los acuerdos de nivel de servicio están escritos.
La documentación interna es caótica o inexistente. La lógica de negocio dentro de un bounded context no tiene documentación útil. Los flujos internos de un equipo son conocimiento tácito.

La consecuencia es que cuando alguien cambia de equipo, o cuando un equipo crece y incorpora personas nuevas, el conocimiento que existía solo como conocimiento social desaparece o se degrada.

Una organización que quiera documentación útil y sostenible necesita reconocer esta dinámica y diseñar intencionalmente los incentivos para documentar hacia adentro, no solo hacia afuera.

Architecture Decision Records (ADRs) son especialmente efectivos en este contexto porque capturan decisiones con su razonamiento — no solo el qué, sino el por qué, y el contexto que existía cuando se tomó la decisión. Son documentación interna que sobrevive a la rotación de personas.

Planes de carrera que ignoran Conway

El diseño de los planes de carrera en organizaciones de ingeniería está profundamente influenciado por la estructura organizacional — y cuando esa estructura contradice la arquitectura técnica, los planes de carrera refuerzan el problema.

El ejemplo más común: una organización organizada por especialidades técnicas (frontend, backend, datos, infraestructura) con planes de carrera que premian la profundidad en esa especialidad. El resultado:

Los ingenieros se vuelven expertos en una capa técnica, no en un dominio de negocio.
El conocimiento del dominio queda fragmentado entre especialidades.
Los cambios de negocio requieren coordinar múltiples equipos con incentivos distintos.
La carrera de un ingeniero avanza alejándose del problema real, no acercándose.

En contraste, las organizaciones que diseñan planes de carrera orientados al dominio — donde crecer significa entender mejor un dominio de negocio, tener mayor impacto en él, y eventualmente liderar dentro de él — producen equipos que alinean el conocimiento técnico con el conocimiento del negocio.

Esto no significa que la especialidad técnica no importe. Significa que la especialidad técnica al servicio de un dominio es más valiosa que la especialidad técnica en abstracto.

Un Staff Engineer que entiende profundamente el dominio de pagos es más valioso que uno que conoce todos los patrones de mensajería pero no puede articular por qué el equipo de pagos usa un modelo de consistencia eventual en lugar de transacciones distribuidas.

La comunicación interna como arquitectura invisible

Cada decisión sobre cómo fluye la información dentro de una organización es, implícitamente, una decisión de arquitectura.

¿Los equipos tienen reuniones semanales de sincronización? Entonces los cambios que cruzan esas fronteras tienen una latencia mínima de una semana. ¿Las decisiones técnicas requieren aprobación de un comité de arquitectura central? Entonces todos los servicios convergerán hacia la visión de ese comité, independientemente de lo que necesite cada dominio.

Algunos patrones de comunicación y sus consecuencias en la arquitectura:

Plataformas internas de ingeniería (IDP) — cuando un equipo de plataforma construye herramientas para que otros equipos sean autónomos, está creando una capa de abstracción que reduce la fricción de comunicación. Los equipos consumen APIs de plataforma en lugar de coordinar con personas. La arquitectura se vuelve más desacoplada porque la organización se volvió más desacoplada.

Guilds y comunidades de práctica — los canales de comunicación horizontal (entre personas con el mismo rol en distintos equipos) producen convergencia de prácticas sin centralización de decisiones. Son el equivalente organizacional de un protocolo de sincronización eventual: cada equipo mantiene autonomía, pero el conocimiento se propaga.

Reuniones de dependencias — si los equipos necesitan una reunión regular para gestionar sus dependencias mutuas, esa reunión es una señal de que el acoplamiento en el código es real. La reunión es la interfaz — el código tiene una dependencia que la organización gestiona con comunicación.

Señales de que Conway está trabajando en tu contra

No siempre es obvio cuándo la estructura organizacional está produciendo problemas de arquitectura. Estas son señales a observar:

Síntoma técnico → Causa organizacional probable:

“Cualquier feature toca tres equipos” → Los límites de los equipos no coinciden con los límites del negocio.
“Nadie sabe quién es dueño de ese servicio” → El servicio creció más allá del equipo que lo creó, sin que nadie rediseñara la propiedad.
“La documentación siempre está desactualizada” → No hay incentivos para documentar hacia adentro; la documentación es obligación hacia otros equipos, no hacia el propio.
“Las decisiones de arquitectura tardan meses en aprobarse” → La autoridad de decisión está centralizada en un grupo que no tiene el contexto local para decidir rápido.
“Tenemos microservicios pero seguimos desplegando todo junto” → Los servicios tienen más acoplamiento que lo que la estructura organizacional puede gestionar de forma independiente.

Usar Conway a favor

La Ley de Conway no es una condena. Es un mapa. Una vez que entiendes el mecanismo, puedes usarlo intencionalmente.

El proceso para hacerlo:

Define primero la arquitectura objetivo — no el estado actual, sino el sistema que quieres tener. Identifica los bounded contexts naturales del negocio, los límites de responsabilidad, las interfaces entre dominios.
Evalúa el alineamiento actual — ¿cómo se mapean los equipos actuales a esa arquitectura objetivo? ¿Dónde hay fricción porque las fronteras no coinciden?
Diseña los equipos para que produzcan la arquitectura — reorganiza gradualmente, siguiendo los principios de Team Topologies: equipos orientados a stream, equipos de plataforma, equipos de habilitación, equipos de subsistema complicado.
Alinea la documentación y los planes de carrera — documenta los límites de los dominios, no solo las interfaces técnicas. Diseña carreras que crezcan dentro de dominios, no solo dentro de especialidades.
Diseña los canales de comunicación — identifica qué comunicación es necesaria y cuál es síntoma de acoplamiento. Reduce la comunicación que es parche, no la que es genuinamente necesaria.

Este no es un proceso de semanas. Es un proceso de meses o años. Pero cada paso en la dirección correcta produce mejoras visibles: features que antes tocaban tres equipos empiezan a vivir en uno; decisiones que tardaban meses empiezan a tomarse localmente; la documentación mejora porque los incentivos mejoran.

Cierre

Conway observó algo que la mayoría de las organizaciones prefiere ignorar: las decisiones organizacionales son decisiones de arquitectura. Cada vez que defines un equipo, asignas responsabilidades, o diseñas cómo fluye la comunicación, estás diseñando el sistema que ese equipo va a construir.

La pregunta no es si la Ley de Conway aplica en tu organización. Aplica siempre. La pregunta es si vas a diseñar intencionalmente la organización para producir la arquitectura que quieres, o si vas a dejar que la organización produzca por accidente la arquitectura que le resulta natural.

La diferencia entre esas dos opciones es la diferencia entre una estrategia técnica y una acumulación de consecuencias no buscadas.