LA LEY DE CONWAY: TU ARQUITECTURA REFLEJA TU ORGANIZACIÓN

La ley, sin adornos

"Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure."  Melvin Conway, 1967

Tradúcelo al contexto de software moderno: si tienes tres equipos separados, frontend, backend y base de datos, casi inevitablemente producirás un sistema con tres capas bien marcadas y con interfaces rígidas entre ellas. No porque esa sea la mejor arquitectura posible, sino porque es la que refleja cómo fluye la comunicación dentro de tu organización.

Si tienes un equipo monolítico donde todos hablan con todos sobre todo, el sistema tenderá a ser un monolito donde todo depende de todo. Si tienes equipos autónomos organizados por capacidades de negocio, el sistema tenderá a tener servicios autónomos organizados por capacidades de negocio.

La estructura del código refleja la estructura social del equipo que lo escribió. Siempre.

La ley en acción

El diagrama no es una coincidencia ni un resultado deliberado. Es la ley operando. Los equipos tienden a diseñar interfaces en los límites donde terminan sus responsabilidades, porque comunicarse a través de esos límites tiene fricción. La arquitectura del sistema replica exactamente los puntos de fricción y los canales de comunicación del equipo.

El ejemplo clásico: el compilador de ocho pasos

Conway usó como ejemplo original el desarrollo de un compilador. Cuando el proyecto lo trabajaban ocho personas en dos grupos separados, el compilador resultó tener dos pasadas. Cuando lo hicieron cinco personas en un único grupo, tuvo una sola pasada. La arquitectura del sistema no fue una decisión técnica deliberada: fue el resultado directo de cómo estaba organizado el equipo.

Este mismo patrón se repite constantemente en la industria. Microsoft Windows históricamente ha tenido una arquitectura fragmentada porque refleja la fragmentación de sus equipos internos. El navegador Chrome tiene una arquitectura de procesos aislados porque fue construido por equipos que operaban con alto grado de autonomía.

Por qué importa más que nunca

Durante décadas la Ley de Conway fue tratada como una curiosidad intelectual. Fue la explosión de los microservicios lo que la devolvió al centro del debate. De repente, las empresas descubrieron algo incómodo: no puedes simplemente decidir tener microservicios. Si tu organización sigue siendo un monolito jerárquico, producirás microservicios distribuidos que se comportan como un monolito — lo que algunos llaman el peor de los mundos: la complejidad de los microservicios sin sus beneficios.

• El caso de Amazon: El éxito de Amazon Web Services no es solo una historia de tecnología. Es una historia de estructura organizacional. La famosa regla de los 'two-pizza teams' de Jeff Bezos, si no puedes alimentar al equipo con dos pizzas, es demasiado grande, no fue una decisión cultural arbitraria. Fue una decisión arquitectónica. Equipos pequeños y autónomos producen servicios pequeños y autónomos. AWS es Conway's Law aplicada de forma intencional a escala global.
• El caso contrario: Muchas transformaciones hacia microservicios fracasan exactamente por la misma razón. Una empresa reorganiza su código en cincuenta servicios pero mantiene la misma estructura organizacional centralizada, con equipos de plataforma que controlan la infraestructura, equipos de arquitectura que aprueban cada decisión técnica, y equipos de negocio que no tienen autonomía sobre su stack. El resultado es cincuenta servicios que requieren coordinación constante entre equipos para cualquier cambio. La complejidad operacional se multiplicó, pero los beneficios de autonomía nunca llegaron. Conway lo predijo.

La Inverse Conway Maneuver

Si Conway's Law es descriptiva, entonces existe una forma de usarla de manera prescriptiva. Matthew Skelton y Manuel Pais, en su libro Team Topologies, lo llaman la Inverse Conway Maneuver: en lugar de dejar que la estructura del equipo determine la arquitectura, diseña primero la arquitectura que quieres y luego organiza el equipo para que la refleje.

No preguntes '¿cómo organizamos el equipo para construir este sistema?'. Pregunta '¿qué arquitectura queremos y qué equipo necesitamos para que surja naturalmente?'

En la práctica esto significa que antes de decidir que quieres microservicios organizados por dominio de negocio, necesitas equipos organizados por dominio de negocio. Antes de decidir que quieres una plataforma de datos autónoma, necesitas un equipo que sea dueño completo de esa plataforma, incluyendo su operación.

Los cuatro tipos de equipo según Team Topologies

• Stream-aligned teams: organizados alrededor de un flujo de valor de negocio. Tienen autonomía completa para entregarlo.

• Platform teams: proporcionan capacidades internas que los stream-aligned teams consumen como servicio.

• Enabling teams: ayudan a los stream-aligned teams a adquirir capacidades que aún no tienen.

• Complicated-subsystem teams: responsables de partes del sistema que requieren conocimiento especializado muy específico.

La clave es que esta taxonomía no es solo sobre personas — es sobre cómo fluye la comunicación y las dependencias entre ellos. Conway's Law predice que esas líneas de comunicación se convertirán en las interfaces de tu sistema.

Lo que esto significa para ti hoy

Si eres desarrollador, la próxima vez que te preguntes por qué el sistema está estructurado de una forma que parece arbitraria o subóptima, busca la respuesta en el organigrama. Casi siempre la encontrarás ahí.

Si eres arquitecto técnico, antes de proponer una nueva estructura de servicios o componentes, pregúntate si la organización tiene la estructura de comunicación que esa arquitectura requiere. Una arquitectura de microservicios autónomos en una organización centralmente coordinada no va a funcionar — no porque la tecnología falle, sino porque la ley opera.

Si eres líder de ingeniería, entiende que cada decisión que tomas sobre cómo organizar los equipos, quién habla con quién, qué fronteras de responsabilidad defines — todas esas decisiones son decisiones arquitectónicas. Estás diseñando el sistema tanto como cualquier diagrama de componentes.

La pregunta que vale hacerse

Dibuja el organigrama de tu equipo. Dibuja la arquitectura de tu sistema. ¿Se parecen? Casi con certeza sí. La pregunta es si ese parecido fue una decisión deliberada o simplemente lo que ocurrió.

CONCLUSIÓN

Conway's Law no es un problema a resolver. Es una realidad a diseñar. Los equipos que la ignoran la sufren: producen arquitecturas accidentales que reflejan fricción organizacional, silos y falta de comunicación. Los equipos que la entienden la usan como herramienta: diseñan primero la arquitectura que quieren y construyen la organización que la hace posible.

En un mundo obsesionado con frameworks, patrones y herramientas, la Ley de Conway nos recuerda algo incómodo: el mayor determinante de la calidad de tu software no está en tu repositorio. Está en cómo hablan las personas que lo construyen.