Open Standards for Data Mesh

Presentación

Gracias por la invitación, Tom. Es la primera vez que estoy en Lovaina y de momento va genial. Me llamo Simon y soy software engineer de corazón. Trabajé siete años en una consultora y desde agosto de 2025 soy Co-Founder y CEO de Entropy Data, donde construimos un marketplace de productos de datos. Tenemos clientes en siete países, entre ellos Estados Unidos, Australia y Bélgica.

Además soy coautor de "Java by Comparison", de mi época Java (ahora Claude programa por mí), y cotraduje al alemán el libro "Data Mesh"; lo mejor es que en la edición alemana las imágenes salen en color. Coescribo datamesh-architecture.com y datacontract.com, comantengo la Data Contract CLI y el Data Contract Editor, ambos open source, y formo parte del TSC de BITOL, el proyecto de la Linux Foundation que impulsa los estándares abiertos de Data Contracts y productos de datos. De hecho, hoy mismo hemos tenido la reunión del TSC en la oficina de Tom, una forma estupenda de empezar la tarde en persona.

Un repaso rápido a Data Mesh

Esto es un meetup de Data Mesh, así que seguramente ya lo sabes: un repaso muy corto solo para partir de la misma base. Data Mesh, término acuñado por Zhamak Dehghani, se apoya en cuatro principios: propiedad por dominio, datos como producto, plataforma de datos self-service y gobernanza federada.

La arquitectura típica tiene la plataforma self-service abajo, la gobernanza federada arriba y un enabling team al lado que ayuda a los demás. En el centro están los dominios, con sus equipos construyendo productos de datos para que otros los usen.

Cuando un equipo construye un producto de datos solemos usar el Data Product Canvas, open source, que creé en mis años de consultoría como plantilla de Miro. Los Input Ports vienen de sistemas fuente o de otros productos de datos. Los Output Ports ofrecen datos, vía un Data Contract, a consumidores con casos de uso concretos. En el medio está la implementación: procesamiento, framework, motor de consultas, almacenamiento, planificación, coste. Muchos de estos productos, juntos, forman el grafo del mesh.

¿Qué es un estándar? ¿Y para qué los necesitamos?

En vez del diccionario de Oxford, prefiero mirar XKCD. Las mil formas de escribir una fecha dieron lugar al estándar ISO 8601: todo el mundo gana cuando lo usa (menos Estados Unidos, como apunta XKCD). Las distintas maneras de contar, "uno, dos, tres, ya" frente a "tres, dos, uno, ya", generan la misma confusión y el mismo coste, y por eso los estándares abaratan las cosas. Y luego está el clásico de XKCD "How Standards Proliferate": tienes catorce estándares, creas uno universal que lo cubra todo y ahora tienes quince. Ese es justamente el problema de los estándares.

Déjame aclarar de qué estoy hablando hoy. Los estándares que me interesan son:

• De facto, no de iure: los impulsa el uso real en una masa crítica de empresas, no una ley.
• De una iniciativa, no de un fabricante: los mantiene una iniciativa abierta, no los controla una sola empresa. Si lo dicta un único proveedor, no es un estándar.
• Muchos contribuidores, no uno: se trata de repartir el poder y el control.
• Abiertos, no detrás de un muro de pago: usables libremente. (Estamos certificados en ISO 27001, y pagar 130 francos suizos por un PDF de 10 páginas es exactamente la fricción que los estándares abiertos evitan.)

En un Data Mesh se podría estandarizar casi todo: monitorización, catálogos, consultas, almacenamiento, políticas, analítica, relaciones. Yo me voy a centrar en los tres que más importan ahora mismo.

¿Qué es un Data Contract?

Un Data Contract es un documento que define la propiedad, la estructura, la semántica, la calidad y las condiciones de uso para intercambiar datos entre un productor y sus consumidores. Piensa en una API, pero para datos.

El contrato es lo que crea la confianza. El productor es su dueño; el consumidor lo lee y confía en él; entre los dos acuerdan los datos que van a fluir.

"El contrato es, por definición, correcto. Cuando los datos y el contrato no coinciden, los datos están mal. Así de fuerte es esa capa de confianza, al menos conceptualmente."

La gran fusión de formatos de Data Contract

Como esta necesidad surgió con el auge de Data Mesh y de los datos descentralizados, al principio cada empresa se inventó su propio formato. PayPal creó su plantilla interna, la liberó como open source y la donó a la Linux Foundation como ODCS 2.2. En paralelo, nosotros construimos por aquel entonces nuestra propia Data Contract Specification (DCS), que se usó mucho gracias al tooling que había a su alrededor, sobre todo la Data Contract CLI.

Como me gusta lo abierto, me uní al TSC y sacamos ODCS 3.0, quitando lo específico de PayPal y dejándolo utilizable para cualquier empresa, porque PayPal solo hay uno. El año pasado deprecamos nuestra propia Data Contract Specification en favor de ODCS y trasladamos todos nuestros recursos ahí. El control importa: ser uno más entre muchos miembros de un comité, con buen equilibrio entre usuarios finales, consultores y fabricantes, es mucho más sano que un proyecto de un único proveedor, por muy abierto que sea. ODCS 3.2 está al caer; en la reunión del TSC de hoy acabamos de aprobar unas cuantas incorporaciones.

Qué hay dentro de un contrato ODCS

ODCS tiene muchos bloques con los que un productor puede describir lo que ofrece. Un solo fichero YAML recoge:

• Fundamentos: ID, nombre, versión y estado para ir introduciendo o retirando lo que ofreces.
• Esquema: tablas y columnas con sus tipos, claves primarias y foráneas, nombres de negocio, clasificaciones y etiquetas de PII. Aunque tus datos vivan como JSON en S3 o como CSV por SFTP, puedes declarar igualmente las relaciones, porque técnicamente están ahí.
• Calidad de datos: enumerados del tipo order_status ∈ {pending, shipped, cancelled}, o comprobaciones SQL arbitrarias como "el número de filas debe superar las 100.000".
• Equipo y soporte: cómo llegar a los owners, canales de Slack, sistemas de tickets.
• Condiciones de uso: qué pueden y qué no pueden hacer los consumidores con los datos.
• SLAs: frescura, retención, disponibilidad, todo ello medible por herramientas.
• Servidores: dónde viven realmente los datos, para que quien tenga acceso vaya directo.

El estándar define la estructura del YAML y qué puedes expresar. Todo lo que viene después se construye encima de eso.

Automatízalo todo

Una vez que tienes el YAML puedes automatizar: comparar el contrato con los datos reales, detectar cambios incompatibles en una PR, monitorizar producción de forma continua, generar Java, Pydantic, modelos dbt y SQL DDL, y llevar los metadatos a metastores, a catálogos como Collibra, a marketplaces como Entropy Data y a catálogos de software como LeanIX. La Data Contract CLI hace todo esto: se conecta a Snowflake, Databricks, BigQuery, lo que sea, y produce un informe de hasta qué punto los datos cumplen lo prometido. Por dentro usamos Soda Core para ejecutar las comprobaciones de calidad, otro proyecto open source de una empresa belga, algo que aquí en Lovaina viene muy al caso.

Y si miras el histórico de estrellas en GitHub, la Data Contract CLI es más popular que la propia especificación ODCS. Esa es la lección: el tooling importa más que el estándar. El estándar existe porque te regala ese tooling, porque te evita el vendor lock-in cuando varios fabricantes soportan el mismo formato y porque así nos ayudamos entre todos en vez de reinventar diez veces lo mismo.

Un contrato es además los mejores metadatos que le puedes dar a una IA. Si combinas IA con metadatos estructurados así, sobre todo con los modelos actuales de la clase Opus, el límite lo pones tú.

Editores para humanos (y para gente de negocio)

Escribir YAML a mano da mucho trabajo, así que construimos el Data Contract Editor. Permite rellenar contratos con una vista de formulario, una vista de diagrama o el YAML en crudo, con vista previa y validaciones incluidas. Y lo más importante: aquí es donde negocio y técnica se encuentran. Negocio piensa en columnas y entiende los datos; técnica completa los detalles físicos que faltan. Muchas veces empieza negocio y termina técnica.

Y para la gente todavía más de negocio creamos una plantilla de Excel para ODCS. Tiene un éxito sorprendente. La CLI la convierte al YAML correspondiente y sigue procesándola.

Estándar abierto + editor open source + tooling de automatización + plantilla de Excel: ese paquete lo tienes gratis, sin muro de pago, solo úsalo.

El Open Data Product Standard (ODPS)

Los contratos son una pieza clave. Los productos de datos son la otra. El Open Data Product Standard (ODPS), del proyecto BITOL, refleja a ODCS en fundamentos, condiciones de uso, equipo, soporte y propiedades personalizadas. La diferencia clave: Input Ports, Output Ports y puertos de gestión. Cada puerto enlaza con un Data Contract en ODCS.

Como ODPS se apoya en ODCS, si ya tienes contratos el fichero del producto de datos es cortísimo. Uno típico tiene nombre, descripción, versión y unos pocos puertos: por ejemplo, un Input Port de Kafka en v1 y cuatro Output Ports de Snowflake para datos con y sin PII en v1 y v2. Ya está. Todos juntos forman el grafo de tu Data Mesh.

Del YAML a un grafo vivo del mesh

Como cada producto de datos declara sus Input Ports y Output Ports en ODPS, y cada puerto referencia un contrato ODCS, te sale gratis un grafo de dependencias completo. Las aplicaciones fuente alimentan a los productos de datos; los productos de datos alimentan a otros productos de datos o directamente a casos de uso como la analítica de embudo, los informes mensuales de objetivos o la clasificación de usuarios en tiempo real.

De eso va todo esto: el estándar es lo que hace posible el grafo. Visualízalo y tienes el mapa de tu Data Mesh, derivado íntegramente de los ficheros YAML de contratos y productos, no dibujado a mano.

Pero ojo cuando se lo preguntes a Claude

Aquí hay una confusión real. Dos proyectos distintos de la Linux Foundation comparten el mismo acrónimo: ODPS es a la vez "Open Data Product Standard" (el que te estoy contando, parte de BITOL) y "Open Data Product Specification" (un proyecto aparte). Cuando busques, o cuando le preguntes a Claude, tienes que saber cuál de los dos estás leyendo.

Los modelos mentales son distintos. El Standard de BITOL modela productos de datos con varios Input Ports, varios Output Ports y enlaces a muchos contratos ODCS: está diseñado como una familia de estándares componible. La Specification no tiene concepto de Input Port y permite como mucho un contrato enlazado en el nivel superior; es fuerte en planes de precios e internacionalización, lo que la hace mejor opción si gestionas un marketplace externo con condiciones comerciales complejas.

Ninguno está mal: simplemente resuelven problemas distintos con el mismo nombre. Yo estoy en el bando de BITOL porque me interesa que la familia de estándares componga bien entre sí. Ese es mi sesgo; el tuyo puede ser otro.

Qué viene en la familia BITOL

Hoy los estándares centrales son ODCS 3.1 y ODPS 1.0. Las versiones menores de este año se centran sobre todo en añadir más contexto para IA, es decir, metadatos que los agentes puedan usar para descubrir datos y generar consultas.

Alrededor del núcleo estamos redactando estándares auxiliares: OORS para resultados de observabilidad (¿qué pinta tiene el resultado de una comprobación de calidad?), OAAS para acuerdos de acceso y flujos de solicitud, ODDS para dominios de datos, ODMS para Data Mesh y OOCS para orquestación y control. El núcleo sigue siendo el núcleo; los auxiliares cubren los bordes que todo marketplace tiene que codificar de alguna forma.

Open Semantic Interchange (OSI)

Otra vez tenemos choque de acrónimos: OSI es también el modelo de capas de red que estudiaste en la carrera. Este OSI es el Open Semantic Interchange, una iniciativa impulsada por Snowflake junto a muchas otras empresas. Va por la versión 0.1.1 y no es estable todavía, y así lo dicen, pero los grupos de trabajo están muy activos.

La idea central: encima de tus productos de datos y de tus contratos construyes un modelo semántico con datasets, relaciones y métricas, parecido al modelo semántico de Power BI. Y luego OSI le echa por encima "azúcar para IA": instrucciones, sinónimos y ejemplos para que los agentes de IA y las herramientas de BI trabajen bien con los datos.

Comparado con ODCS, los dos se solapan en datasets, relaciones y extensiones propias. OSI añade métricas (por ejemplo, total_revenue = SUM(order_total)) y campos dinámicos (por ejemplo, full_name = first_name + " " + last_name). ODCS tiene lo que a OSI hoy le falta: condiciones de uso, comprobaciones de calidad y SLAs. El solape interesante es el contexto para IA: todo el mundo lo quiere y es ahí donde ambos están evolucionando.

Los grupos de trabajo de ontología, componibilidad y tooling están todos activos. Mi colega y co-founder Jung también está muy metido ahí. Este es de los que hay que seguir de cerca.

Un editor para modelos semánticos

Como un modelo OSI se parece bastante a un contrato (tablas, claves foráneas, relaciones), le construimos también un pequeño editor open source, disponible en editor.opensemantic.com (código en GitHub). Mismo patrón que el Data Contract Editor: vistas de diagrama, formulario y YAML, con vista previa y validación.

Siendo sincero, Claude Code nos construyó la mayor parte en una tarde. Eso hoy es posible precisamente porque el formato de debajo es un estándar abierto que el modelo ya conoce.

Y mucha fuerza detrás

OSI sigue en la 0.1.1, pero los grupos de trabajo que hay detrás van muy en serio:

• Métricas avanzadas y lenguaje de expresiones: más allá de lo básico que has visto arriba.
• Componibilidad: cómo se referencian y se componen entre sí los modelos OSI.
• Integración con catálogos: enganchar con la capa de catálogo de datos de la empresa.
• Representación de ontologías: conceptos y propiedades como grafo. Aquí está muy metido mi co-founder Jochen Christ.
• Conversores de modelos y herramientas para desarrolladores: donde de verdad se construye la historia del ecosistema.

Si miras la lista de miembros (Snowflake, Databricks, Tableau, MicroStrategy y muchos más), hay mucha fuerza detrás de esto. Merece la pena seguirlo.

El panorama completo

Hoy he cubierto ODCS, ODPS y OSI, pero el mapa es mucho más grande: interfaces de API (OpenAPI, AsyncAPI, GraphQL), esquemas (XML, JSON, SQL DDL, Avro), formatos de fichero (CSV, JSON, Parquet, Avro, ORC), formatos de tabla abiertos (Iceberg, Delta, Hudi), APIs de catálogo (Iceberg Catalog, Unity Catalog, Hive Metastore), linaje (OpenLineage), políticas (OPA), observabilidad (OpenTelemetry, OORS), calidad de datos (dbt, Great Expectations, SodaCL) y semántica (OSI, además de RDF/OWL, DCAT, SKOS, SHACL).

Lo que une a los que he destacado: son abiertos, no los controla una sola empresa, los respalda un comité y tienen tooling open source alrededor. Un Data Mesh se construye sobre muchos estándares, y vienen más.

La predicción

Swagger 1.0 salió en 2011. Hoy OpenAPI está en todas partes: cualquier API REST que toques lo lleva. Un 99% de adopción, de facto.

ODCS 3.0, la primera versión que no arrastra las particularidades de PayPal y la primera realmente utilizable por cualquier empresa, salió en 2025. Mi hipótesis es que esto irá mucho más rápido que OpenAPI, porque el mundo va mucho más rápido ahora.

Mi predicción: dentro de cuatro años ODCS estará en todas partes. Ve preparándote.