Charla · TDWI München 2026
Open Standards for Data Products
Dr. Simon Harrer (CEO & Co-Founder, Entropy Data) · 23 de junio de 2026
Una charla en solitario en TDWI München 2026, en tres movimientos. Simon abre con un adelanto del futuro: lanza un agente de programación para que construya un producto de datos por su cuenta y lo deja trabajando en segundo plano. Dedica la parte central de la charla al stack de estándares abiertos que hace todo eso posible (ODCS para los Data Contracts, ODPS para los productos de datos, OSI para la semántica) y a las herramientas open source que los rodean. Al final el agente ha terminado, y resulta que el futuro ya está aquí. La petición de cierre: ayuda a hacer historia llevando estos estándares hasta la meta.
En directo desde TDWI München 2026. La anotación de abajo es un resumen editado de las diapositivas.
El ponente
Simon Harrer se describe como un ingeniero de software de corazón que hace unos cinco años se pasó al mundo de los datos. Es coautor de "Java by Comparison" (que hoy forma parte de los datos de entrenamiento de varios modelos de lenguaje, como señala con una sonrisa) y tradujo al alemán "Data Mesh", de Zhamak Dehghani. La edición impresa alemana va a todo color, cosa que ninguna original en inglés hace.
Hoy es co-founder y CEO de Entropy Data, una pequeña startup que construye un marketplace de productos de datos y una capa de metadatos, con clientes en todo el mundo, seis personas y un montón de agentes haciendo el trabajo. Forma parte del Technical Steering Committee de Bitol en la Linux Foundation, contribuye a Open Semantic Interchange (la iniciativa de estandarización que puso en marcha Snowflake) y desarrolla herramientas open source alrededor de todo ello.
También mantiene data-landscape.com, un panorama abierto de los estándares abiertos del mundo de los datos. Merece la pena echarle un vistazo, dice: es todo abierto y gratuito.
El plan
Tres cosas. Primero, asomarnos al futuro a modo de motivación: ¿qué aspecto podría tener? Después, aprender sobre estándares, los abiertos: por qué existen y qué pueden hacer.
Y por último, hacer historia juntos. Ten el móvil a mano e inicia sesión en GitHub, le dice Simon a la sala, porque lo vamos a necesitar antes de terminar.
Un adelanto del futuro (solo un aperitivo)
La pregunta que enmarca todo: ¿y si ya estuviéramos usando estándares abiertos para productos de datos, y los viviéramos de verdad? Para responderla, Simon lanza una demo en vivo (con una grabación de respaldo lista, por si acaso). En un mismo directorio hay dos archivos: un Data Contract conforme al estándar que describe los datos que quiere ofrecer, y un archivo de producto de datos en ODPS que describe la caja del diagrama de arquitectura, con su propósito, su dominio, sus Output Ports y sus enlaces hacia la capa semántica.
Entonces arranca el agente de programación: claude --dangerously-skip-permissions, "haz que este producto de datos sea una realidad". Él solo escribió qué quiere. El agente se encarga del resto, y la construcción tarda unos 15 minutos.
Así que lo deja corriendo en segundo plano, con los tokens trabajando duro para nosotros, y pasa al verdadero tema de la charla. Quédate con esta imagen. La recompensa llega al final.
Primero: ¿qué es un producto de datos?
El público de una conferencia de datos ya se lo sabe, así que Simon va rápido. Un producto de datos es pensamiento de producto aplicado a los datos: optimizas para tus consumidores, asumes la propiedad, tienes un equipo que responde por él y construyes interfaces de las que te haces responsable. Es el segundo de los cuatro principios de Data Mesh.
El Data Product Canvas, gratuito y open source, es donde lo diseñas sobre el papel, en un taller con gente, partiendo del caso de uso. Simon llama al canvas terminado la "partida de nacimiento" del producto.
Como arquitecto de software de corazón, también ve un producto de datos como una unidad arquitectónica: recibe cosas por sus Input Ports, hace un montón de trabajo por dentro y expone resultados por sus Output Ports. En la demo inicial solo especificó el Output Port y la caja, y luego soltó al agente de programación.
¿Y qué es un estándar?
El xkcd de rigor lo explica muy bien. Necesitamos estándares para ponernos de acuerdo en algo y recortar complejidad: el único formato de fecha correcto es el estándar ISO, y todo lo demás está mal. Lo mismo con la cuenta atrás antes de empezar, "3, 2, 1, ya", para que nadie dude de si la acción arranca en el "uno" o después.
Y el riesgo de rigor: hay 14 estándares, un actor grande quiere entrar, y ahora hay 15. Pasa en todas partes, y el mundo de los datos no es una excepción. Útil cuando recorta complejidad, doloroso cuando solo añade otro competidor.
Qué hace bueno a un estándar
Simon plantea cuatro dimensiones, y en todas quiere el lado izquierdo:
- De facto frente a de iure (uso): si todo el mundo simplemente lo usa, en la práctica ya es un estándar, aunque ningún organismo lo declare así.
- Iniciativa frente a proveedor (propiedad): mejor cuando hay una iniciativa detrás, para que el poder no quede en manos de una sola empresa capaz de controlarlo por completo.
- Muchos frente a uno (control): ¿el poder está repartido entre quienes contribuyen, o lo tiene una única parte?
- Abierto frente a de pago (coste): ¿cualquiera puede leerlo y adoptarlo, o hay que pagarle a un organismo solo para leer la especificación?
Los estándares por los que merece la pena apostar se inclinan a la izquierda en las cuatro: usados de verdad, en manos de la comunidad, con gobernanza amplia y abiertos.
Un mapa de los estándares abiertos
Los estándares aparecen por todas partes en un producto de datos: para describirlo, para leer otros productos, en el procesamiento, el almacenamiento, la planificación, la monitorización y la observabilidad. Para ver todo el panorama de un vistazo, Simon mantiene data-landscape.com, un mapa interactivo y con criterio de los estándares de datos y metadatos, clasificados como adoptar, situacional, evaluar o precaución.
Para esta charla se centra en tres que conoce de cerca y sobre los que puede hablar con honestidad: ODCS, ODPS y OSI. Los demás solo los conoce desde fuera.
¿Qué es un Data Contract?
Un Data Contract existe para generar confianza. Un productor ofrece datos, un consumidor quiere usarlos, y el contrato que hay en medio recoge las promesas y garantías del productor sobre ese conjunto de datos (que puede ser varias tablas). Cubre estructura, semántica, propiedad, calidad y condiciones de uso.
La necesidad de Data Contracts surgió en paralelo en muchas empresas hace unos años. Cada una montó su propio formato en YAML, JSON, Excel, Word o Confluence, pero el problema de fondo siempre era el mismo: capturar las garantías que da un proveedor sobre una oferta de datos. (Más en ¿Qué es un Data Contract?)
La gran fusión de formatos
Esta es la historia. PayPal liberó su formato de Data Contract como versión 2.2 y lo donó a la Linux Foundation. La empresa de Simon también tenía un formato competidor, igual que muchas otras. Él se sumó al esfuerzo de estandarización, y el grupo reformó la versión de PayPal (que estaba pensada para una única plataforma de datos, porque no todo el mundo es PayPal ni trabaja solo con BigQuery) para que encajara en cualquier empresa.
Con la versión 3.1 fusionaron los dos linajes y retiraron el suyo, porque un estándar fuerte vale más que dos compitiendo. ODCS 3.2 está a la vuelta de la esquina. La lección: en lugar de convertirlo en 15 estándares, los bandos se unieron en uno solo, gobernado en Bitol.
Por dentro del Open Data Contract Standard
ODCS v3 lleva información de esquema, calidad de datos, precios (está en el estándar, aunque Simon nunca ha visto a nadie usarlo, una discusión académica divertida), propiedad y equipo, seguridad, acuerdos de nivel de servicio, infraestructura y más. Puedes leerlo todo en datacontract.com.
La parte interesante es el esquema: guarda cosas como la clasificación de los datos y las marcas de PII, valores de ejemplo y comprobaciones de calidad de datos integradas. Una comprobación puede imponer un conjunto de valores válidos; otra puede ser SQL puro que se ejecuta como control de calidad conforme al estándar. También puedes registrar quién es el dueño del producto y cómo contactarlo, las condiciones de uso (qué puedes y qué no puedes hacer con los datos, con enlaces a una política de privacidad o a la licencia si son datos comprados) y SLAs como retención y frescura.
Y dice dónde viven los datos. En el ejemplo es Postgres sobre Supabase, y a partir de ODCS 3.2 también hay una ubicación Hana. (Contexto: Open Data Contract Standard.)
¿Y ahora qué? Automatizarlo todo
¿Por qué merecía la pena el estándar? Porque no tienes que inventarte el formato y puedes colgarle lógica encima. Son los mejores metadatos que puedes tener sobre un conjunto de datos, sostiene Simon, y no hay nada mejor, sobre todo cuando además los enlazas con una ontología. En cuanto un contrato es legible por máquinas, impulsa todo lo demás:
- Generación de código: Java, Pydantic, modelos dbt, SQL DDL
- Tests: comprobar los datos en Hana o en cualquier otro sistema contra el contrato, en cada punto del ciclo de vida, más detección de cambios incompatibles y monitorización
- Distribución de metadatos: enviarlos a metastores, catálogos y marketplaces
- Aprovisionamiento de infraestructura: Output Ports, Input Ports, anonimización, control de acceso
- Colaboración y gobernanza: convenciones de nombres, evolución del esquema, acuerdos de uso, flujos de aprobación
Lo pueden usar las personas, lo pueden usar los sistemas deterministas y también los agentes, que es exactamente lo que está haciendo ahora mismo el que sigue construyendo en segundo plano.
Los estándares abiertos traen herramientas abiertas
Un estándar abierto te permite construir herramientas abiertas que trabajan codo con codo con él, así que adoptar el estándar te da la automatización casi gratis. La Data Contract CLI, open source (unas 900 estrellas en GitHub), lee el YAML, se conecta a todos los proveedores de datos habituales, ejecuta las comprobaciones y te devuelve un informe de tests que puedes llevarte a cualquier parte. También importa y exporta, así que llegas rápido a un contrato y sigues trabajando desde ahí.
Estándar y herramientas están fuertemente acoplados. La gráfica del historial de estrellas muestra a los dos subiendo juntos hacia las 1.000: la CLI fue por delante durante un buen tramo, ayudada por una reescritura de Go a Python (el mundo de los datos vive en Python), mientras que el estándar dibuja un palo de hockey al final. Al principio, un estándar sin herramientas no vale nada, porque tienes que construirlo todo tú; dale a la gente la automatización gratis y el estándar cuaja.
Un editor y el Excel de rigor
Como no todo el mundo domina YAML, también existe un Data Contract Editor open source con vista de formulario, vista de YAML con previsualización en vivo y vista de diagrama que funciona como una herramienta de modelado de datos.
Y el Excel de rigor. Simon esperaba librarse de él, pero la realidad no paraba de mostrar empresas montando sus propias hojas de cálculo para capturar contratos ODCS, así que el equipo construyó una con conversión automática de Excel a YAML. Resultó ser muy popular. Apuesta por el estándar y te llevas el editor, la plantilla de Excel y la automatización de la CLI como paquete. Si quieres que ganen los estándares abiertos, arrima el hombro en las herramientas, porque son las que impulsan la adopción, y la adopción es lo que empuja también a los proveedores a darles soporte.
El Open Data Product Standard
Los Data Contracts no hablan de productos de datos; un contrato es en realidad la interfaz, el conjunto de datos que compartes. Un producto de datos, tal y como lo ve Simon, puede exponer varios contratos en varias plataformas a la vez, y hay un estándar que le encaja bien: ODPS.
Un producto de datos apunta a un contrato por cada Output Port (lo que comparte) y por cada Input Port (aquello de lo que depende). En el ejemplo, un producto Orders tiene cuatro Output Ports: orders en versión 1 y en versión 2, más las variantes sin PII, porque los datos sin información personal son mucho más fáciles de conseguir, mientras que los ports sensibles quedan detrás de un proceso de aprobación manual que puede tardar semanas. Un Input Port referencia un topic de Kafka que un pipeline convierte en la oferta.
Como los ports apuntan a contratos, obtienes lineage a nivel de producto: un servicio de pedidos alimenta el producto Orders, que a su vez alimenta a otros consumidores. (Ver ¿Qué es un producto de datos?)
Lo que viene en Bitol
Un rápido levantar de manos: alrededor del 10 % de la sala ya usa ODCS. ODCS 3.2 aterriza pronto, ODPS 1.1 está en camino y el grupo de trabajo está redactando más estándares en torno a la observabilidad, los dominios de datos, los acuerdos de acceso y la orquestación.
Lleva su tiempo, apunta Simon. El comité no se reúne a menudo y todos hacen esto además del trabajo que de verdad paga las facturas.
Un aviso: hay dos cosas llamadas ODPS
Ojo con la confusión: hay dos estándares llamados ODPS, ambos en la Linux Foundation. Uno forma parte de la familia Bitol, funciona bien con ODCS a través de los Input Ports y puede referenciar varios contratos. El otro va por libre, no tiene el concepto de Input Port y se corresponde con un único ODCS.
Encarnan ideas genuinamente distintas de lo que es un producto de datos. El de Bitol es más flojo en precios e internacionalización; el otro es fuerte en planes de precios e i18n. Uno se llama Standard y el otro Specification. Es, admite Simon, una verdadera lástima.
Open Semantic Interchange
Los productos de datos aterrizan en un marketplace, que es adonde van los agentes a preguntar qué existe, así que esa capa también necesita estándares, o vuelves a los formatos de metadatos propietarios. El tercer estándar es la semántica: ¿qué significan los datos? Open Semantic Interchange (OSI), muy impulsado por Snowflake, empezó con el modelo semántico clásico: datasets, relaciones y, sobre todo, métricas. Tus datos ya están en Snowflake, Databricks, Oracle o SAP, y encima les pones una capa semántica.
Lo que llama la atención es lo AI-first que es. El formato lleva instrucciones, sinónimos y ejemplos, de forma que rellenarlos hace que los agentes funcionen mucho mejor: dale instrucciones a tus metadatos y los agentes sacarán más partido de ellos. Por lo demás se parece bastante a un contrato: describes datasets, relaciones y ahora métricas, por ejemplo total_revenue como la suma de los importes de los pedidos, o full_name como nombre más espacio más apellido.
Y, como en todas partes, hay herramientas open source, incluido un editor para modelarlo. (Más: Semántica.)
Los estándares aprenden unos de otros
ODCS y OSI son en realidad bastante parecidos. La comparativa muestra dónde va por delante cada uno: OSI gana en métricas, campos dinámicos y contexto de IA, mientras que ODCS cubre las condiciones de uso, la calidad y los SLAs.
Las diferencias se van cerrando a través de los comités. El contexto de IA llega en ODCS 3.2, junto con los campos dinámicos y las métricas como el ejemplo de full_name. Los estándares están creciendo juntos y aprendiendo unos de otros, y da gusto verlo.
Ontologías y un cambio de nombre a Apache Ossie
OSI tiene muchos grupos de trabajo, y uno especialmente activo sobre ontologías, que a Simon le gusta mucho. Todo está muy verde todavía (versión 0.2.0.dev), pero cuenta con un fuerte respaldo de Snowflake. Puedes modelar una ontología de conceptos y relaciones, con internacionalización, y enlazar la columna de un contrato con un concepto.
Un guiño para el público informático: llamar "OSI" a tu iniciativa cuando ya existe un famoso modelo de redes con ese nombre es una jugada atrevida. Parece que están de acuerdo, porque justo ayer donaron la iniciativa a la Apache Foundation y la rebautizaron como Apache Ossie. Hay muchos proveedores detrás, Entropy Data incluida, así que el formato viene en camino.
En directo durante la charla: el repositorio del Open Data Contract Standard supera las 1.000 estrellas.
Vamos a hacer historia
Aquí viene la parte que la sala puede hacer junta. Justo antes de la charla, el Open Data Contract Standard estaba en 978 estrellas de GitHub. Con 1.000 alcanza el siguiente nivel y puede graduarse dentro de la Linux Foundation. Así que esta es tu oportunidad: 22 estrellas, seguro que podemos con eso.
Y la sala lo hizo. Salieron los móviles, el contador fue subiendo en directo, 998, y luego por encima de la línea.
Lo conseguimos de verdad. En menos de cinco minutos, la comunidad de Bitol llevó al Open Data Contract Standard de 978 a más de 1.000 estrellas en GitHub, en directo desde la sala. Con eso queda superado el listón para que ODCS se gradúe dentro de la Linux Foundation. Gracias a todos los que escanearon el código QR y dieron su estrella. Juntos podemos mover montañas.
Si estos estándares te resultan útiles, dale una estrella al repo de ODCS y ayuda a que siga creciendo.
Gracias
Ese es el argumento: los productos de datos construidos sobre un stack de estándares abiertos, ODCS para los contratos, ODPS para los productos, OSI para la semántica, permiten que agentes y personas construyan y consuman datos de la misma forma. El futuro no está por llegar: está a un git clone de distancia.
Prueba tú mismo el marketplace de productos de datos basado en contratos en demo.entropy-data.com, escribe a Simon a simon.harrer@entropy-data.com o contáctalo en LinkedIn, y dale una estrella en GitHub a datacontract-cli si te ha servido.
Preguntas del público
Una selección de preguntas del público después de la charla.
P: ¿Están Data Mesh y los productos de datos por fin a punto de dar el salto en la era de la IA, ahora que la calidad de los metadatos es la palanca de verdad?
Esa es la tesis. Data Mesh se atascaba muchas veces en la política, en el vaivén de la centralización a la descentralización, y en contextos de BI a menudo no llegaba a despegar. Lo que ha cambiado es que antes la calidad de los metadatos no le interesaba a nadie; la gobernanza podía agitar todos los palos y todas las zanahorias que quisiera, y a nadie le importaba. Ahora le dices a un agente "adelante" y, con malos metadatos, produce basura con total seguridad, mientras que con buenos metadatos, impulsados por estándares, produce algo genuinamente útil. Eso crea un ciclo de realimentación real para preocuparse por la calidad de los metadatos. Los estándares no son una bala de plata ni una manguera que lo arregla todo, pero te empujan en la dirección correcta y ayudan a pasar de agentes mediocres a agentes buenos. Incluso algo tan pequeño como las instrucciones, los sinónimos y los ejemplos de OSI mejora de forma notable lo que produce un agente.
P: ¿No son los metadatos un producto competitivo para las grandes plataformas y una nueva forma de lock-in?
Sí, y justo por eso deberías apostar por los estándares abiertos. El éxito de los agentes lo deciden los metadatos, así que todos los grandes proveedores quieren que tus metadatos vivan con ellos. Ahora mismo se está formando un enorme lock-in de metadatos, y es todavía más fuerte si tus metadatos están en un formato propietario. Como cliente necesitas cierta posición de poder para negociar precios; si pueden decirte "pero si todos tus metadatos ya están aquí", estás atrapado. Así que controla tus metadatos, mantenlos en casa, quizá incluso en privado. Los metadatos en sí no son caros ni ocupan mucho; lo caro es el cómputo y la inferencia.
P: ODPS parece quedarse corto en lo que ocurre entre los Input Ports y los Output Ports. ¿Se va a estandarizar la lógica, o uso propiedades personalizadas?
Algo pasará ahí, pero ahora mismo no es el foco principal; el foco está en ODCS. Ya existe una parte al estilo bill of materials, la idea de la industria manufacturera de en qué consiste un producto, y hoy puedes modelar algo así, aunque no la he visto usar mucho. Lo importante es que con ODCS y ODPS tienes una especie de spec para tu agente de programación, y las skills hacen que construya productos conformes. Codificar "anonimiza esta columna" en el contrato, y cómo se hace la anonimización en las skills: el agente lo junta todo. Cuánto hay que describir de verdad es una pregunta abierta: quizá menos de lo que pensamos. Describe el objetivo y la calidad que quieres, no cada paso.
P: ¿Cómo evito un mantenimiento caro de los metadatos cuando el conocimiento de negocio está en manos de expertos de dominio que nunca van a escribir YAML?
Una respuesta es una ontología de dominio, capturada con el negocio en talleres, igual que rellenas un data product canvas. Los detalles técnicos y físicos son cosa de los ingenieros, pero aun así puedes llevar al negocio contigo en la discusión. No hay cura milagrosa. Lo que sí observo es que con la IA la burocracia duele menos: la IA automatiza las partes burocráticas, así que te llevas lo bueno sin que te desgaste como persona. La vieja objeción de que "los Data Contracts son demasiado esfuerzo" se ha reducido drásticamente. Una pequeña anécdota: puedes redactar el contrato de entrada con IA, dándole tus guías de lo que es un buen contrato más, por ejemplo, la transcripción de una reunión que tuviste una hora antes. Lo que sigue importando es que el artefacto exista como fuente de la verdad.
P: ¿Se usa esto ya en la práctica, con el agente construyendo la mayor parte y tú revisando y refinando?
Sí. Tenemos clientes en Estados Unidos usándolo de forma impresionante, contract-first: usan IA para redactar el contrato, se revisa, y después otro agente construye el pipeline. El artefacto decisivo es el contrato. Ahí es donde la gente se pone de acuerdo, donde está el bucle de revisión, donde entra la persona. Piensa en el contrato como una cómoda con cajones: en uno metes tus requisitos de calidad, en otro tu estrategia de anonimización o seudonimización, en otro tu clase de protección. Las personas llenan los cajones, el agente construye, y sigue habiendo sitio para las personas en el proceso, lo cual está bastante bien.