La arquitectura no limita el dato. Lo estructura.
Un modelo completo. No piezas sueltas.
DATUM cubre el ciclo completo del dato — desde la estrategia hasta los productos de datos — en un modelo integrado, gobernado y seguro por diseño.
Tres planos complementarios que trabajan juntos dentro de un flujo continuo del dato.
El gobierno define las reglas. La plataforma ejecuta el ciclo del dato. La explotación activa el valor. Esa separación clara permite que cada plano evolucione sin romper los demás.
Plano estratégico
Modelo de gobierno, roles, políticas, oficina del dato, comité, backlog y criterios de decisión alineados con negocio.
Plano de plataforma
Motores de metadatos, DataOps, calidad, observabilidad y publicación que convierten el framework en operación real.
Plano de explotación
KPIs, cuadros de mando, productos de datos, dominios de negocio, autoservicio gobernado y base para IA.
Del origen al producto de datos
Fuentes y captura
Sistemas operacionales, APIs, ficheros y eventos. La plataforma soporta ingesta batch y, de forma opcional, streaming y real time.
Raw y estandarización
Primer aterrizaje técnico del dato, trazabilidad inicial, control estructural y organización por capas gobernadas por metadatos.
Common Data
Modelo común corporativo con entidades, relaciones, semántica compartida y base para la explotación transversal del negocio.
Calidad y control
Reglas, scorecards, observabilidad, remediación y trazabilidad integradas en el flujo de operación del dato.
Business y KPIs
Cálculo de indicadores, agregaciones, modelos semánticos y publicación controlada para reporting, BI y autoservicio gobernado.
Productos de datos e IA
Exposición al negocio por dominios, productos de datos, marketplace interno y base consistente para analítica avanzada e inteligencia artificial.
Cada plano tiene una responsabilidad distinta y un lenguaje propio.
Modelo de gobierno, roles, políticas, oficina del dato, comité, backlog y criterios de decisión alineados con negocio.
Motores de metadatos, DataOps, calidad, observabilidad y publicación que convierten el framework en operación real.
KPIs, cuadros de mando, productos de datos, dominios de negocio, autoservicio gobernado y base para IA.
Cuatro decisiones que determinan si la arquitectura escala o se convierte en deuda técnica.
No son opciones — son principios que deben estar presentes desde el primer día. Añadirlos a posteriori siempre cuesta más que diseñarlos desde el inicio.
Gobierno, operación y explotación son planos distintos con responsabilidades distintas. Mezclarlos genera dependencias que impiden escalar.
El metadato no es documentación — es el mecanismo que conecta gobierno, DataOps y consumo. Sin él, cada pieza opera de forma aislada.
La arquitectura no se diseña para hoy. Se diseña para que mañana pueda añadirse un dominio, un patrón de streaming o un producto de datos sin rehacer el modelo.
Cualquier dato en cualquier capa debe poder explicar de dónde viene, cómo ha sido transformado y quién lo ha tocado. Esto no es opcional — es la base de la confianza.
Una misma arquitectura para múltiples patrones de ejecución.
La arquitectura no limita cómo se ejecuta el dato. Batch, streaming y publicación gobernada conviven dentro del mismo marco sin fragmentar el modelo.
Procesamiento planificado para cargas periódicas, consolidaciones y transformaciones estructuradas con control de calidad integrado.
Capacidad adicional desde Governed para eventos y casos de uso con menor latencia, y parte nativa de los niveles más avanzados.
Exposición del dato mediante KPIs, datasets corporativos y, en niveles superiores, productos de datos por dominio.
Monitorización, logging, alertado y métricas operativas para entender qué ocurre en cada proceso y sostener la plataforma.
De la arquitectura al modelo operativo
datum_architecture_page.related.lead
La arquitectura de DATUM no es una elección técnica. Es un conjunto de principios no negociables.
Estos principios son el contrato de calidad del producto. Un CTO·CIO o arquitecto que los lee sabe exactamente qué garantiza DATUM y qué no puede comprometer. No son buenas prácticas — son restricciones de diseño.
No pertenece a un sistema ni a un equipo técnico aislado. Tiene propietario funcional, reglas de calidad, trazabilidad y uso autorizado.
Primero se define el metadato. Después se generan las estructuras técnicas. Nunca al revés.
No IT. No arquitectura. El glosario y el diccionario funcional son responsabilidad del Data Owner, validados con el equipo técnico.
Cada plano tiene responsabilidades distintas y puede evolucionar de forma independiente sin romper los demás.
Landing, Operational, Common Data, Business. Sin mezcla de responsabilidades entre capas.
Las estructuras, las reglas, los pipelines y la publicación se generan desde el metadato. La arquitectura es determinista, no artesanal.
Añadir un dominio nuevo no implica reescribir el modelo. Implica parametrizar la estructura existente.
El mismo input produce siempre el mismo output. Ejecutar un proceso una o cien veces produce el mismo resultado. Sin variabilidad por estado.
No se añade a posteriori. Las reglas de calidad son parte del circuito DataOps desde la primera capa de ingesta.
Los patrones de ingesta, transformación y publicación son reutilizables por dominio. Sin SQL arbitrario embebido. Sin código artesanal por proyecto.
Cualquier dato en cualquier capa puede explicar de dónde viene, cómo fue transformado y quién lo tocó. El linaje no es opcional.
Clasificación, mínimo privilegio, enmascaramiento y auditoría continua son parte del modelo desde el primer día. No se añaden al final.
Cada usuario accede únicamente a los datos que necesita para su función. El acceso se justifica, se documenta y se revisa.
Es una entrega formal, controlada y trazable. El negocio accede al dato publicado — no a las capas operacionales internas.
Debe estar gobernado, justificado y trazado. El acceso cruzado entre dominios se realiza preferentemente por publicación gobernada, no por acceso directo.
Un perfil concreto, una pregunta real.
La deuda técnica crece con cada iniciativa. Cambiar una tecnología rompe el modelo. Añadir un nuevo dominio requiere rediseñar lo que ya existe. La arquitectura que funciona para hoy no aguanta mañana.
Rediseño de arquitectura DATUM con Common Data corporativo, DataOps industrializado y publicación gobernada para analítica multi-país.
La arquitectura no vale por lo que contiene, sino por lo que permite operar.
Siguiente paso