⏱️ Lectura: 13 min
Un blog de historia militar publicó esta semana un texto que, sin nombrarla, describe una de las leyes más citadas de la ingeniería de software: la Ley de Conway. Bret Devereaux abrió en acoup.blog una serie sobre cómo diseñar ejércitos premodernos creíbles para mundos de ficción, y su tesis central —ningún ejército puede evitar recrear en el campo de batalla la estructura social de la que proviene— es casi palabra por palabra lo que Melvin Conway escribió sobre los sistemas informáticos en 1968.
📑 En este artículo
- TL;DR
- Qué publicó acoup y por qué le importa a quien programa
- La Ley de Conway: el mismo principio en el software
- Reclutar, pagar, liderar: las preguntas de acoup en clave tech
- Datos y antecedentes: de 1968 a Team Topologies
- Impacto y análisis para equipos en LATAM
- Qué sigue
- Preguntas frecuentes
- Referencias
Si construís software en equipo, esa idea explica por qué tu arquitectura termina pareciéndose a tu organigrama aunque nadie lo haya decidido a propósito. Vale la pena entender por qué ocurre y cómo aprovecharlo.
TL;DR
- Bret Devereaux (acoup.blog) publicó el 5 de junio de 2026 la Parte I de una serie sobre ejércitos premodernos para worldbuilders.
- Su tesis: ningún ejército puede evitar recrear en batalla la estructura social de la sociedad de la que proviene.
- Es la misma idea que Melvin Conway formuló en 1968 para el software: el sistema copia la estructura de comunicación de la organización.
- La Ley de Conway explica por qué un equipo dividido en silos produce una arquitectura con esos mismos silos.
- La ‘maniobra inversa de Conway’ propone diseñar primero los equipos para obtener la arquitectura deseada.
- El libro Team Topologies (2019) convirtió esa idea en un método práctico de diseño organizacional.
- Para equipos en LATAM la lección es concreta: definí los límites de los equipos antes que los límites de los servicios.
Qué publicó acoup y por qué le importa a quien programa
El 5 de junio de 2026, Bret Devereaux —historiador especializado en el ejército romano y autor del blog A Collection of Unmitigated Pedantry (acoup.blog)— publicó la primera entrega de una serie sobre cómo construir ejércitos premodernos para worldbuilding. El objetivo declarado es ayudar a quienes escriben ficción a evitar errores comunes: ejércitos profesionales en sociedades que no tienen la estructura administrativa para sostenerlos, guardias que aparecen de la nada sin encajar en ninguna parte de la sociedad, fuerzas demasiado grandes o demasiado pequeñas para el mundo que las rodea.
Para llegar ahí, Devereaux propone una pregunta de diseño que cualquier arquitecto de software reconocería: antes de decidir cómo se ve el ejército, hay que entender la sociedad que lo produce. ¿Es agraria? ¿Quién se siente obligado a servir y por qué? ¿Cómo se paga? ¿Quién lidera y con qué autoridad? La respuesta a esas preguntas determina las armas, las tácticas y la estructura de mando. Y la frase que ancla todo el texto es la que nos interesa: ningún ejército puede evitar recrear sus estructuras sociales civiles en el campo de batalla.
Cambiá ‘ejército’ por ‘sistema’ y ‘campo de batalla’ por ‘producción’, y tenés un enunciado que aparece en casi todos los libros de arquitectura de software de los últimos veinte años.
La Ley de Conway: el mismo principio en el software
En 1968, el programador Melvin Conway publicó un artículo titulado How Do Committees Invent? con una observación que la industria tardó décadas en tomar en serio: cualquier organización que diseña un sistema producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización. Esa frase es la Ley de Conway.
La consecuencia es incómoda. Si tu empresa tiene un equipo de frontend, uno de backend y uno de base de datos que apenas se hablan, vas a obtener un sistema con tres capas rígidas y fronteras gruesas entre ellas, porque cada interfaz entre módulos es, en el fondo, una negociación entre personas. Donde la comunicación humana es difícil, el software pone un contrato formal, una cola, una API. Donde dos personas se sientan juntas, el código tiende a fundirse en un solo módulo. La Ley de Conway no es una metáfora: es una observación estructural sobre cómo el trabajo humano deja huella en el artefacto.
Esto es exactamente lo que describe Devereaux para los ejércitos. Un ejército feudal donde los soldados deben lealtad a su señor local, no al rey, produce un mando fragmentado en el campo: cada contingente sigue a su noble. Un ejército ciudadano de hoplitas, donde los que combaten son los mismos que votan en la asamblea, produce una formación igualitaria donde todos pelean hombro con hombro. La estructura social no se queda en casa; marcha con el ejército. El software hace lo mismo: la estructura del equipo no se queda en el organigrama, se compila dentro del binario.
graph LR
A["Equipo de Pagos"] --> SA["Servicio de Pagos"]
B["Equipo de Cuentas"] --> SB["Servicio de Cuentas"]
C["Equipo de Mensajes"] --> SC["Servicio de Mensajes"]
SA -. "API REST" .-> SB
SB -. "cola de eventos" .-> SCEl diagrama ilustra la versión más visible de la Ley de Conway: tres equipos independientes terminan produciendo tres servicios independientes, y las fronteras de comunicación entre equipos se vuelven fronteras técnicas (una API REST aquí, una cola de eventos allá). Nadie diseñó esos límites en una pizarra de arquitectura; emergieron del organigrama.
💭 Clave: La arquitectura que ves en producción no es la que dibujaste en el diagrama: es la que tu estructura de equipos te permitió construir.
Reclutar, pagar, liderar: las preguntas de acoup en clave tech
Devereaux estructura su serie alrededor de cuatro preguntas sobre cómo una sociedad genera un ejército: por qué la gente sirve, cómo se la incorpora, cómo se paga el costo y quién lidera. Cada una tiene un eco directo en cómo una empresa genera software.
- Por qué sirven — En un ejército, la motivación (obligación feudal, ciudadanía, paga mercenaria) define la cohesión. En un equipo, la motivación (propósito del producto, propiedad del código, incentivos) define si la gente cuida el sistema o solo cumple tickets. Equipos sin sentido de pertenencia producen código que nadie quiere mantener.
- Cómo se incorpora — El reclutamiento militar tiene fricción: hay que encontrar, equipar y entrenar gente. El onboarding técnico es lo mismo. Un sistema que tarda semanas en explicarse a un nuevo desarrollador está revelando que su estructura no es legible, y eso casi siempre refleja una organización confusa.
- Cómo se paga — Devereaux insiste en que mantener ejércitos es caro y muchas sociedades simplemente no pueden permitírselo. En tech, el equivalente es la deuda técnica y el costo operativo: una arquitectura de microservicios exige una madurez de plataforma (CI/CD, observabilidad, on-call) que muchas organizaciones no tienen. Adoptarla sin pagar ese costo produce el equivalente al ejército profesional en una aldea: insostenible.
- Quién lidera — La cadena de mando define cómo se toman decisiones bajo presión. En software, quién tiene autoridad para decidir un contrato de API o un esquema de datos determina la velocidad y la calidad de las fronteras del sistema.
Datos y antecedentes: de 1968 a Team Topologies
La Ley de Conway pasó de curiosidad a herramienta de diseño en etapas. En 1968 era una nota de un solo artículo en la revista Datamation. En 2010, en una adenda a su propio paper, Conway resumió la idea como un homomorfismo entre la organización y el sistema: una correspondencia estructural, no una simple analogía. La popularización fuerte llegó con el auge de los microservicios alrededor de 2014, cuando equipos que querían servicios pequeños e independientes descubrieron que no podían lograrlos con una organización monolítica de mil personas que se comunicaban a través de tickets.
De ahí surgió la maniobra inversa de Conway (Inverse Conway Maneuver): si el sistema copia la estructura del equipo, entonces para obtener la arquitectura que querés, primero rediseñá los equipos. En 2019, el libro Team Topologies de Matthew Skelton y Manuel Pais convirtió esa intuición en un método explícito, con cuatro tipos de equipo (alineado al flujo, plataforma, habilitador y subsistema complicado) y tres modos de interacción. La idea de fondo sigue siendo la misma que la de Conway en 1968 y la de Devereaux en 2026: la estructura social viene primero.
Un ejemplo concreto de la maniobra inversa, traducido a estructura de proyecto: si querés que tres dominios de negocio sean realmente independientes y desplegables por separado, no empieces por el repositorio, empezá por dejar que cada equipo sea dueño de su frontera de extremo a extremo.
# Arquitectura deseada: 3 dominios desacoplados
# La maniobra inversa: cada equipo posee su dominio completo
pagos/ # Equipo A: dueño del esquema, la API y el deploy
api/
db/
deploy.yml
cuentas/ # Equipo B: idem, sin tocar el esquema de pagos
api/
db/
deploy.yml
mensajes/ # Equipo C: consume eventos, no llama a las DB ajenas
api/
consumers/
deploy.yml
# Regla Conway: ningun equipo escribe en la base de datos de otro.
# Si la org respeta esa frontera humana, el codigo respeta la tecnica.Lo importante no es la estructura de carpetas en sí, sino la regla social que la sostiene: ningún equipo cruza la frontera de otro. Cuando esa regla humana se mantiene, la frontera técnica se mantiene sola. Cuando se rompe —porque dos equipos comparten la misma base de datos ‘por urgencia’— la arquitectura se degrada exactamente por donde se rompió la comunicación. Es la Ley de Conway operando en tiempo real.
⚠️ Ojo: Adoptar microservicios sin reorganizar los equipos suele producir un ‘monolito distribuido’: todas las desventajas de la red, ninguna de las ventajas de la independencia.
Impacto y análisis para equipos en LATAM
Para equipos de desarrollo en América Latina, donde muchas empresas crecen rápido desde una startup pequeña hacia varias docenas de personas, la Ley de Conway tiene una aplicación práctica inmediata: la decisión más importante de arquitectura que vas a tomar este año probablemente no sea técnica, sino organizacional.
Cuando una startup de cinco personas comparte todo el contexto en una sola conversación, el monolito es la arquitectura correcta: refleja fielmente una organización donde todos hablan con todos. El problema aparece cuando la empresa pasa a cuarenta personas pero mantiene el monolito y a la vez crea equipos separados. Ahí la Ley de Conway empieza a pelear contra vos: tres equipos que ya no se comunican bien siguen forzados a editar el mismo código, y el resultado es conflictos de merge constantes, despliegues que se bloquean entre sí y nadie que se sienta dueño de nada.
La recomendación que se desprende, tanto de acoup como de Conway, es la misma: no copies la arquitectura de una empresa mucho más grande. Una sociedad agraria pequeña no puede sostener un ejército profesional permanente, y un equipo de cuarenta personas no puede sostener la arquitectura de servicios de una empresa de mil. Diseñá el sistema que tu organización actual puede mantener, y rediseñá la organización antes —no después— de querer una arquitectura distinta.
💡 Tip: Antes de tu próximo gran refactor, dibujá el organigrama real (quién habla con quién, no el formal). Tu arquitectura futura se va a parecer a ese dibujo más que a cualquier diagrama de cajas y flechas.
Qué sigue
Devereaux anunció que la serie continuará con entregas dedicadas a cada componente: reclutamiento, financiamiento, liderazgo y cohesión en el campo, para cerrar con ‘arquetipos’ históricos que muestran cómo se combinan esos factores. Para quien diseña software, vale la pena leerla con la lente de Conway puesta: cada vez que el historiador explica por qué un ejército feudal pelea distinto a uno ciudadano, está describiendo, sin saberlo, por qué un equipo con silos produce un sistema distinto a uno con equipos autónomos.
La lección transversal es vieja y resistente: las estructuras que construimos siempre llevan la marca de cómo nos organizamos para construirlas. La Ley de Conway no se puede derogar; solo se puede usar a favor o sufrir en contra.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué dice exactamente la Ley de Conway?
Que cualquier organización que diseña un sistema producirá un diseño cuya estructura copia la estructura de comunicación de esa organización. La formuló Melvin Conway en 1968. En términos prácticos: tu arquitectura de software termina pareciéndose a tu organigrama real.
¿Qué tiene que ver un artículo sobre ejércitos premodernos con programar?
La tesis central del artículo de Bret Devereaux —que un ejército recrea en batalla la estructura social de su sociedad— es el mismo principio que la Ley de Conway aplica al software. Dos campos sin relación llegaron de forma independiente a la misma observación sobre cómo la estructura social moldea lo que se produce.
¿Qué es la maniobra inversa de Conway?
Es la estrategia de diseñar primero la estructura de los equipos para obtener la arquitectura deseada. Si el sistema copia a la organización, entonces cambiar la organización es la forma más directa de cambiar el sistema. El libro Team Topologies (2019) la convirtió en un método práctico.
¿Significa esto que los microservicios son siempre mejores?
No. Los microservicios solo funcionan si la organización tiene equipos autónomos y la madurez de plataforma para sostenerlos. Adoptarlos sin reorganizar produce un ‘monolito distribuido’ con todas las desventajas y ninguna ventaja. Para un equipo pequeño, un monolito suele ser la arquitectura correcta.
¿Cómo aplico la Ley de Conway en un equipo chico de LATAM?
Empezá por mapear quién se comunica con quién en la práctica. Mantené una arquitectura proporcional a tu organización actual y, antes de buscar una arquitectura más desacoplada, ajustá primero los límites y la propiedad de los equipos. La regla básica: ningún equipo debería escribir en el dominio de otro.
Referencias
- acoup.blog — Artículo fuente de Bret Devereaux sobre ejércitos premodernos para worldbuilders (Parte I).
- melconway.com — Paper original de Melvin Conway, How Do Committees Invent? (1968), con adenda del autor.
- Wikipedia — Resumen de la Ley de Conway, su historia y la maniobra inversa.
- martinfowler.com — Análisis de Martin Fowler sobre la Ley de Conway aplicada a arquitectura de software.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios