Datum · Architecture · Planes and principles

The architecture doesn't constrain the data. It structures it.

Three model planes
The layers of DATUM

A complete model. Not separate pieces.

DATUM covers the complete data cycle — from strategy to data products — in an integrated, governed and secure-by-design model.

Sources
ERPCRMCoreExternal
Data Strategy
Vision, roadmap and executive sponsors
Strategy · Governance
Data GovernancePillar
Real time
Events · streaming
AI / ML
Models on governed data
◈ Metadata
Metadata
Catalogue, glossary and lineage
The core of Datum. Glossary, dictionaries, lineage and operational metadata in real time.
DataOps
Pipelines, quality and automation
Data Products
Business autonomy and federation
Pillar
Data Architecture
Sources, integration and velocity
Data architecture
Security by design
Least privilege, classification and audit
Consumption
AnalyticsReportingAI / MLAPIs
Metadata
The core of Datum. Glossary, dictionaries, lineage and operational metadata in real time.
How it works

Three complementary planes working together within a continuous data flow.

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

Strategic plane

Governance model, roles, policies, data office, committee, backlog and business-aligned decision criteria.

Plano

Platform plane

Metadata engines, DataOps, quality, observability and publication that turn the framework into real operations.

Plano

Exploitation plane

KPIs, dashboards, data products, business domains, governed self-service and AI foundation.

Flujo estructural del dato

Del origen al producto de datos

Gobierno + automatización + explotación

Sources & capture

Operational systems, APIs, files and events. The platform supports batch ingestion and, optionally, streaming and real-time.

Raw & standardisation

First technical landing of the data, initial traceability, structural control and organisation by metadata-governed layers.

Common Data

Corporate common model with entities, relationships, shared semantics and a foundation for cross-business exploitation.

Quality & control

Rules, scorecards, observability, remediation and traceability integrated into the data operations flow.

Business & KPIs

Indicator calculation, aggregations, semantic models and controlled publication for reporting, BI and governed self-service.

Data products & AI

Business exposure by domain, data products, internal marketplace and consistent foundation for advanced analytics and artificial intelligence.

The three planes

Each plane has a distinct responsibility and its own language.

01
Strategic plane

Governance model, roles, policies, data office, committee, backlog and business-aligned decision criteria.

02
Platform plane

Metadata engines, DataOps, quality, observability and publication that turn the framework into real operations.

03
Exploitation plane

KPIs, dashboards, data products, business domains, governed self-service and AI foundation.

What this layer activates

Four decisions that determine whether the architecture scales or becomes technical debt.

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.

01
Separación por responsabilidad

Gobierno, operación y explotación son planos distintos con responsabilidades distintas. Mezclarlos genera dependencias que impiden escalar.

Cada plano puede evolucionar de forma independiente sin romper los demás.
02
Metadato como eje central

El metadato no es documentación — es el mecanismo que conecta gobierno, DataOps y consumo. Sin él, cada pieza opera de forma aislada.

Una arquitectura metadato-first permite automatizar, gobernar y reutilizar desde el diseño.
03
Modularidad y evolución

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.

Foundation → Governed → Federated → Data Products: cada fase añade capacidad sin romper la anterior.
04
Trazabilidad extremo a extremo

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.

El linaje no se añade a posteriori. Se diseña desde la primera capa de ingesta.
Execution patterns

One architecture for multiple execution patterns.

The architecture does not limit how data is executed. Batch, streaming and governed publication coexist within the same framework without fragmenting the model.

01
Governed batch

Scheduled processing for periodic loads, consolidations and structured transformations with integrated quality control.

02
Streaming / real-time optional

Additional capability from Governed level for events and lower-latency use cases, and native in more advanced levels.

03
Publication by layers and products

Data exposure via KPIs, corporate datasets and, at higher levels, domain data products.

04
Observability and control

Monitoring, logging, alerting and operational metrics to understand what happens in each process and sustain the platform.

Keep exploring

From architecture to the operating model

datum_architecture_page.related.lead

24 guiding principles · The quality contract of DATUM

DATUM architecture is not a technical choice. It is a set of non-negotiable principles.

These principles are the product quality contract. A CTO·CIO or architect who reads them knows exactly what DATUM guarantees and what it cannot compromise. These are not best practices — they are design constraints.

01
Data and governance
Data is a corporate asset

It does not belong to a system or an isolated technical team. It has a functional owner, quality rules, traceability and authorised use.

02
Data and governance
Data governance precedes technology

First the metadata is defined. Then technical structures are generated. Never the other way around.

03
Data and governance
Business defines the meaning of data

Not IT. Not architecture. The glossary and functional dictionary are the Data Owner's responsibility, validated with the technical team.

04
Architecture
Separation between governance, platform and infrastructure

Each plane has distinct responsibilities and can evolve independently without breaking the others.

05
Architecture
Each layer has a unique and explicit purpose

Landing, Operational, Common Data, Business. No mixing of responsibilities between layers.

06
Architecture
Metadata governs the architecture

Structures, rules, pipelines and publication are generated from metadata. The architecture is deterministic, not artisanal.

07
Architecture
Architecture scales without breaking the core

Adding a new domain does not mean rewriting the model. It means parameterising the existing structure.

08
Operations
Data operations must be idempotent

The same input always produces the same output. Running a process once or a hundred times produces the same result. No variability by state.

09
Operations
Data quality is embedded in the flow

Not added afterwards. Quality rules are part of the DataOps circuit from the first ingestion layer.

10
Operations
Automation is reusable · Minimum coding

Ingestion, transformation and publication patterns are reusable across domains. No arbitrary embedded SQL. No artisanal code per project.

11
Operations
Architecture must be traceable end-to-end

Any data in any layer can explain where it came from, how it was transformed and who touched it. Lineage is not optional.

12
Security and access
Security is integrated by design

Classification, least privilege, masking and continuous audit are part of the model from day one. Not added at the end.

13
Security and access
Least privilege and minimum exposure principle

Each user accesses only the data they need for their function. Access is justified, documented and reviewed.

14
Security and access
Publication is not a free replica

It is a formal, controlled and traceable delivery. Business accesses published data — not internal operational layers.

15
Security and access
Cross-owner access is not free

It must be governed, justified and traced. Cross-domain access is preferably done through governed publication, not direct access.

Who leads this in your organisation?

A specific profile, a real question.

Si lidera tecnología o arquitectura
CTO·CIO · Arquitecto de datos · Director de IT
«¿Cómo diseño una arquitectura que escale sin reescribirse cada dos años?»

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.

Añadir gobierno a posteriori cuesta entre 3x y 5x más que diseñarlo desde el inicio.Forrester — Total Economic Impact of Data Governance 2023
Banca · Financiación al consumo
+1.500%
rendimiento analítico

Rediseño de arquitectura DATUM con Common Data corporativo, DataOps industrializado y publicación gobernada para analítica multi-país.

Arquitectura EnterpriseCloud híbridaSnowflake
Next step

The architecture is not valuable for what it contains, but for what it allows to operate.

Next step