Cuando una organización decide construir una plataforma tecnológica de capacidades — de datos, de servicios, de integración — enfrenta una tensión que se repite con notable consistencia: la tentación de diseñarla completa antes de usarla. La lógica parece sólida: mejor hacerlo bien desde el inicio que tener que corregir después.
El resultado, sin embargo, es predecible. La plataforma se convierte en un proyecto de meses o años. Cuando finalmente está disponible, parte de lo que se diseñó ya no responde a lo que el negocio necesita. Y el costo de haber esperado — invisible durante la construcción — se hace evidente demasiado tarde.
Este no es un problema de equipos poco rigurosos. Es un problema de paradigma. Y lo llamaremos: Big Architecture Up Front. El equivalente arquitectónico del Big Design Up Front que el mundo del desarrollo de software tardó décadas en superar.
Lo que esta página recoge es el cuerpo de conocimiento técnico que existe para abordarlo. No como recetario, sino como fundamento: seis marcos conceptuales que, leídos juntos, describen una forma diferente y más efectiva de construir plataformas — una que no sacrifica solidez por velocidad, sino que entiende que la solidez real solo se puede construir de forma incremental.
El Rigor mal orientado: Completeness Fallacy & Correctness Bias
Evolutionary Architecture — El marco fundacional. Define cómo una arquitectura puede preservar lo que importa mientras evoluciona con el entorno, a través de mecanismos de cambio guiado e incremental. Establece que las decisiones arquitectónicas deben tomarse en el momento de mayor información disponible — no al inicio, cuando se sabe menos.
Just Enough Architecture — El criterio profesional que le da nombre técnico preciso a "suficiente". Introduce el modelo basado en riesgo como mecanismo de calibración: el rigor arquitectónico debe ser proporcional al riesgo real, no a un estándar abstracto de completitud. Suficiente no es lo opuesto de sólido — es lo opuesto de desperdicio.
Cost of Delay & Premature Completeness — El argumento económico y empírico. El tiempo tiene valor que se erosiona mientras se espera. Y entre el 64% y el 80% de las features construidas raramente o nunca se usan. Diseñar el 100% antes de entregar el 20% es invertir el máximo esfuerzo donde hay mínima certeza de valor — y hacerlo mientras el mundo sigue moviéndose.
Data Mesh + Platform as Product — La visión arquitectónica y el modelo de construcción. Data Mesh define cómo organizar los datos por dominio para que lleguen a quien los necesita sin acoplamiento al core. Platform as Product define el criterio de éxito: no "¿está completa la plataforma?" sino "¿está entregando valor a sus usuarios hoy?" Juntos convierten el incremental en estrategia, no en improvisación.
Security como Fitness Function — El argumento que devuelve la preocupación por seguridad dentro del paradigma evolutivo, no fuera de él. La seguridad no es un estado que se alcanza una vez — es una propiedad que se verifica continuamente. Definir las fitness functions de seguridad temprano no es lo mismo que implementarlas todas de inmediato. Y una plataforma intermedia bien diseñada no es el sacrificio de seguridad: es la arquitectura de seguridad.
Cost of Delay & Premature Completeness
Data Mesh + Platform as Product