Data-first or Contract-first?

El ponente

Jochen Christ es un software engineer metido en datos que, en sus propias palabras, construye herramientas para que los datos, las personas y la IA trabajen juntos. Es co-founder y CTO de Entropy Data, autor del sitio Data Mesh Architecture, maintainer de la Data Contract CLI y miembro del TSC del proyecto Bitol de la Linux Foundation, hogar del Open Data Contract Standard.

Entropy Data es un marketplace de productos de datos construido sobre Data Contracts y semántica, con el objetivo de poner datos de alta calidad al alcance tanto de las personas como de los agentes.

¿Dónde empieza el viaje?

Una pregunta enmarca toda la charla: cuando te pones a construir un producto de datos, ¿cuál es tu punto de partida?

• Camino A, el tradicional: empezar por los datos. Te traes los datos de producción, los exploras, construyes un producto y después le defines el contrato.
• Camino B, la alternativa: empezar por el contrato. Acuerdas primero la interfaz con los Data Consumers, especificas el contrato y después lo construyes.

¿La segunda ruta es un rodeo, un atajo o simplemente otro camino hacia el mismo objetivo? Eso es lo que la charla se propone responder.

Usa los datos que ya tienes

Así es como los Data Engineers han trabajado toda la vida. Extraes datos de producción a tu plataforma de datos, los exploras para descubrir casos de uso y patrones, y construyes un dataset, un dashboard o un informe para publicarlo. Es el ritmo natural del data engineering y la analítica.

Tiene virtudes reales: creatividad (ves patrones y errores que jamás se te habría ocurrido pedir), velocidad (una consulta SQL te da un prototipo en minutos) y está anclado en la realidad, porque trabajas con los datos que existen de verdad.

Pero explorar por sí solo no es un producto

El problema del data-first es que lo que tienes todavía no es un producto. Cuatro pegas aparecen una y otra vez:

• Propiedad indefinida, la cuestión central del Data Mesh: ¿quién es dueño de este dataset a largo plazo?
• Sin documentación: una columna llamada TX021 es una marca de tiempo, ¿pero la fecha del pedido, la hora del pago u otra cosa?
• Todavía no listo para producción: sin reglas de calidad, sin comprobaciones, sin expectativas.
• Datasets técnicos enormes: copiar producción te deja tablas anchas y crudas por las que nadie sabe navegar.

El primer arreglo es poner los datos bajo contrato, lo que añade un cuarto paso al camino: testear.

¿Qué es un Data Contract?

Un Data Contract es un documento YAML que recoge quién es dueño de los datos, sus términos de uso, una descripción y su esquema, semántica, calidad y SLA.

Piénsalo como una especificación de API, pero para datos. Las APIs REST tienen OpenAPI, los mensajes y los topics de Kafka tienen AsyncAPI, y los datasets compartidos tienen el Open Data Contract Standard. La misma idea, otra interfaz.

El estándar: ODCS

El estándar de la industria para Data Contracts es ODCS, el Open Data Contract Standard, gobernado por el proyecto Bitol de la Linux Foundation. Un único archivo YAML contiene todo lo que necesita un consumidor:

• Fundamentos: nombre, versión, estado.
• Esquema: tablas y columnas con ejemplos, clasificaciones y etiquetas, así que es bastante más que un esquema SQL pelado.
• Calidad como código: reglas predefinidas como "el número de valores inválidos debe ser cero", o comprobaciones SQL arbitrarias que se ejecutan de verdad.
• Equipo: el owner del producto de datos y la información de contacto.
• Términos de uso: el propósito previsto y las limitaciones, por ejemplo "estos datos de pedidos no pueden usarse para marketing".
• SLA y servidores: las garantías y dónde viven realmente los datos.

Los términos de uso son seguramente la parte más importante: dicen para qué sirve el producto y para qué no debe usarse nunca.

Convierte el contrato en un test

Un contrato solo vale algo si puedes hacerlo cumplir. La Data Contract CLI, que es open source, lee el YAML, se conecta a tu producto de datos en Snowflake, Databricks, BigQuery, Postgres o donde viva, y convierte el esquema, las reglas de calidad y los SLA en sentencias SQL que ejecuta contra los datos reales.

Ejecuta datacontract test y obtienes un código de salida: cero es bueno, distinto de cero significa que algo se rompió. Métela en tu pipeline de despliegue, en un DAG de Airflow o en un job de Databricks para verificar, en cada cambio, que el producto en marcha sigue cumpliendo todas las garantías del YAML.

En la ejecución de CI de la diapositiva, 27 comprobaciones pasan y una falla, y detecta un desajuste de tipo: una columna que el contrato espera numérica es en realidad texto.

Hay más: publícalo

El Data Mesh va de compartir productos de datos más allá de las fronteras de los equipos, así que el camino gana un quinto paso: publicar. Ese mismo YAML se puede subir a una herramienta de metadatos, a un catálogo o a un marketplace como Entropy Data, y así el producto se vuelve fácil de descubrir, legible y accesible, en vez de ser solo un archivo YAML en crudo.

Y como son metadatos sobre un estándar abierto, los agentes también pueden leerlos. Pueden buscar en el marketplace y luego conversar con los datos o consultarlos de forma autónoma, siempre respetando los términos de uso definidos en el contrato, el propósito y las limitaciones, de modo que el acceso sigue siendo seguro.

Tres de cuatro, resueltos

Poner los datos bajo contrato arregla tres de los cuatro problemas: ahora hay un owner con nombre y apellidos, una interfaz acordada con documentación y tests de calidad ejecutables.

Lo que no arregla es el dataset técnico enorme. El data-first tiende a publicar lo que salió del sistema origen, así que sigues teniendo tablas anchas llenas de columnas parecidas donde nadie sabe cuáles le importan de verdad al negocio. Para resolverlo hay que cambiar el punto de partida.

Empieza con una conversación

El contract-first no empieza por los datos. Empieza por una conversación. Antes de mirar una sola columna, te sientas con tus Data Consumers y entiendes qué quieren hacer de verdad: un modelo de IA, un dashboard para el CFO, un caso de uso operativo. Después especificas esos requisitos como contrato, construyes el producto y lo testeas.

Escribir el contrato al principio es además la mejor documentación que vas a conseguir nunca, porque todavía te quedan ganas de escribirla. Nadie escribe buena documentación cuando el producto ya está publicado.

Los beneficios se acumulan: colaboración y empatía (sabes que alguien lo necesita de verdad), lenguaje de negocio (usas los términos del consumidor, no nombres crudos de columnas), expectativas reales (reglas de calidad que significan algo) y un producto de datos del tamaño justo, solo con los campos que hacen falta de verdad, que es justo lo que arregla el problema de los datasets enormes.

Que lo guíe el caso de negocio

Empiezas con un taller, idealmente presencial, con los stakeholders y el futuro Data Product Owner. Un data product canvas le da estructura: lo rellenas por la derecha, empezando por el caso de negocio, y dejas que eso guíe la interfaz y las fuentes que vas a necesitar.

El ejemplo que recorre la charla: Maxi, category manager en una empresa de e-commerce, quiere un inventario de los productos que no se han vendido en los últimos seis meses, los llamados shelf warmers que se quedan en el almacén acumulando polvo. "Shelf warmer" es el término del negocio, y ahí está la clave.

John, el product owner del equipo de ventas, responde con las preguntas que afinan el contrato: ¿qué cuenta como venta? ¿Cuentan las devoluciones? ¿Y las bajas de inventario o el stock robado? Esas respuestas se convierten en la semántica del contrato.

Recógelo donde el negocio pueda

El YAML en crudo no es accesible para los usuarios de negocio. Después de ver a tres clientes recoger contratos en Excel por su cuenta, el equipo publicó una plantilla Excel de ODCS oficial, más un conversor en la CLI entre Excel y YAML en ambos sentidos. Los product owners rellenan la hoja, la hacen circular y la convierten cuando están contentos.

Para los engineers, el Data Contract Editor open source convierte un contrato en una experiencia visual, con vistas de diagrama y de entidad-relación. Ya viene integrado en la CLI, así que datacontract edit <name> te abre el editor directamente.

Un contrato del tamaño justo

El requisito, una vez entendido, es diminuto. Maxi no necesita la tabla entera de pedidos ni la de stock. Necesita una tabla, shelf_warmers, con cuatro columnas: un SKU (el número de artículo), el nombre del artículo, una marca de tiempo de la última venta y, por convención de la organización, una marca de tiempo de procesamiento.

El trabajo que importa aquí es la semántica: dejar por escrito qué significa realmente "última venta". La descripción aclara que es la marca de tiempo del último movimiento negativo de stock, que puede incluir eventos que no son ventas, como bajas de inventario, y que es nula si el artículo nunca ha tenido una venta registrada. Esa frase es la diferencia entre un producto usable y un juego de adivinanzas.

Constrúyelo con un coding agent

Con el contrato especificado, toca construir, y hoy eso significa un coding agent (Claude Code, Codex, Copilot CLI). El agente necesita dos entradas. La primera es el YAML del contrato: qué construir. La segunda es cómo construye productos de datos tu organización, porque el agente no sabe si usas Snowflake, dbt o tus propias convenciones de nombres.

Ese "cómo" se entrega en forma de skills: instrucciones para el coding agent, guardadas en un repositorio git.

Skills: enséñale tu stack al agente

El dbt Data Product Builder, que es open source, es un repositorio plantilla que clonas y adaptas a tus convenciones. Cada skill no es más que un documento markdown con los pasos a seguir: una skill bootstrap para un producto nuevo, una skill implement para los cambios, más skills para metadatos y para testear.

Una skill puede, por ejemplo, definir cómo se mapea un campo de ODCS a un modelo de dbt, o llevar una plantilla de cómo es un proyecto dbt en tu organización, que el agente después respeta. La instalas desde el marketplace de plugins de tu agente y la conectas a tus metadatos y a tu proyecto dbt.

"Probar sale barato, así que puedes ir añadiendo más y más skills, y las skills pueden referenciar a otras skills."

La construcción

Toda la instrucción cabe en una línea: implementa el producto de datos del contrato. El agente lee el contrato, reconoce que es un producto nuevo, carga la skill bootstrap con su plantilla de dbt y se pone a trabajar en modo YOLO, montando los modelos dbt y el cableado de OpenLineage que prescriben las skills. En la charla se muestra como grabación de pantalla; en vivo la construcción tarda unos once minutos.

Y lo más importante: también usa el marketplace para encontrar sus fuentes aguas arriba. Para cumplir el contrato busca eventos de actualización de stock y datos maestros de artículos, encuentra esos productos de datos existentes y solicita acceso como parte del código generado.

El resultado

Unos once minutos después, el producto está construido: un proyecto dbt completo con Input Ports y Output Ports, la tabla SHELF_WARMERS poblada en Snowflake y el producto de datos publicado en el marketplace en modo privado, listo para que su owner lo haga público.

Los tests del contrato, que también forman parte de las skills, se ejecutan como un paso en CI o en tu pipeline de datos. Cuando el contrato está en verde, publicas. La implementación la hace un coding agent, pero los requisitos, la semántica y las garantías son tuyos.

Publica cuando los tests estén en verde

El contract-first recorre entender, especificar, construir y testear. Inviertes el tiempo al principio en entender y especificar los requisitos como contrato, el coding agent lo implementa, los tests del contrato se ejecutan en tu pipeline y, cuando están en verde, publicas.

No hay un camino equivocado

Las dos rutas llegan al mismo destino: un producto en producción que aporta valor. Entonces, ¿cuál es la respuesta? Tres conclusiones:

• Un contrato es lo que hace fiables a los datos. Recoge los requisitos y la semántica y automatiza el testeo, así que cuando algo rompería las expectativas de un consumidor, se pone en rojo y te avisa.
• Habla con tus stakeholders de datos. No hay atajo. Si no entiendes el valor de negocio de un producto de datos, probablemente no merezca la pena construirlo. Tómate en serio la propiedad del producto.
• Los coding agents implementan lo que especifiques. Cuanto mejor sean tu especificación y tus descripciones, mejor construye el agente y mejor puede señalar lo que falta o lo que no encaja.

"Los Data Contracts son los que marcan la diferencia. Son los que hacen que tu producto de datos sea fiable."