marybernalj La evolución de la arquitectura de datos. Arquitecturas modernas y patrones de diseño
Cada vez confirmo que entender las arquitecturas de datos no es solo cuestión técnica, sino una forma de ver cómo evoluciona el conocimiento en las organizaciones …
Serie · Data Architecture Stories
De los datos al conocimiento: cómo diseñar infraestructuras con propósito
Imaginemos que el mundo de los datos es una pirámide. En su base se encuentra la información que da soporte a la operación diaria: las transacciones, los registros, los movimientos que mantienen viva a la organización. En la cima están las decisiones, la analítica avanzada y la inteligencia artificial. Entre ambos extremos, hay capas de arquitectura que permiten que los datos asciendan con propósito, estructura y sentido.
Durante décadas, esa base ha estado compuesta por las bases de datos relacionales, estructuras sólidas, precisas, que garantizan integridad y consistencia. Son los cimientos sobre los que funcionan los sistemas de facturación, ventas, nómina, atención al cliente o gestión hospitalaria, entre otros. Pero, aunque son diseñadas para registrar, no lo son necesariamente para analizar. Su lenguaje es el de la exactitud, no el de la exploración.
Cuando las organizaciones empezaron a necesitar respuestas más allá de lo transaccional, entender tendencias, correlaciones o comportamientos, surgió el Data Warehouse. Este modelo trajo orden, limpieza y coherencia: un entorno estructurado donde los datos se integran, se transforman y se preparan para análisis confiables. Es la primera capa que conecta la operación con la estrategia.
Sin embargo, la realidad se volvió más compleja. Las empresas ya no solo registraban números, sino textos, imágenes, videos, clics, interacciones, datos de sensores o redes sociales, de manera más diversa y más rapida. Y con ello, la estructura rígida del warehouse empezó a quedar corta. Fue entonces cuando emergen estructuras como el Data Lake, que permite almacenar información diversa en su estado original. El lago ofrece flexibilidad, pero también trajo un nuevo desafío: sin gobernanza, puede volverse un “pantano” donde los datos se pierden entre el ruido.
La búsqueda de equilibrio entre control y flexibilidad dio origen al Data Lakehouse, una arquitectura híbrida que combina lo mejor de ambos mundos. Mantiene la calidad y estructura del warehouse, pero con la apertura y escalabilidad del lake. Muchas organizaciones adoptan este enfoque cuando desean progresar en analítica avanzada y machine learning sin perder trazabilidad.
A medida que los volúmenes de datos crecieron y las organizaciones se volvieron más descentralizadas, apareció una nueva pregunta: ¿cómo mantener la coherencia cuando los datos están distribuidos por toda la empresa? La respuesta comenzó a llegar desde dos enfoques complementarios: Data Mesh y Data Fabric.
El Data Mesh nace como una propuesta para democratizar los datos y llevar la responsabilidad a los equipos que más los entienden. En lugar de centralizarlo todo en un solo lago o almacén, distribuye la gestión entre dominios: cada área, finanzas, marketing, operaciones, clientes, se convierte en dueña de sus propios datos y los trata como productos. Esto reduce los cuellos de botella de los equipos técnicos y acerca la inteligencia al conocimiento del negocio. No se trata solo de tecnología, sino de cultura: colaboración, responsabilidad compartida y estándares comunes.
Pero la descentralización también trae su reto: ¿cómo garantizar que esos dominios no se conviertan en islas de datos inconexas? Aquí es donde entra el Data Fabric. Si el Mesh reparte el poder, el Fabric lo conecta. Es una capa inteligente y automatizada que une todos los entornos, on-premise, nube, bases relacionales, lakes o APIs externas, a través de metadatos activos, automatización y orquestación inteligente.
El Fabric no mueve los datos, los teje, asegurando que estén disponibles, contextualizados y gobernados sin importar dónde se encuentren.
Y aquí surge una reflexión clave: ¿son opuestos el Mesh y el Fabric? No. En realidad, responden a capas distintas del mismo problema.
El Data Mesh define cómo se organizan las personas y los dominios en torno a los datos.
El Data Fabric, cómo se conectan y automatizan esos datos a nivel técnico.
Uno es una arquitectura socio-técnica, el otro una infraestructura tecnológica.
Por eso, lejos de competir, se potencian mutuamente: el Fabric ofrece la columna vertebral que hace posible la descentralización responsable del Mesh, y el Mesh aporta el contexto humano y organizacional que da sentido al Fabric.
En conjunto, ambos representan el paso hacia arquitecturas adaptativas, capaces de aprender, integrar y evolucionar sin perder coherencia.
Con esto, la arquitectura de datos deja de ser un conjunto de capas estáticas para convertirse en un ecosistema que se autorregula y se amplía según la complejidad de la organización.
Y al final, lo que realmente importa no es el nombre de la arquitectura, sino su capacidad para convertir datos dispersos en conocimiento conectado. Porque los datos, como las ideas, solo cobran sentido cuando se relacionan.
En este punto, es importante distinguir entre las arquitecturas modernas de datos y los patrones de diseño que las hacen posibles.
Las arquitecturas, como el Data Warehouse, el Data Lake, el Lakehouse, el Mesh o el Fabric, definen cómo se estructura y organiza el ecosistema de información. Son el mapa de la ciudad. Los patrones, en cambio, son las reglas de tránsito, los caminos y la lógica que permiten que todo funcione sin caos: desde arquitecturas orientadas a eventos (Event-Driven Architecture) hasta modelos híbridos como Lambda o Kappa, pasando por enfoques como DataOps o microservicios de datos, que aportan agilidad y control.
Una organización puede tener una arquitectura Lakehouse y gobernarla con principios de DataOps; o un Data Mesh que opera con flujos event-driven y pipelines organizados. Las arquitecturas dan forma; los patrones, movimiento. Y cuando ambos se integran con propósito, los datos dejan de ser estructuras estáticas para convertirse en sistemas vivos, capaces de adaptarse, aprender y evolucionar.
Un consejo práctico es no tratar de saltar de una arquitectura tradicional a un modelo avanzado de la noche a la mañana. Evoluciona por capas: ordena tus fuentes, limpia tus flujos, estandariza tus procesos, y luego automatiza. La madurez arquitectónica se construye paso a paso, no con grandes migraciones.
En última instancia, entender las arquitecturas de datos es entender las etapas de madurez de una organización. No se trata de seguir modas, sino de construir estructuras que crezcan con el conocimiento. Porque, como toda buena ciudad, un ecosistema de datos bien diseñado no se impone: se habita, se vive y se mejora cada día.
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 decidir (y no solo para reportar).
