Módulo 2: La Ley de Conway
1. Presentación del módulo: shipeas tu organigrama
Descripción
Al terminar esta lección vas a entender la ley más subestimada del oficio, la que explica por qué tantos rediseños "perfectos" fracasan sin que nadie sepa por qué: la estructura de un sistema es una copia de la estructura de comunicación de la organización que lo construye. La formuló Melvin Conway en 1968 y por eso se llama la Ley de Conway, pero en los pasillos se dice más corto y más brutal: shipeas tu organigrama. No importa qué tan bonito sea tu diagrama; el software que sale al final tiene la forma de cómo se comunican los equipos que lo escribieron. Si dos equipos casi no se hablan, la juntura entre sus dos pedazos de sistema va a ser frágil y va a estar justo ahí, en el silencio entre ellos. Si un equipo hace todo, el sistema va a ser una sola bola sin costuras internas. No es una tendencia ni una superstición: es una fuerza tan confiable como la gravedad organizacional, y este módulo entero es aprender a verla, medirla y —lo más importante— usarla a tu favor.
Esto importa porque reubica el mayor apalancamiento del arquitecto. En el módulo 1 vimos que el arquitecto no es el que dibuja el diagrama y se va; es el que habilita, comunica y hace reversibles las decisiones caras. La Ley de Conway le pone números a por qué: si el sistema copia la organización, entonces el diagrama no es la palanca —la organización lo es—. Puedes dibujar tres servicios independientes hasta que te duela la mano, pero si se los entregas a dos equipos que comparten todo y se pisan a diario, no vas a obtener tres servicios independientes: vas a obtener un monolito distribuido, que es lo peor de los dos mundos —la complejidad de la red sin la independencia de los servicios—. La estructura de comunicación real siempre le gana al diagrama deseado. Por eso el arquitecto que entiende Conway deja de pelear contra el organigrama y empieza a tratarlo como lo que es: la primera decisión de arquitectura, y la más difícil de revertir.
Conexión con el módulo: esta lección es el mapa, no el territorio. Aquí no mides nada todavía a fondo; entiendes por qué las seis lecciones que siguen van en el orden que van. Primero el enunciado y su medición: la lección 2 formula la ley y mide el espejo org↔código sobre Mercado. Luego el origen de casi todo monolito: la lección 3 muestra por qué el monolito de Mercado refleja el equipo único que lo parió, y qué pasa cuando la organización crece pero el código no. Después el mecanismo económico que lo explica: la lección 4 ejecuta n(n-1)/2 y demuestra por qué la coordinación explota y los equipos chicos ganan. Con eso ya puedes diagnosticar la enfermedad: la lección 5 mide la fricción del módulo que cruza dos equipos —el checkout de Mercado—. Y las dos últimas te dan la cura: la lección 6 es la maniobra inversa de Conway (cambiar la organización para obtener la arquitectura), y la 7 son las team topologies de Skelton & Pais —los cuatro tipos de equipo y los tres modos de interacción—. La lección 8, el proyecto, te pone a rediseñar la organización de Mercado para una capacidad nueva con tus manos.
Un puente construido por dos cuadrillas que no se hablan
Piénsalo así. Una constructora tiene que levantar un puente que cruce un río ancho. El puente es uno solo, pero el trabajo se reparte entre dos cuadrillas: la del norte arranca desde la orilla norte, la del sur desde la orilla sur, y se supone que se encuentran en el centro. Las dos cuadrillas son buenísimas. El problema es que trabajan en campamentos separados, a kilómetros de distancia, con jefes distintos, y coordinan por correos que a veces se contestan y a veces no. Cada una interpreta los planos a su manera. La del norte usa un cierto grosor de acero; la del sur, otro. La del norte deja los pernos a la izquierda; la del sur los espera a la derecha.
¿Dónde va a estar el punto débil del puente? No es un misterio. Va a estar exactamente en el centro, en la juntura donde las dos cuadrillas se encuentran —justo donde su comunicación era más pobre—. Toda la longitud que construyó una sola cuadrilla va a estar bien, porque ahí la mano derecha sabía lo que hacía la izquierda. Pero en la costura, donde dos organizaciones que apenas se hablaban tuvieron que embonar su trabajo, es donde aparecen los milímetros que no cuadran, el acero de grosores distintos, los pernos que no alinean. La juntura del puente cae donde se dividió la organización que lo construyó. No porque las cuadrillas fueran malas, sino porque una juntura física es el reflejo de una juntura de comunicación.
El software funciona igualito. Cada vez que dos equipos tienen que hacer embonar dos pedazos de sistema, ahí —en esa integración, en ese contrato, en ese formato que uno produce y otro consume— es donde aparecen los bugs de integración, las suposiciones que no coinciden, el campo que uno mandaba como texto y otro esperaba como número. Y ese punto de fricción cae precisamente donde se dividió la organización. Si quieres saber dónde va a fallar un sistema antes de que se construya, no mires el diagrama técnico: mira el organigrama, y busca los lugares donde dos equipos que no se hablan bien van a tener que embonar su trabajo. Ahí está tu juntura frágil. Eso es la Ley de Conway, y por eso es tan útil: te deja predecir la forma del sistema mirando la forma de la organización.
El caso: Mercado y sus cinco squads
Bajemos del puente al software. A lo largo de esta guía acompañamos a Mercado, el marketplace del ecosistema. Pero ya no es solo un sistema: es un sistema y su organización. Hoy Mercado tiene cinco squads:
catalog— el catálogo de productos y la búsqueda.orders— el carrito, el procesamiento de pedidos y el checkout.payments— el cobro y la facturación.shipping— las etiquetas de envío y el seguimiento de entregas.platform— las capacidades transversales: autenticación, notificaciones, la infraestructura compartida.
No siempre fueron cinco. En 2019, Mercado era un solo equipo de siete personas que escribió un monolito —todo en una sola base de código, un solo despliegue—. Funcionó de maravilla mientras fueron pocos. Pero el negocio creció, contrataron, y en algún momento partieron a la gente en cinco squads por dominio. Lo que no partieron fue el código: el monolito sigue siendo un monolito, y ahora cinco squads intentan poseerlo por pedazos, pisándose en las junturas. El síntoma más doloroso es el checkout: un módulo que orders considera suyo pero que payments toca todo el tiempo, porque el checkout es donde el pedido y el cobro se abrazan. Cada cambio al checkout necesita a los dos squads de acuerdo. Es lento, es frágil, y nadie entiende bien por qué —hasta que ves que la culpa no es de las personas, es de la estructura—.
A lo largo del módulo vamos a medir todo esto en Mercado, no a afirmarlo. Pero antes de medir nada, veamos la Ley de Conway en su forma más pura: la capacidad de predecir la arquitectura mirando la organización. Fíjate bien, porque en este pedacito de código está condensado el módulo entero.
# Conway en una linea: dame como se comunica tu organizacion
# y te digo donde van a caer las junturas de tu sistema.
# Ambos grafos son EL MISMO grafo.
# Como se comunican los squads de Mercado hoy (quien coordina con quien):
org_comm = [
("orders", "catalog"),
("orders", "payments"),
("orders", "shipping"),
("orders", "platform"),
("payments", "platform"),
]
n_squads = 5
print(f"Squads en Mercado: {n_squads}")
print(f"Canales de comunicacion activos entre squads: {len(org_comm)}")
print()
print("Conway predice: el sistema tendra UNA juntura (interfaz entre modulos)")
print("por cada canal de comunicacion. Las junturas caeran EXACTAMENTE aqui:")
for a, b in org_comm:
print(f" interfaz {a} <--> {b}")
print()
print(f"Junturas predichas en el sistema: {len(org_comm)}")
print("El organigrama de comunicacion y el mapa de modulos son el mismo dibujo.")Qué esperar. Al correrlo:
Squads en Mercado: 5
Canales de comunicacion activos entre squads: 5
Conway predice: el sistema tendra UNA juntura (interfaz entre modulos)
por cada canal de comunicacion. Las junturas caeran EXACTAMENTE aqui:
interfaz orders <--> catalog
interfaz orders <--> payments
interfaz orders <--> shipping
interfaz orders <--> platform
interfaz payments <--> platform
Junturas predichas en el sistema: 5
El organigrama de comunicacion y el mapa de modulos son el mismo dibujo.
Detente en la última línea, porque es toda la ley en una frase. No corrimos ningún análisis técnico del sistema; solo miramos cómo se comunican los cinco squads y con eso predijimos dónde va a tener el sistema sus interfaces entre módulos. Cada canal de comunicación entre dos squads se va a materializar como una juntura en el código —una API, un contrato, un formato compartido—, y esas junturas van a caer exactamente donde están los canales. El organigrama de comunicación y el mapa de módulos no son dos dibujos parecidos: son el mismo dibujo. Por eso Conway es tan poderosa como herramienta de predicción: te deja leer la forma futura del sistema en la forma presente de la organización, antes de escribir una línea.
Ahora, fíjate en algo que este teaser ya insinúa y que va a ser el hilo del módulo: orders está en el centro de casi todo —habla con catalog, con payments, con shipping y con platform—. Cuatro de los cinco canales pasan por orders. Eso no es casualidad: es porque el checkout, que vive en orders, es el punto donde todo el flujo de compra se junta. Un módulo que necesita hablar con cuatro equipos distintos es un módulo que va a acumular fricción, y en la lección 5 vamos a medir exactamente cuánta. Por ahora, quédate con la intuición: la topología de la organización ya te está diciendo dónde va a doler el sistema.
El mapa de las seis lecciones
Las seis lecciones que siguen van en este orden por una razón: cada una arma la pieza que la siguiente necesita.
| Lección | Qué te da | Por qué va aquí |
|---|---|---|
| 2 | El enunciado de la ley y la medición del espejo org↔código | No puedes usar Conway hasta enunciarla con precisión y medirla, no solo citarla |
| 3 | Por qué el monolito refleja el equipo único que lo parió | Es el caso más común de Conway en la vida real, y explica de dónde viene el dolor de Mercado |
| 4 | El costo de coordinación: n(n-1)/2, ejecutado | Es la razón económica de que Conway opere y de que los equipos chicos ganen |
| 5 | La fricción del módulo que cruza dos equipos, medida | Es el diagnóstico: dónde exactamente cobra Conway su impuesto en Mercado |
| 6 | La maniobra inversa de Conway | Es la cura: cambiar la organización para obtener la arquitectura que quieres |
| 7 | Las team topologies (los 4 tipos, los 3 modos) | Es el vocabulario para diseñar la organización a propósito, no por accidente |
El arco es: primero aprendes a ver y medir la ley (2), luego entiendes de dónde viene el monolito típico (3) y por qué la coordinación cuesta tanto (4), luego diagnosticas la fricción concreta (5), y al final aplicas las dos herramientas de cura: la maniobra inversa (6) y el vocabulario de topologías para diseñar la organización a propósito (7). La lección 8 —el proyecto— junta todo sobre una capacidad nueva de Mercado que no vimos, para que confirmes que aprendiste el método y no memorizaste el caso.
Lo que este módulo NO toca
Conviene marcar la frontera desde ahora, porque hay temas vecinos que parecen de aquí y son de otra parte.
Qué hace un arquitecto en general fue el módulo 1. Ahí vimos el rol —facilitador, no dictador; el que hace reversibles las decisiones caras—. Este módulo se concentra en una sola dimensión de ese rol: la dinámica entre la organización y la arquitectura. Cuando aquí digamos "el arquitecto reestructura los equipos", damos por sabido por qué el arquitecto tiene esa responsabilidad (eso fue M1) y nos enfocamos en cómo la estructura de equipos moldea el sistema.
Comunicar la arquitectura con diagramas es el módulo 3. En este módulo vamos a dibujar organizaciones y dependencias con diagramas simples y con tablas ejecutadas, pero cómo se comunica una arquitectura a distintas audiencias —el C4 model (Context/Container/Component/Code), el diagrama para el VP contra el diagrama para el dev— es el módulo 3. Aquí los diagramas son para entender la dinámica org↔sistema, no para comunicarla a un stakeholder; esa es otra habilidad y va después.
La reestructuración detallada de personas (management) queda fuera. Vamos a hablar de mover equipos, crear un squad nuevo, cambiar quién posee qué. Pero cómo se ejecuta ese cambio con las personas —los 1:1s, las evaluaciones de desempeño, la política de a quién se le da la noticia y cómo— es gestión de gente, y no es de esta guía. Aquí trabajamos la dinámica org↔arquitectura: qué forma de organización produce qué forma de sistema, y cómo elegir la forma que quieres. El cómo humano de llegar ahí es un oficio hermano que se apoya en este, pero no lo cubrimos.
Errores comunes
Creer que Conway es una anécdota graciosa y no una ley (de subestimación). Qué pasa: alguien escucha "shipeas tu organigrama", se ríe, lo repite en una charla, y sigue diseñando como si la organización no existiera —dibuja la arquitectura ideal y la entrega esperando que se cumpla—. Por qué pasa: Conway suena a chiste de oficina, no a restricción física, así que se trata como color y no como ingeniería. Cómo detectarlo: si tu plan de arquitectura no menciona ni una sola vez cómo están organizados los equipos, estás ignorando la mitad del problema. Cómo corregirlo: es todo el módulo —empezar a tratar el organigrama como la primera decisión de arquitectura, no como un dato ajeno—.
Pelear contra el organigrama en vez de usarlo (de terquedad). Qué pasa: el arquitecto ve que la organización va a producir una arquitectura que no le gusta, y en vez de cambiar la organización, insiste en el diagrama y se frustra cuando el sistema sale con la forma de los equipos y no la del diagrama. Por qué pasa: cambiar un diagrama se siente al alcance de la mano; cambiar equipos se siente fuera de su autoridad. Cómo detectarlo: si te descubres repitiendo "pero el diseño dice que estos servicios son independientes" mientras el sistema claramente no lo es, estás peleando contra Conway. Cómo corregirlo: la maniobra inversa (lección 6) —si quieres servicios independientes, forma equipos independientes; la fuerza de Conway deja de ser tu enemiga y se vuelve tu herramienta—.
Confundir el diagrama con la arquitectura real (de ilusión). Qué pasa: el equipo tiene un diagrama hermoso de cajitas separadas y jura que "así está diseñado el sistema", cuando en la práctica todo se toca todo porque los equipos comparten y se pisan. El diagrama describe la organización que quisieran tener, no la que producen. Por qué pasa: el diagrama es aspiracional y nadie lo confronta contra la estructura de comunicación real. Cómo detectarlo: compara el diagrama con quién-habla-con-quién de verdad; si no coinciden, el diagrama miente y el sistema va a tener la forma de la comunicación, no la del dibujo. Cómo corregirlo: mide el espejo (lección 2) —la arquitectura real es la que la organización puede sostener, no la que el diagrama promete—.
Ejercicios
Ejercicio 1 — Predice la juntura. Una empresa tiene un equipo de frontend en una ciudad y un equipo de backend en otra, en husos horarios distintos, que coordinan por tickets. Sin saber nada técnico del producto, ¿dónde predice la Ley de Conway que va a estar el punto más frágil del sistema, y por qué? ¿Qué forma de arquitectura es casi inevitable que produzcan?
Ver solución
La juntura frágil va a caer exactamente en el contrato entre el frontend y el backend —la API que los conecta—, porque ahí es donde se encuentran dos organizaciones que se comunican mal (husos distintos, coordinación por tickets, cero conversación fluida). Es el centro del puente entre las dos cuadrillas.
La arquitectura casi inevitable: un frontend y un backend fuertemente separados por una API que se vuelve un campo de batalla —cambios que uno pide y el otro tarda semanas en entregar, malentendidos sobre el formato de los datos, features que se atoran porque requieren coordinar los dos lados y la coordinación es cara—. No van a producir, por ejemplo, features verticales de punta a punta (un equipo que hace su pedacito de frontend y de backend), porque para eso los dos lados tendrían que estar en el mismo equipo. La organización (frontend / backend) impone la arquitectura (capas separadas por una API tensa). Si lo que se quisiera fueran features independientes de punta a punta, habría que reorganizar en equipos verticales —que es, exactamente, la maniobra inversa de la lección 6—.
Ejercicio 2 — El diagrama que miente. El arquitecto de una startup presenta un diagrama de tres microservicios "totalmente independientes". Investigas y descubres que los tres los mantienen las mismas cuatro personas, que se sientan juntas, comparten una base de datos y despliegan todo al mismo tiempo. ¿Qué va a producir esa organización, sin importar lo que diga el diagrama? ¿Por qué el diagrama es aspiracional y no descriptivo?
Ver solución
Esa organización —cuatro personas juntas, base de datos compartida, despliegue conjunto— va a producir un monolito, aunque el diagrama diga "microservicios". Por Conway, la estructura de comunicación (un solo grupo que se comunica constantemente y comparte todo) se copia en la estructura del sistema (una sola cosa acoplada). Tres "servicios" que comparten base de datos y se despliegan juntos no son independientes: son un monolito partido en tres carpetas. En cuanto uno necesite cambiar el esquema de la base, los otros dos se enteran y hay que coordinar —es decir, están acoplados, que es justo lo que un microservicio no debería estar—.
El diagrama es aspiracional: describe la arquitectura que al arquitecto le gustaría tener, no la que su organización puede sostener. Para que esos tres servicios fueran de verdad independientes, harían falta tres equipos que puedan trabajar y desplegar sin coordinarse —y con cuatro personas juntas eso no existe—. La lección: el diagrama describe una intención; la organización describe la realidad. Cuando chocan, gana la organización. Antes de dibujar microservicios, pregunta si la organización tiene la estructura de comunicación que los microservicios necesitan; si no, o cambias la organización, o el diagrama es ficción.
Ejercicio 3 — ¿Palanca o dibujo? Un arquitecto quiere que el checkout de Mercado deje de ser un cuello de botella entre orders y payments. Propone dos caminos: (a) rediseñar el módulo checkout en el código para separar mejor la parte de pedido de la parte de pago; (b) reorganizar los equipos para que un solo equipo posea el flujo de checkout completo. Según la Ley de Conway, ¿cuál de los dos es más probable que funcione de forma duradera, y por qué el otro tiende a revertirse?
Ver solución
El más duradero es (b), reorganizar los equipos. Según Conway, la forma del código tiende a converger a la forma de la comunicación. Si dos equipos (orders y payments) siguen compartiendo el checkout, cualquier separación que hagas en el código (a) se va a erosionar con el tiempo: como los dos equipos siguen teniendo que coordinar sobre esa área, van a volver a meter dependencias cruzadas, atajos "temporales", y en unos meses el módulo estará tan enredado como antes. La estructura de comunicación no cambió, así que la estructura del código regresa a reflejarla.
En cambio, si un solo equipo posee el flujo de checkout completo (b), la comunicación sobre el checkout pasa a ser interna a ese equipo —barata, constante, sin fronteras que cruzar—, y el código naturalmente se organiza alrededor de ese dueño único. La separación se sostiene porque la organización la respalda. Esto no quiere decir que (a) sea inútil: rediseñar el código ayuda. Pero rediseñar el código sin rediseñar los equipos es luchar contra la corriente —una y otra vez, para siempre—. La regla del módulo: reorganizar el código sin reorganizar los equipos revierte; reorganizar los equipos hace que el código se reorganice solo. Eso es, exactamente, la maniobra inversa de Conway de la lección 6.
Resumen y siguiente paso
En esta lección conociste la tesis que sostiene el módulo: shipeas tu organigrama —la estructura del sistema copia la estructura de comunicación de la organización que lo construye—. Con el puente de las dos cuadrillas viste que la juntura frágil cae donde se dividió la organización, no donde el diseño la puso. Conociste a Mercado y sus cinco squads, y su dolor concreto: un monolito que nació de un solo equipo y hoy lo pelean cinco, con el checkout como el punto de mayor fricción entre orders y payments. Y con el teaser ejecutado viste la ley en su forma más pura: dado cómo se comunican los squads, se predice dónde van a caer las junturas del sistema —el organigrama de comunicación y el mapa de módulos son el mismo dibujo—.
Antes de avanzar deberías poder: enunciar la Ley de Conway con tus palabras y explicar por qué la juntura de un sistema cae donde se divide la organización; reconocer un diagrama aspiracional (el que promete una arquitectura que la organización no puede sostener); y distinguir la palanca real (reorganizar equipos) del dibujo (rediseñar el diagrama y esperar que se cumpla).
Lo que sigue es enunciar la ley con precisión y —lo que la vuelve una herramienta y no una frase— medirla. En la lección 2 vas a conocer la formulación original de Melvin Conway (1968), vas a entender por qué opera (el diseño hereda la forma de la comunicación, no por magia sino por mecánica), y vas a construir la medición del espejo sobre Mercado: tomar el mapa de quién posee qué módulo y de qué depende cada módulo, clasificar cada dependencia en intra-equipo (barata) o cross-equipo (cara), y calcular qué tan alineados están la organización y el código. Es el paso de "intuyo que el sistema se parece a la organización" a "sé exactamente cuánto, y dónde no se parece está la fricción".
Recursos
- Melvin Conway — "How Do Committees Invent?" (1968) — el paper original donde nace la ley, escrito por el propio Conway y disponible gratis en su sitio. Corto y sorprendentemente legible; la frase exacta es "organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations". La fuente de todo el módulo.
- Skelton & Pais — Team Topologies — el libro que convirtió Conway en una disciplina de diseño organizacional; introduce la maniobra inversa y los cuatro tipos de equipo que veremos en las lecciones 6 y 7. El sitio tiene un resumen gratuito de los conceptos.
- Martin Fowler — "Conway's Law" — el ensayo de Fowler que explica la ley y la maniobra inversa en dos páginas claras, con el ejemplo clásico del compilador de dos pasos escrito por dos equipos. El mejor punto de partida en español o inglés para entender por qué la ley importa.