Architecture and components of the service
A technical view of the components that form DATUM Data Space Gateway, their responsibilities and how they work together to enable governed sharing of data products.
Seven components, one coherent architecture
Each component has a unique and explicit responsibility. No overlap, no circular dependencies.
Internal platform for governance, DataOps and publication. Manages metadata, quality, ownership, lineage and internal data products. It is the foundation on which the Gateway operates.
Registry of externally published assets. Contains public metadata, access conditions and available versions of each shared data product.
Layer for definition, negotiation and enforcement of usage policies. Manages who can access, for what, for how long and under what restrictions.
Technical interoperability component. Implements federated sharing protocols, aligned with the Eclipse Dataspace Protocol, technically decoupling publisher and consumer.
Immutable store of all agreements, accesses and usage conditions. Foundation of audit, compliance and real sovereignty of shared data.
DATUM's DataOps circuit feeds the Gateway with certified assets and receives validated external assets. Integration is bidirectional and governed.
Process of receiving, validating and assimilating external assets into DATUM. Ensures that consumed data meets internal quality and traceability standards.
Technical components are not the product.
The product is the capacity to govern through them.
Who manages what in the operational model
| Role | Responsibility |
|---|---|
| Data Owner | Authorises which assets may be published and under what usage conditions |
| Data Office | Manages the backlog of sharing initiatives and validates policy compliance |
| Data Architect | Designs the integration between DATUM Core and the Gateway, and defines the external catalogue model |
| Platform SMEs | Configure and operate the Gateway, the federated connector and the agreement registry |
| IT / Security | Manage infrastructure, federated identity and technical access to the Gateway |
| Data Committee | Approves sharing policies and exceptions affecting critical or sensitive assets |
Five technical differentiators of the Gateway
The Gateway is built on the same components that govern data inside: catalog, metadata, quality, lineage. It is not an additional module with its own model.
Policies are expressed as usage rules, not technical permissions. This allows translating commercial contracts and regulatory obligations to applied control, not documented.
Every operation —publication, consumption, policy modification— leaves trace in standardized auditable format. Traceability is system output, not later construction.
Compatible with Eclipse Dataspace Protocol and Data Spaces Support Centre components. No rewriting integration when the dominant standard changes.
The Gateway updates, scales and evolves without touching internal operation. Changes to the federated edge do not compromise Core operation.
Four demonstrable technical metrics
Every asset in the external catalog has its usage policy applied. No orphan assets remain at the federated edge.
From when the operation occurs until the evidence is available for audit. Controlled and monitorable time.
The Gateway responds within the agreed SLA on the 95th percentile of requests. Predictable performance for scaling.
Operational adherence to Eclipse Dataspace Protocol and European frameworks without overpromising unimplemented compatibilities.
Connect with the rest of the capability
dsg.arquitectura.related.lead