La fragmentación en software empresarial no es una casualidad: es el resultado inevitable de cómo están estructuradas las organizaciones. Mientras que equipos FOSS pequeños producen sistemas elegantes (SQLite es el ejemplo clásico), empresas con presupuestos enormes generan software desconectado donde podés “ver los seams” entre departamentos. Todo se explica por la Ley de Conway, un principio de 1967: las organizaciones diseñan sistemas que reflejan su propia estructura de comunicación.
En 30 segundos
- La Ley de Conway (1967) explica por qué empresas con 5 divisiones producen 5 módulos desconectados.
- SQLite es coherente porque una visión clara prevaleció; Windows es fragmentado porque Microsoft tiene múltiples equipos con agendas propias.
- Equipos pequeños con arquitecto jefe (como Linus en Linux) logran integridad conceptual; equipos grandes sin visión central terminan en silos.
- Brooks’s Law: agregar desarrolladores a un proyecto atrasado lo ralentiza aún más. La comunicación escala exponencialmente.
- Recuperar coherencia requiere límites arquitectónicos claros y decisiones centralizadas, no necesariamente un monolito.
Antes que nada, la Ley de Conway es un principio fundamental de la arquitectura de software que establece que cualquier sistema de software diseñado por una organización reflejará inevitablemente la estructura de comunicación de esa organización. Dicho de otra forma: tu organigrama es tu código.
El contraste: software coherente vs fragmentado
Ponele que abrís una aplicación empresarial grande. Empezás a navegar y al rato caés en cuenta: acá se nota dónde termina el trabajo de un equipo y empieza el del otro. Los patrones de navegación cambian. La nomenclatura es diferente. La experiencia de usuario saltos en tres ocasiones de “elegante” a “parece que lo armó otro quilombo completamente”. (Spoiler: es literal, porque lo armó otro equipo con su propio jefe, presupuesto y roadmap.)
Ahora contrastar con descargar una herramienta FOSS medianamente buena. Git. SQLite. Curl. Todo encaja. La API es consistente. Los mensajes de error tienen lógica. Navigás y adivinas cómo va a funcionar la siguiente pantalla porque hay un punto de vista detrás.
¿Cómo es que una empresa con presupuesto ilimitado, procesos rígidos y arquitectos dedicados produce sistemas peores que lo que hace un grupo de nerds en GitHub? Conway lo explicó en 1967, y nadie le prestó atención.
La Ley de Conway: Tu organigrama es tu arquitectura
Melvin Conway, un programador de los ’60s, observó algo incómodo: los sistemas que diseñaban las organizaciones reflejaban exactamente su estructura organizacional. Si tu empresa tenía un departamento de frontend, uno de backend y uno de DevOps, tu software tendría una frontera nítida entre frontend, backend y DevOps. Si tenías cinco divisiones geográficas, tu código sería cinco módulos desconectados.
El problema no es que esto sea un “problema” per se. El problema es que nadie piensa en ello. Armas equipos basándote en reportes, presupuestos, especialidades. Tu organizador de recursos humanos estructura la empresa sin consultar a un arquitecto. Y boom: seis meses después tenés un código que es imposible de cambiar sin coordinación entre siete equipos.
Empresa con 500 ingenieros, 50 equipos, 10 sub-divisiones: 50+ límites de equipo en el código. Cada equipo optimiza para sus métricas, su roadmap, su deadline. Nadie optimiza para el usuario final. Más contexto en capacidades del nuevo Claude.
Fragmentación empresarial: Mosaicos desconectados
Mirá un empresa típica: el equipo de CRM usa Salesforce. Finanzas usa NetSuite. Marketing tiene HubSpot. Proyecto usan Jira. Documentación está en Confluence. Datos dispersos entre sistemas, integraciones frágiles, nadie tiene la verdad única. Un cliente llama porque su factura no coincide con el CRM, y vos necesitás un query SQL custom más un script Python más una llamada a tres APIs diferentes, ninguna diseñada para hablar con las otras.
Todo esto pasaría de largo si alguien hubiera diseñado la arquitectura una sola vez, con una visión clara. “Acá va la verdad de clientes, acá interfaces públicas, acá qué puede cada equipo tocar.” Pero en lugar de eso, cada equipo eligió sus herramientas sin consultar con los demás.
Es casi como si tuvieran que producir software coherente a través de múltiples equipos sin ruptura. ¿Pero alguien preguntó cómo hacerlo? No. Compraron herramientas, contrataron gente, y seis años después tuvieron un monumento a la fragmentación.
Integridad conceptual: Cuando uno o pocos tienen la visión
SQLite existe desde 1999. Una sola persona, D. Richard Hipp, la creó. Hoy en día, un pequeño equipo la mantiene. Está embebida en billones de dispositivos: Android, iOS, laptops, navegadores, cada app que tenés. ¿Por qué es perfecta?
Porque había una visión: “una librería SQL liviana, sin dependencias externas, que funcione igual en todos lados.” Ese norte constante, ese “no” a features complicadas, ese “sí” a portabilidad por encima de capacidad bruta, produjo un software que es arte. Cero sorpresas, cero límites invisibles entre partes, cero “wait, ¿eso cómo funciona?”
Contrast con Windows. Microsoft tiene equipos de Outlook, equipos de Windows Explorer, equipos de Internet Explorer, equipos de Windows Update. Todos reportando a gente diferente. El resultado: abrís las carpetas de la mano derecha pero actualizás desde la izquierda, tu correo usa una API diferente a tu navegador, cambios de seguridad rompen aplicaciones legacy porque nadie coordinó. Sobre eso hablamos en arquitectura de los LLMs modernos.
No es que Microsoft no tenga ingeniero talentosos. Es que 50,000 ingenieros en 300 equipos con diferentes jefes produciría fragmentación incluso si todos fueran gente de primer nivel (porque, honestamente, la mayoría de Microsoft sí lo es).
Brooks’s Law: Por qué más gente ralentiza todo
The Mythical Man-Month, escrito por Fred Brooks en 1975, plantea algo que las startups ignoran: agregar desarrolladores a un proyecto atrasado lo ralentiza aún más. La comunicación entre N personas escala en O(N²). Con 10 personas son 45 canales de comunicación. Con 100 son 4,950. Cada cambio de arquitectura requiere consenso. Cada decisión, reunión con siete equipos.
Un equipo de 5 con visión clara: toma decisiones en dos horas. Un equipo de 5 reporta a un arquitecto. Ese arquitecto veta lo que no cierra. Resultado: coherencia.
Un equipo de 50 con 5 sub-jefes: cada uno veta diferente, todos aman su dominio, la política organizacional entra, las decisiones toman tres semanas, y cuando se resuelve, dos sub-jefes ya decidieron hacer otra cosa porque para ellos ya fue.
Ejemplos en producción: FOSS vs Enterprise
Git: Linus Torvalds lo creó porque necesitaba controlar versiones del kernel de Linux. Una visión: “sistema distribuido, rápido, simple.” Años después, no cambió. Todo que necesitás está en 15 comandos que funcionan igual en 2005 que en 2026. Otros version control systems con presupuesto, marketing, empresas detrás: evolucionaron features, complejidad, y hoy git sigue siendo el standard.
Linux kernel: Descentralizado, pero con regla clara: Linus es el árbitro final. Revisión de código obsesiva. Si tu patch no cierra, se rechaza. Resultado: código que después de 30 años sigue siendo robusto. ¿Por qué? Porque hay una visión, unos principios, alguien que dice “no”.
Windows: Necesitamos directorios, control de usuarios, networking, multimedia, etc. Microsoft armó 20 equipos para eso. Coordinación entre equipos significó compromisos, limitaciones, “vamos a hacer esto de forma que el otro equipo pueda trabajar en paralelo.” El resultado es Windows: un SO que funciona, pero con decisiones que no cierran si las mirás dos segundos. Lo explicamos a fondo en alternativa de despliegue local.
Recuperar coherencia: Estrategias para empresas
No se trata de volver a un monolito. Domain-Driven Design (DDD) ofrece una salida: definir límites claros entre dominios, cada uno con interfaces públicas explícitas, cada equipo autónomo dentro de su dominio pero sin poder tocar el de otros.
Requiere:
- Un Chief Architect (o un pequeño grupo) que tiene el veto final en arquitectura. No democracia. Dictadura benevolente.
- Documentación de interfaces entre equipos. Contratos claros. Si cambias tu API, los otros equipos ven el cambio coming y planifican.
- Decisiones arquitectónicas centralizadas. No “cada equipo elige su stack”. Base de datos única o al menos schema unificado. No 15 bases de datos diferentes porque cada equipo eligió la suya.
- Code review entre equipos. Si tu cambio afecta mi dominio, debo revisarlo.
| Variable | FOSS pequeño (coherente) | Enterprise grande (fragmentado) |
|---|---|---|
| Equipo | 5-10 personas, 1-2 arquitectos | 100-500 personas, 5-50 equipos |
| Visión central | Sí, clara, 1 persona la define | No, múltiples equipos con agendas propias |
| Límites arquitectónicos | Definidos, documentados, se respetan | Porosos, constantemente violados, negocios |
| Proceso decisión | Rápido (horas), veto claro | Lento (semanas), consenso imposible |
| Coherencia resultante | Alta, código es kunst, interfaces predecibles | Baja, parches, límites invisibles, sorpresas |
| Ejemplo | SQLite, Git, curl, Linux kernel | Windows, Oracle DB, SAP, Salesforce |
Errores comunes al ignorar Conway
Error 1: “Vamos a arreglar la arquitectura sin reorganizar equipos.” No funciona. Si tu problema es organizacional, el código solo seguirá siendo un reflejo de eso. Remasterizar la arquitectura mientras conservas 30 equipos con jefes diferentes es tirar dinero.
Error 2: “Más integraciones van a conectar los silos.” Integraciones superficiales entre sistemas fragmentados crean ilusión de unidad. La verdad subyacente sigue siendo: datos dispersos, equipos desconectados. En dos años, la integración es frágil, nadie entiende qué sistema es la “verdad”, y todo se rompe en la primera refactorización de cualquier extremo.
Error 3: “Vamos a documentar bien y así el código se entiende.” Documentación no cambia la realidad de que tu código es un mosaico. Es como poner señalética clara en un edificio mal diseñado. Ayuda, pero el problema persiste.
Preguntas Frecuentes
¿Qué dice exactamente la Ley de Conway?
Que la estructura de cualquier sistema de software diseñado por una organización reflejará la estructura de comunicación de esa organización. Dicho de otra forma: organizaciones descentralizadas crean módulos descentralizados; organizaciones jerárquicas crean arquitecturas jerárquicas; organizaciones fragmentadas crean software fragmentado. No es una maldición; es una predicción de física organizacional.
¿Cómo logró SQLite ser tan coherente?
Una visión clara (“una librería SQL embebible, sin dependencias, portátil”) y una persona (Richard Hipp) que defende esa visión durante 27 años. Cada feature se veta si no cierra con la visión. Resultado: un software que hace una cosa y la hace perfectamente. No intentes hacer Oracle sobre SQLite; simplemente usa SQLite cuando necesitás ligereza. Relacionado: restricciones en la generación de video.
¿Qué es Brooks’s Law y por qué importa?
Que agregar personas a un proyecto atrasado lo ralentiza, porque la comunicación entre N personas crece exponencialmente (O(N²)). Con 10 personas son 45 canales; con 100, son 4,950. Cada nueva persona requiere onboarding, cada cambio requiere más coordinación. Por eso equipos pequeños con visión clara casi siempre ganan a equipos grandes sin rumbo.
¿Necesito un monolito para recuperar coherencia?
No. DDD (Domain-Driven Design) permite múltiples servicios autónomos mientras se mantiene integridad conceptual. Necesitás límites claros, interfaces públicas documentadas, y una autoridad (arquitecto o equipo pequeño) que tenga veto en cambios. Monolito vs microservicios es una decisión de implementación; coherencia es una decisión de arquitectura.
¿Por qué el software FOSS suele ser mejor que el empresarial?
No siempre es mejor, pero cuando es mejor, es por una razón: equipos pequeños, una visión clara, y un punto de vista. No hay política de ejecutivos, sin presión de quarterly revenue, sin presupuestos cortados a mitad de año que obligan a compromisos absurdos. Si necesitás herramienta empresarial con presupuesto, considera adoptar o contribuir a FOSS.
Conclusión
La Ley de Conway no es un maldición; es un reflejo. Si tu organización es fragmentada, tu software será fragmentado. Si tu organización tiene equipos autónomos pero límites claros, tu software tendrá eso. La pregunta no es “¿cómo hago software coherente?” sino “¿cómo organizo mi equipo para que naturalmente produzca software coherente?”
SQLite ganó porque una persona cuidó una visión durante 27 años. Git ganó porque Linus Torvalds veta cada commit. Linux kernel gana porque tiene arquitecto (o varios) pero principios claros. Windows perdió coherencia cuando la fragmentación organizacional de Microsoft se propagó al código.
Vos podés aprender de eso. No necesitás 500 personas para lograr escala. Necesitás 5-10 con una visión, límites arquitectónicos claros, y alguien con autoridad para decir “no.” Si en tu empresa eso no es posible, entonces el software fragmentado que ves es síntoma de un problema organizacional más profundo.
Fuentes
- More Vetoes, Less Vision — Scribe by Hemanth — Análisis original sobre cómo la estructura organizacional impacta la coherencia de software.
- Melvin Conway — Conway’s Law — Artículo original que define la Ley de Conway (1967).
- Ley de Conway — Wikipedia — Explicación y referencias históricas sobre el principio.
- SQLite Database Engine — Documentación de SQLite, ejemplo de software coherente.
- The Mythical Man-Month — Wikipedia — Referencias a Brooks’s Law y la escala de comunicación en equipos.