marybernalj De la analítica descriptiva a la toma de decisiones
Serie · Data Architecture Stories
De los datos al conocimiento: cómo diseñar infraestructuras con propósito
En los primeros relatos de esta serie hablamos de la necesidad de dar estructura a los datos, de los cimientos invisibles que sostienen cualquier sistema analítico y de cómo la evolución del Data Warehouse al Data Lake abrió la puerta a nuevos usos y escalas. Todo ese recorrido tiene un punto en común: la arquitectura no es neutra. Cada decisión de diseño habilita, o limita, lo que puede hacerse después con los datos.
Durante mucho tiempo, la arquitectura de datos se diseñó con una misión clara y aparentemente suficiente: responder preguntas conocidas. Indicadores mensuales, reportes operativos, dashboards que mostraban qué había pasado y si los números subían o bajaban. Ese enfoque funcionó durante años y permitió a muchas organizaciones ordenar su información y ganar control. Pero el contexto cambió. Y con él, las preguntas.
Hoy las organizaciones no solo necesitan saber qué ocurrió, sino qué está ocurriendo, qué podría ocurrir y qué conviene hacer a continuación. Quieren anticipar, simular escenarios, entender trayectorias y no solo resultados finales. Y ese cambio transforma el papel de la arquitectura de datos.
Un sistema pensado únicamente para reportes suele estar optimizado para agregaciones, métricas estables, cortes temporales fijos y consultas predefinidas. Funciona bien cuando las preguntas son repetitivas y conocidas de antemano. Pero cuando el objetivo es apoyar decisiones complejas, ese mismo diseño empieza a mostrar sus límites. Los datos llegan resumidos, los historiales se pierden, las relaciones entre dominios no existen o son difíciles de reconstruir. No falla el análisis; falla la base que lo sostiene.
Hay una idea clave que henos estado hablando en toda la serie: la arquitectura de datos define qué preguntas pueden hacerse y cuáles no podrán responderse. Si los datos están excesivamente agregados, desconectados entre áreas o modelados solo para eficiencia de consulta, se vuelve casi imposible analizar evolución en el tiempo, entender interacciones complejas o detectar patrones que no estaban previstos desde el inicio. No es una limitación del equipo analítico ni del modelo que se quiera aplicar; es una limitación estructural.
En una arquitectura orientada a la toma de decisiones, el tiempo deja de ser un simple atributo y se convierte en un eje central del diseño. Ya no basta con guardar el estado actual; es necesario conservar el historial, permitir múltiples escalas temporales y evitar sobrescribir información que puede ser clave para entender cambios. Cuando el tiempo se integra correctamente, los datos dejan de ser solo números y empiezan a contar historias: trayectorias, transiciones, acumulaciones y rupturas.
Lo mismo ocurre con los dominios. Las decisiones reales rara vez dependen de una sola variable. Surgen de la interacción entre comportamientos, contextos, estados y cambios acumulativos. Una arquitectura moderna debe facilitar estas conexiones, permitir análisis cruzados y evitar silos rígidos que fragmentan la comprensión. No se trata de perder estructura, sino de diseñarla con intención analítica, sabiendo que muchas preguntas aún no existen cuando se construye el sistema.
No toda arquitectura está pensada para decidir, y eso no es necesariamente un error. Pero sí es un riesgo no reconocer cuándo un diseño, válido para reporting, se convierte en un freno para el análisis avanzado, la analítica predictiva o el uso de modelos más complejos. Diseñar para decidir implica aceptar la incertidumbre, las preguntas abiertas y los usos futuros que todavía no están completamente definidos.
Si quieres saber si tu arquitectura está preparada para apoyar decisiones, hazte una pregunta simple: ¿puedo reconstruir cómo y por qué algo cambió en el tiempo, sin rehacer todo el sistema?. Como consejo practico, empezar a guardar el historial, desacoplar capas y preservar señales temporales suele ser más valioso que añadir una nueva tecnología.
En el próximo post para dar cierre a la serie, hablaremos de cuando la arquitectura deja de servir solo al análisis y comienza a alimentar sistemas que aprenden, modelos que evolucionan y decisiones que ya no se toman solo mirando hacia atrás, sino también hacia adelante.
Este artículo hace parte de la serie Data Architecture Stories, donde exploramos cómo los datos se convierten en conocimiento a través del diseño, la cultura y la tecnología.
Próximo post: Arquitectura de datos para IA.
