Módulo 2: La Ley de Conway

2. Shipeas tu organigrama: la ley, medida

Siguiente →

Descripción

Al terminar esta lección vas a tener la Ley de Conway convertida en una herramienta que se ejecuta, no en una frase que se cita. Primero, el enunciado exacto y su origen: en 1968 Melvin Conway escribió que "las organizaciones que diseñan sistemas están obligadas a producir diseños que son copias de las estructuras de comunicación de esas organizaciones". Vas a entender por qué eso es verdad —no por casualidad ni por mala suerte, sino por una mecánica inevitable: para que dos módulos de software encajen, las personas que los escriben tienen que ponerse de acuerdo, y ese acuerdo requiere comunicación; así que la estructura de las piezas termina calcada de la estructura de quién-habla-con-quién—. Segundo, y esto es lo que separa esta lección de un dato de trivia: vas a medir el espejo sobre Mercado. Vas a tomar el mapa de quién posee qué módulo y de qué depende cada módulo, y vas a calcular, ejecutando, qué tan alineados están la organización y el código —clasificando cada dependencia en intra-equipo (barata) o cross-equipo (cara), y derivando el grafo de comunicación que la arquitectura le exige a la organización—.

Esto importa porque la Ley de Conway solo sirve si la puedes medir. "Shipeas tu organigrama" como frase te da una intuición; medida, te da un diagnóstico. La diferencia es la misma que entre "creo que tengo fiebre" y "38.9°C". Cuando puedes calcular que el 61.5% de las dependencias de tu sistema cruzan fronteras de equipo, dejas de discutir si hay un problema de organización y empiezas a discutir cuál módulo específico lo concentra y qué reestructuración lo bajaría. La medición transforma Conway de una observación pasiva ("ah, mira, el sistema se parece a la organización") en un instrumento activo ("estas ocho dependencias cruzan equipos, y aquí está el mapa de las conversaciones que tu código exige y tu organigrama quizás no tiene"). Ese mapa —el grafo de comunicación que la arquitectura demanda— es el artefacto central de la lección, y es la materia prima de todo lo que sigue: el monolito (lección 3), la fricción (lección 5) y la maniobra inversa (lección 6).

Conexión con el módulo: esta lección pone los cimientos. La lección 1 te dio la intuición (el puente, el teaser que predice junturas); esta la vuelve rigurosa —la ley enunciada con precisión y medida sobre datos fijos—. El mapa de ownership y dependencias que construyes aquí es el mismo que vas a reusar durante todo el módulo: la lección 3 lo mide bajo dos organizaciones distintas (para explicar el monolito), la lección 5 le calcula la fricción por módulo, y la lección 6 lo reestructura con la maniobra inversa. Si la lección 1 fue "existe una ley y predice junturas", esta es "aquí está la ley, y así se mide cuánto la cumple tu sistema".

Para que dos piezas encajen, dos personas tienen que hablar

Piénsalo así, sin nada de software. Imagina que armas un mueble de esos que vienen en caja, pero el trabajo se reparte entre dos personas: una arma el lado izquierdo del clóset y la otra el derecho, y al final los dos lados tienen que unirse con unos tornillos que pasan de un lado al otro. Para que esos tornillos embonen, las dos personas tienen que ponerse de acuerdo: dónde van los agujeros, de qué diámetro, a qué altura. Si hablan bien, los agujeros coinciden y el mueble queda firme. Si no hablan —cada uno hace los agujeros donde le parece—, al momento de unir los lados los tornillos no entran, y el mueble queda cojo justo en la unión.

Ahora fíjate en la consecuencia profunda: la cantidad de "puntos de acuerdo" que necesitan las personas es exactamente la cantidad de conexiones físicas entre sus piezas. Si el diseño del mueble tuviera los dos lados unidos por veinte tornillos, las dos personas tendrían que coordinar veinte agujeros. Si el diseño los uniera por un solo perno grande, coordinarían un solo punto. La estructura de las piezas (cuántas conexiones tienen entre sí) determina cuánta comunicación hace falta entre las personas. Y aquí está el giro que descubrió Conway: la flecha también apunta al revés. Si las dos personas casi no se pueden comunicar, van a diseñar —inconscientemente— piezas que necesiten pocos puntos de acuerdo, porque coordinar es caro y lo evitan. Y si se comunican todo el tiempo, van a diseñar piezas que se entrelazan sin culpa, porque coordinar les sale gratis.

Traslada eso al software y tienes la Ley de Conway completa. Cada vez que el módulo de un equipo tiene que llamar al módulo de otro equipo —una API, un contrato, un formato de datos compartido—, las personas de los dos equipos tienen que ponerse de acuerdo sobre esa interfaz. Ese acuerdo cuesta comunicación. Como los equipos evitan (sin darse cuenta) la comunicación cara, el sistema tiende a tener sus interfaces justo donde los equipos ya se comunican, y a evitar interfaces donde los equipos no se hablan. El resultado: la estructura del sistema termina siendo una copia de la estructura de comunicación. No porque alguien lo planee, sino porque es el camino de menor resistencia. Por eso Conway no es una recomendación ("deberías alinear equipos y arquitectura") sino una ley descriptiva ("lo estés viendo o no, tu sistema ya copió tu organización").

Ejemplo trabajado: medir el espejo en Mercado

Vamos a medir la Ley de Conway sobre el monolito de Mercado. Necesitamos dos mapas. El primero, el mapa de ownership: qué squad es dueño de cada módulo del código —hoy, con los cinco squads—. El segundo, el mapa de dependencias: qué módulo depende de qué otro (quién llama a quién, quién lee los datos de quién). Con esos dos mapas podemos clasificar cada dependencia del código: si un módulo y aquel del que depende pertenecen al mismo squad, es una dependencia intra-equipo —barata, porque la coordinación es interna, la gente se sienta junta—; si pertenecen a squads distintos, es cross-equipo —cara, porque exige que dos squads se pongan de acuerdo—.

Y hacemos algo más, lo importante: por cada dependencia cross-equipo, anotamos el par de squads que tiene que hablar. La unión de todos esos pares es el grafo de comunicación que la arquitectura le exige a la organización —el dibujo de todas las conversaciones inter-squad que el código necesita para funcionar—. Ese grafo, según Conway, debería coincidir con cómo se comunica de verdad la organización. Donde el código exige una conversación que la organización no tiene, hay fricción.

# Conway medido: el espejo entre la estructura de la organizacion
# y la estructura del codigo, calculado sobre Mercado.

# Quien es dueno de cada modulo (mapa de ownership actual: 5 squads).
owner = {
    "product_catalog":     "catalog",
    "search":              "catalog",
    "cart":                "orders",
    "order_processing":    "orders",
    "checkout":            "orders",
    "payment_processing":  "payments",
    "invoicing":           "payments",
    "shipping_labels":     "shipping",
    "delivery_tracking":   "shipping",
    "auth":                "platform",
    "notifications":       "platform",
}

# Dependencias del codigo: (modulo, del-que-depende).
deps = [
    ("search",             "product_catalog"),
    ("cart",               "product_catalog"),
    ("checkout",           "cart"),
    ("checkout",           "payment_processing"),
    ("checkout",           "shipping_labels"),
    ("checkout",           "notifications"),
    ("checkout",           "order_processing"),
    ("order_processing",   "shipping_labels"),
    ("order_processing",   "auth"),
    ("payment_processing", "invoicing"),
    ("payment_processing", "auth"),
    ("invoicing",          "notifications"),
    ("shipping_labels",    "delivery_tracking"),
]

# Clasifica cada dependencia: intra-equipo (barata) o cross-equipo (cara).
intra, cross = [], []
team_edges = set()   # el grafo de comunicacion que el codigo EXIGE entre squads
for src, dst in deps:
    ts, td = owner[src], owner[dst]
    if ts == td:
        intra.append((src, dst, ts))
    else:
        cross.append((src, dst, ts, td))
        team_edges.add((ts, td))

print(f"{'dependency':<40}{'kind':<7}{'teams'}")
for src, dst, ts, td in cross:
    print(f"{src+' -> '+dst:<40}{'CROSS':<7}{ts} -> {td}")
for src, dst, t in intra:
    print(f"{src+' -> '+dst:<40}{'intra':<7}{t}")

total = len(deps)
print()
print(f"dependencias totales : {total}")
print(f"intra-equipo         : {len(intra)}  ({len(intra)/total*100:.1f}%)")
print(f"cross-equipo         : {len(cross)}  ({len(cross)/total*100:.1f}%)")
print()
print("Grafo de comunicacion que la ARQUITECTURA le exige a la ORGANIZACION:")
for ts, td in sorted(team_edges):
    print(f"  {ts}  debe hablar con  {td}")
print(f"canales inter-squad exigidos por el codigo: {len(team_edges)}")

Qué esperar. Al correrlo:

dependency                              kind   teams
cart -> product_catalog                 CROSS  orders -> catalog
checkout -> payment_processing          CROSS  orders -> payments
checkout -> shipping_labels             CROSS  orders -> shipping
checkout -> notifications               CROSS  orders -> platform
order_processing -> shipping_labels     CROSS  orders -> shipping
order_processing -> auth                CROSS  orders -> platform
payment_processing -> auth              CROSS  payments -> platform
invoicing -> notifications              CROSS  payments -> platform
search -> product_catalog               intra  catalog
checkout -> cart                        intra  orders
checkout -> order_processing            intra  orders
payment_processing -> invoicing         intra  payments
shipping_labels -> delivery_tracking    intra  shipping

dependencias totales : 13
intra-equipo         : 5  (38.5%)
cross-equipo         : 8  (61.5%)

Grafo de comunicacion que la ARQUITECTURA le exige a la ORGANIZACION:
  orders  debe hablar con  catalog
  orders  debe hablar con  payments
  orders  debe hablar con  platform
  orders  debe hablar con  shipping
  payments  debe hablar con  platform
canales inter-squad exigidos por el codigo: 5

Aquí está el espejo, medido. Léelo por partes.

El número que duele: 61.5% de las dependencias cruzan equipos. De las trece dependencias del sistema, ocho cruzan una frontera de squad y solo cinco se quedan dentro de un equipo. Eso es un sistema mal alineado con su organización: la mayoría de las conexiones del código exigen que dos squads coordinen. En un sistema sano —bien "conwayzado"—, esperarías lo contrario: la mayoría de las dependencias internas a cada equipo, y unas pocas, limpias y bien definidas, cruzando fronteras. Mercado tiene el patrón inverso, y ese 61.5% es la firma numérica de un monolito que fue partido en squads sin partir el código. (En la lección 3 vamos a ver de dónde salió exactamente ese desalineamiento.)

Dónde se concentra el cruce: en checkout y en order_processing. Mira las filas CROSS: casi todas involucran a orders. checkout cruza hacia payments, shipping y platform; order_processing cruza hacia shipping y platform. Orders es el squad que más fronteras cruza, porque los módulos del flujo de compra (checkout, procesamiento de pedido) necesitan tocar el pago, el envío y las notificaciones —que viven en otros squads—. Esto confirma la intuición del teaser de la lección 1: orders está en el centro de casi todo, y el checkout es el módulo más cruzado. En la lección 5 le vamos a poner un número exacto a esa fricción.

El artefacto central: el grafo de comunicación que el código exige. Las últimas líneas son el corazón de la lección. El sistema, por su estructura de dependencias, exige que cinco pares de squads se comuniquen: orders con catalog, con payments, con platform y con shipping; y payments con platform. Ese es el organigrama de comunicación que tu código demanda —y fíjate que salió de las dependencias del código, no de preguntarle a nadie cómo se organiza la empresa—. Aquí está la Ley de Conway convertida en herramienta: si estos cinco canales coinciden con cómo se comunica de verdad la organización, el sistema fluye. Si el código exige que orders hable con shipping pero orders y shipping están en edificios distintos y coordinan por tickets, ahí —en ese canal exigido pero no sostenido— es donde el sistema se va a atorar. El grafo te dice exactamente qué conversaciones necesita tu arquitectura para no romperse.

Un matiz honesto sobre la medición, porque toda métrica esconde supuestos. Contar "dependencias cross-equipo" trata a todas las dependencias como iguales, y no lo son: una dependencia cross-equipo hacia un servicio de plataforma estable y bien versionado (como auth) cuesta mucho menos coordinación que una dependencia cross-equipo donde los dos lados cambian a la vez (como checkout y payment_processing evolucionando juntos). El 61.5% es una primera aproximación —un termómetro grueso—; en la lección 5 vamos a refinar la medición para pesar la fricción por cuántos equipos deben coordinar simultáneamente, que captura mejor el dolor real. Por ahora, el 61.5% cumple su trabajo: gritar que este sistema no está alineado con su organización, y señalar dónde.

Profundización: por qué el espejo es inevitable (y qué es un homomorfismo sin la jerga)

Los académicos describen la Ley de Conway con una palabra elegante: el sistema es un homomorfismo de la organización. Suena intimidante, pero la idea es simple y vale la pena entenderla, porque explica por qué el espejo no se puede esquivar con buenas intenciones.

Un homomorfismo, en cristiano, es una correspondencia que preserva la estructura. Piensa en un mapa de metro: no es geográficamente exacto (las distancias mienten, las curvas se enderezan), pero preserva lo que importa —qué estación conecta con qué estación, en qué orden—. Si en la realidad la estación A conecta con la B y la B con la C, en el mapa también, aunque las posiciones estén distorsionadas. El mapa es un homomorfismo de la red real: distinto en los detalles, idéntico en la estructura de conexiones.

Conway dice que tu sistema es un homomorfismo de tu organización en ese mismo sentido: no es que cada persona sea un módulo (eso sería una copia exacta, que no es lo que pasa), sino que la estructura de conexiones se preserva. Si en la organización el equipo A se comunica con el B, en el sistema el módulo de A se conecta con el de B. Si A no se comunica con C, es muy improbable que el módulo de A dependa del de C —porque construir esa dependencia habría requerido una comunicación que no existe—. El mapa de conexiones de la organización se calca en el mapa de conexiones del sistema. Por eso, cuando en el ejemplo derivamos "el grafo de comunicación que el código exige", estamos leyendo el homomorfismo al revés: partiendo de la estructura del código, recuperamos la estructura de comunicación que tuvo que existir para producirlo.

¿Por qué es inevitable? Por la mecánica del mueble: una conexión en el código exige un acuerdo entre personas, y un acuerdo exige un canal de comunicación. No puedes construir una dependencia entre dos módulos sin que las personas responsables se coordinen —aunque sea mínimamente— sobre la interfaz. Así que cada arista del sistema requiere una arista de comunicación en la organización. Y a la inversa, las aristas de comunicación baratas (dentro de un equipo) se convierten en dependencias sin fricción, mientras que las aristas caras o inexistentes (entre equipos que no se hablan) se convierten en fronteras del sistema. La estructura de comunicación es el molde; el sistema es lo que se vacía en él. No hay forma de que el software salga con una forma que la comunicación no permita —igual que no puedes vaciar concreto en una forma y que salga con la forma de otra—.

La consecuencia práctica, que es la tesis del módulo: si quieres cambiar la forma del sistema de manera duradera, cambia el molde —la estructura de comunicación—, no el concreto ya vaciado —el código—. Rediseñar el código sin cambiar la comunicación es como reesculpir el concreto a mano cada vez que se seca: funciona un rato y vuelve a la forma del molde. Esa es, exactamente, la razón de ser de la maniobra inversa de Conway (lección 6).

Errores comunes

Citar Conway sin medirla (de superficialidad). Qué pasa: alguien dice "por Conway, este sistema refleja la organización" y ahí se detiene, como si nombrar la ley resolviera algo. Nunca calcula cuánto la refleja ni dónde. Por qué pasa: la frase es pegajosa y da la sensación de entendimiento sin el trabajo de medir. Cómo detectarlo: si mencionas Conway en una reunión pero no puedes decir qué porcentaje de tus dependencias cruzan equipos ni cuáles, estás citando, no midiendo. Cómo corregirlo: construye los dos mapas (ownership y dependencias) y clasifica cada dependencia, como en el ejemplo; el 61.5% es un diagnóstico, "shipeas tu organigrama" es solo un eslogan.

Confundir el organigrama formal con la estructura de comunicación real (de literalidad). Qué pasa: alguien toma el diagrama oficial de la empresa —quién le reporta a quién— y asume que esa es la estructura que Conway predice que se copiará. Pero Conway habla de la comunicación real, no de las líneas de reporte. Dos equipos que en el organigrama están en departamentos distintos pero que se sientan juntos y almuerzan juntos se comunican mucho, y su software se va a acoplar; dos equipos bajo el mismo jefe pero en husos horarios opuestos apenas se comunican, y su software se va a separar. Por qué pasa: el organigrama formal es visible y la comunicación real es invisible. Cómo detectarlo: si tu análisis de Conway usa el diagrama de RR.HH. y no cómo fluye de verdad la información, estás midiendo el molde equivocado. Cómo corregirlo: mapea la comunicación real —quién habla con quién, con qué frecuencia, con qué fluidez—; esa es la estructura que se copia, no el PDF del organigrama.

Creer que un buen diseño puede vencer a Conway (de voluntarismo). Qué pasa: el arquitecto insiste en que "con suficiente disciplina" los equipos van a mantener las fronteras que el diagrama pide, aunque la organización empuje en contra. Diseña microservicios independientes para equipos que comparten todo, y confía en que la fuerza de voluntad sostenga la separación. Por qué pasa: subestima que Conway es una ley, no una tendencia que la disciplina anula. Cómo detectarlo: si tu plan depende de que la gente "tenga cuidado de no acoplar cosas" contra el gradiente de su propia estructura de comunicación, estás apostando contra la gravedad. Cómo corregirlo: alinea la organización con la arquitectura que quieres (maniobra inversa) en vez de pedirle a la gente que remonte la corriente para siempre; la disciplina se gasta, la estructura no.

Ejercicios

Ejercicio 1 — Recalcula con otra frontera. Supón que Mercado fusiona los squads orders y payments en un solo squad llamado commerce (porque el checkout los obligaba a coordinar tanto que decidieron unirlos). Sin correr el código, ¿cuáles de las ocho dependencias cross-equipo del ejemplo dejarían de cruzar una frontera? ¿Cuántas dependencias cross-equipo quedarían?

Ver solución

Al fusionar orders y payments en commerce, cualquier dependencia que antes cruzaba entre orders y payments se vuelve intra-equipo. Revisando las ocho CROSS del ejemplo:

  • cart -> product_catalog (orders → catalog): sigue cruzando (catalog es otro squad). Cross.
  • checkout -> payment_processing (orders → payments): ahora los dos son commerce. Deja de cruzar → intra.
  • checkout -> shipping_labels (orders → shipping): sigue cruzando. Cross.
  • checkout -> notifications (orders → platform): sigue cruzando. Cross.
  • order_processing -> shipping_labels (orders → shipping): sigue. Cross.
  • order_processing -> auth (orders → platform): sigue. Cross.
  • payment_processing -> auth (payments → platform): sigue (payments ahora es commerce, pero platform es otro). Cross.
  • invoicing -> notifications (payments → platform): sigue. Cross.

Solo una deja de cruzar: checkout -> payment_processing. Quedarían siete dependencias cross-equipo (antes ocho).

La lección: fusionar orders y payments arregla la fricción entre esos dos (la del checkout con el pago, que era el dolor original), pero no toca las dependencias que cruzan hacia catalog, shipping y platform. Reorganizar equipos es quirúrgico —cambia exactamente los cruces que involucran a los equipos que mueves, ni más ni menos—. Por eso la maniobra inversa (lección 6) exige elegir qué fronteras quieres eliminar y organizar alrededor de eso, no fusionar equipos a lo loco.

Ejercicio 2 — El canal exigido que no existe. El ejemplo derivó que el código exige que orders hable con shipping. Imagina que en la organización real, orders y shipping están en oficinas distintas, tienen jefes distintos, y solo coordinan cuando se rompe algo. Según la Ley de Conway, ¿qué le va a pasar a las dependencias checkout -> shipping_labels y order_processing -> shipping_labels con el tiempo? ¿Qué síntoma verías en el sistema?

Ver solución

Cuando el código exige un canal de comunicación (orders → shipping) que la organización no sostiene (oficinas distintas, coordinación solo por emergencias), pasa una de dos cosas, ambas malas:

  1. La interfaz se pudre. Como orders y shipping casi no se hablan, la interfaz entre sus módulos (el contrato de shipping_labels) se vuelve un punto de malentendidos: orders asume un comportamiento, shipping cambia otro sin avisar, y las cosas se rompen en producción justo en esa juntura. Es el centro del puente entre dos cuadrillas que no se coordinan. Síntoma: bugs recurrentes de integración en el flujo de envío, siempre "culpa del otro equipo".

  2. El sistema evoluciona para evitar el canal. Como coordinar con shipping es tan caro, orders empieza a construir atajos —copia lógica de envío dentro de su propio módulo para no tener que pedirle nada a shipping, o duplica datos—. El sistema se deforma para eludir una comunicación que no puede sostener, y aparece lógica de envío regada en orders. Síntoma: duplicación, lógica de envío que "misteriosamente" vive en el equipo equivocado.

En ambos casos, la moraleja de Conway: un canal exigido por el código pero no sostenido por la organización es una fuente garantizada de fricción. La cura no es "que se esfuercen más en coordinar" (eso se gasta); es alinear —o meter orders y shipping en una estructura donde comunicarse sea barato, o volver shipping_labels un servicio con un contrato tan estable que orders no necesite coordinar para usarlo—. Esta es la tensión que las team topologies (lección 7) resuelven con el modo x-as-a-service.

Ejercicio 3 — Lee el homomorfismo al revés. Te dan solo el "grafo de comunicación que el código exige" de un sistema desconocido: frontend ↔ backend, backend ↔ payments, backend ↔ notifications. Sin ver el código, ¿qué puedes inferir sobre cómo está organizada la empresa? ¿Y qué módulo es el más central y por qué probablemente sea un cuello de botella?

Ver solución

Leyendo el homomorfismo al revés (del sistema a la organización), puedes inferir bastante:

La organización tiene (al menos) cuatro grupos que se comunican así: un grupo de frontend, un grupo de backend, un grupo de payments y un grupo de notifications. El backend habla con los otros tres; el frontend, payments y notifications no se hablan entre sí (no hay aristas frontend↔payments ni payments↔notifications). Probablemente frontend, payments y notifications son equipos "hoja" que solo coordinan a través del backend —o payments y notifications son servicios que el backend consume—.

El módulo (y el equipo) más central es el backend, porque es el único que aparece en las tres aristas: toda la comunicación pasa por él. Eso lo vuelve el candidato número uno a cuello de botella, por dos razones que se refuerzan: (1) técnicamente, es el módulo del que todo depende, así que cualquier cambio suyo afecta a muchos y cualquier caída suya tumba todo; (2) organizacionalmente, el equipo de backend tiene que coordinar con los otros tres, así que su carga de comunicación es la más alta y todo el trabajo de los demás se atora esperándolo. Es exactamente la posición de orders en Mercado —el módulo central que cruza hacia todos los demás—. La Ley de Conway te dejó diagnosticar el cuello de botella (técnico y organizacional) sin ver una sola línea de código, solo leyendo el grafo de comunicación exigido.

Resumen y siguiente paso

En esta lección convertiste la Ley de Conway de frase en herramienta. Conociste el enunciado original de Melvin Conway (1968) y —más importante— por qué opera: para que dos módulos encajen, las personas que los escriben tienen que comunicarse, así que la estructura de las piezas queda calcada de la estructura de quién-habla-con-quién (el mueble de dos personas, el homomorfismo que preserva la estructura de conexiones). Y mediste el espejo sobre Mercado: clasificaste las trece dependencias del sistema en intra-equipo (5) y cross-equipo (8), obtuviste el diagnóstico —61.5% de las dependencias cruzan fronteras, la firma de un sistema mal alineado—, y derivaste el artefacto central: el grafo de comunicación que la arquitectura le exige a la organización (cinco canales inter-squad, con orders en el centro de casi todos).

Antes de avanzar deberías poder: enunciar la Ley de Conway con precisión y explicar por qué es inevitable (una conexión en el código exige un acuerdo entre personas); medir el espejo en un sistema —clasificar dependencias en intra y cross-equipo y calcular la alineación—; derivar el grafo de comunicación que un código exige; y distinguir la comunicación real (la que se copia) del organigrama formal (que a veces miente).

Lo que sigue es explicar de dónde salió ese 61.5% de desalineamiento —por qué un sistema termina así—. En la lección 3 vas a ver por qué el monolito de Mercado refleja que al principio había un solo equipo: vas a medir la misma base de código bajo dos organizaciones distintas —la de 2019 (un equipo) y la de 2024 (cinco squads)— y ver las dependencias cross-equipo saltar de 0 a 8 sin que el código cambie una sola línea. Es la historia de casi todo monolito doloroso: nació perfectamente alineado con un equipo único, y quedó desalineado cuando la organización creció y el código no la siguió.

Recursos

  • Melvin Conway — "How Do Committees Invent?" (1968) — el paper fundacional, con la formulación exacta de la ley. Vale leerlo entero (son pocas páginas): Conway ya observaba en 1968 el ejemplo del compilador de dos pasadas escrito por dos grupos, y anticipaba casi todo lo que este módulo mide.
  • Martin Fowler — "Conway's Law" — la mejor explicación breve de por qué la ley opera y qué implica; introduce la distinción entre el organigrama formal y la comunicación real, y la idea de que el diseño hereda la forma de la comunicación.
  • Skelton & Pais — Team Topologies, capítulo sobre Conway's Law — el resumen gratuito de conceptos clave, que trata el "espejo" org↔arquitectura como el punto de partida para diseñar organizaciones a propósito; el puente directo hacia las lecciones 6 y 7 de este módulo.
← Anterior1. Presentación del módulo: shipeas tu organigramaSiguiente →3. El monolito es tu primer organigrama