Data Apps: The Applications That Multiply the Value of Your Data Space
A data space that only moves information from one point to another falls short of its full potential. Data rarely arrives ready to use: it needs to be anonymized, checked for quality, transformed, or enriched before it holds real value for whoever receives it. That's where data apps come in—one of the components that raises the most questions among software architects and development teams starting out with data spaces.
If you're a CTO or architect wondering how to add business logic to data flows without breaking the connector's interoperability or security, this article is for you. We'll explain what data apps are according to the International Data Spaces reference model (IDS-RAM), what types exist, and how to build your own from templates.
In a modern data space, data apps are the mechanism that allows companies and public administrations in Castilla y León to go beyond simple file exchange and turn their data into value-added services.
What data apps are in a data space
The IDS-RAM reference model defines data apps as reusable, certifiable applications deployed on the connector to process or transform data: a standard concept within the IDS ecosystem, not a proprietary feature of any single platform. In practice, it's an independent service, typically packaged in a Docker container, that connects to the connector to process information before or after it's shared, without replacing the connector's identity functions.
The model distinguishes between processing apps, which transform or enrich data in transit, and adapters, which translate formats or protocols with external systems. Distribution is handled through a data space App Store, from which any participant can publish or adopt already-certified data apps.
This separation of responsibilities is key. The connector handles secure communication, mTLS authentication, and compliance with usage policies defined in the policy engine. The data app handles the business logic: anonymizing, validating, enriching, converting formats, or generating synthetic data.
The difference between a connector and a data app
Many development teams confuse the two concepts at first. The IDS connector is the piece of infrastructure that ensures data enters or leaves the data space in a traceable way and in compliance with an agreement. The data app is the application piece that decides what happens to that data as it passes through the system.
This decoupled architecture has an enormous practical advantage: new data-processing capabilities can be added without touching the connector's core or renegotiating the security infrastructure. All it takes is deploying a new container and connecting it to the relevant flow.
Real examples of data apps in production
In data space platforms that follow the IDS model, the transfer module already includes several types of data apps that address very specific needs for companies and public administrations.
Automatic anonymization: applies k-anonymity techniques and differential privacy to a dataset before it leaves the organization's perimeter, so the recipient can analyze it without accessing personally identifiable data.
Data quality control: validates completeness, accuracy, and consistency in both batch processes and real-time flows, blocking or flagging records that don't meet defined business rules.
Synthetic data generation: creates artificial datasets that reproduce the statistical properties of the original data, useful for testing, sales demos, or model training without exposing real information.
Transformation and enrichment: normalizes formats, cross-references external catalogs, or adds metadata before the data reaches the federated catalog published in DCAT-AP-ES format.
Consider the case of an agri-food cooperative in Castilla y León that wants to share production data with a market analysis consultancy. Before that data leaves its connector, an anonymization data app replaces individual farm identifiers with aggregated ranges, meeting the agreed usage terms without losing statistical value for the consultancy.
Another common case is a municipal government in the region publishing data on municipal resource consumption. A quality data app automatically checks for duplicate readings or time gaps before the dataset is added to the federated catalog, preventing the publication of unreliable information.
How data apps integrate with the connector
The typical flow of a data app within a data space follows these steps:
- The connector receives a data transfer request covered by a previously registered usage agreement.
- The policy engine, based on Open Policy Agent, checks whether the flow needs to pass through one or more data apps before completing.
- The data is sent to the corresponding data app's Docker container through a defined interface.
- The data app processes the data and returns it to the connector, which continues the transfer to the final recipient.
This entire process is logged, so both the data provider and consumer can audit which transformations were applied. This traceability is especially important for anyone working with regulated or sensitive data.
Deployment in Docker containers
The use of Docker as a packaging standard is no accident. It allows development teams to work with the language and libraries they prefer, as long as they expose the interface the connector expects. This greatly lowers the barrier to entry: a team experienced in data processing with Python or TypeScript services can bring their existing code to the data space with minimal adaptations.
In addition, container isolation makes horizontal scaling easier when, for example, a data quality data app needs to process streaming flows with variable volume spikes.
How to develop your own data app from templates
One of the aspects most appreciated by development teams is that they don't need to start from scratch. Data space platforms typically include templates for building custom apps in both TypeScript and Python, designed to speed up the development of tailored data services.
The typical process for creating your own data app follows these steps:
- Start from the base template: includes the minimum configuration structure, data input/output handling, and the necessary hooks to communicate with the connector.
- Define the processing logic: this is where the specific transformation is implemented, whether it's a validation rule, a custom anonymization algorithm, or an integration with an external system.
- Configure the data contract: specifies what input format the data app expects and what output format it delivers, so the connector can route it correctly within the flow.
- Package in Docker: the container image is built following the platform's conventions, including the environment variables needed for authentication with the connector.
- Test in a controlled environment: before publishing, it's advisable to validate the data app with test datasets or synthetic data, checking both performance and correctness of the results.
- Publish and version: once validated, the data app becomes available to be invoked from the transfer flows defined by the usage agreements.
For example, a development team at a services company in Castilla y León that needs to convert files from a proprietary format to an open standard before sharing them can build that logic as a data app in TypeScript, reusing the template, without having to modify either the connector or the catalog.
Best practices for building your own data services
There are a few recommendations worth keeping in mind that come up repeatedly in projects of this kind:
- Design the data app to be idempotent, so that reprocessing the same data doesn't produce inconsistent results.
- Keep processing decoupled from the source and destination of the data, so the same data app can be reused across different usage agreements.
- Clearly document the input and output contract, especially if the data app will be shared with other teams or published in an internal service catalog.
- Monitor the container's resource consumption when working with real-time flows, to avoid bottlenecks in the connector.
The role of data apps in data strategy
Beyond the technical side, data apps are also a strategic decision. They make it possible to offer data at different levels of processing depending on the recipient: a complete dataset for a trusted partner, an anonymized one for a third party, a synthetic one for a sales demo—all without duplicating infrastructure or giving up the control the connector provides. Moreover, a data quality validation app built once can be reused across multiple flows within the organization or made available to other data space participants.
Start building your own data apps
If your organization already participates in, or is considering joining, a data space, data apps are the natural next step to get real value from the information flows you manage. If your organization is considering taking this step, look for a technology partner with experience in data spaces who can help you assess which template best fits your use case and how to start deploying your first data services.