Data Architecture: The New Backbone of Modern Software

Dos ponentes

Gernot Starke es INNOQ Fellow, cofundador y maintainer de arc42, cofundador de aim42 y del iSAQB, y lleva muchísimos años haciendo arquitectura de software. Los datos siempre han formado parte de eso, incluso cuando el resto del sector dejó de hablar de ellos.

Simon Harrer es product engineer de vocación, coautor de "Java by Comparison" y "Remote Mob Programming", y cotraductor al alemán de "Data Mesh", de Zhamak Dehghani. Pasó años en INNOQ antes de cofundar Entropy Data como spin-off en 2025. Es co-maintainer de la Data Contract CLI y del Data Contract Editor, y forma parte del TSC del proyecto BITOL de la Linux Foundation, dedicado a los estándares abiertos de Data Contracts y productos de datos.

Datos frente a información

En IT todo el mundo conoce la diferencia, pero conviene repetirla. Los datos son ese montón desordenado de piezas de Lego en el cajón: símbolos aislados que por sí solos no significan nada. 42 o 07.05.2026 son solo valores.

La información son datos en contexto, con semántica. «La temperatura es de 42 °C» o «charla el 2026-05-07» ya son cosas sobre las que puedes actuar. Toda la historia de la arquitectura de datos consiste en convertir lo primero en lo segundo.

De la memoria de núcleos a los disquetes

La parte informática arranca en los años cincuenta con la memoria de núcleos: diminutos anillos de hierro ensartados en cables que se magnetizaban en un sentido o en otro para guardar un bit. Nada que ver con la energía nuclear (en alemán se llama «Kernspeicher», y «Kern» significa simplemente núcleo). Casi nadie en la sala había tocado una nunca.

En 1956, IBM lanzó el primer disco duro: una pila de platos magnéticos con 5 megabytes de capacidad y cerca de una tonelada de peso. Ya en los setenta, el casete compacto se reconvirtió en soporte de datos, con 300 a 400 kilobytes por cara, lo que hoy da para medio icono de una app.

Después llegaron los disquetes de 8, 5,25 y 3,5 pulgadas: flexibles, sensibles al polvo y con casi nada dentro. 80 kB en los primeros, hasta 2880 kB en los últimos. «Datenträger» (soportes de datos, literalmente «portadores de datos»), en el sentido más literal del término.

De los gigabytes al ángstrom

En los años dos mil, los discos de consumo se medían en decenas de gigabytes; a partir de 2010, los SSD llevaron ese mismo formato al terreno de los terabytes. Los discos de centro de datos actuales van por los 24 TB y subiendo, y son difíciles de comprar, porque cada unidad acaba desapareciendo dentro de algún hyperscaler.

Lo fascinante es en qué se ha convertido, sin hacer ruido, la industria del almacenamiento: en un vídeo divulgativo de Seagate que enseñó Gernot se habla de cabezales de lectura y escritura que vuelan sobre el plato con tolerancias del orden del ángstrom, tamaños moleculares. Los fabricantes de discos duros trabajan con el mismo nivel de precisión que las máquinas de litografía de ASML. Merece los cuatro minutos de vídeo.

El comercio como caso de uso de datos

Dejar constancia de las cosas ha sido siempre una necesidad básica de las civilizaciones. El comercio es un ejemplo claro. Los constructores de las pirámides egipcias ya llevaban listas de transacciones. Los comerciantes medievales anotaban lo que compraban y vendían con plumas doradas.

Luego alguien inventó la contabilidad por partida doble, que duplicaba a propósito los datos que un comerciante tenía que llevar, precisamente para reducir errores. Es, en el fondo, un sistema de calidad de datos. (Spoiler: esta idea va a volver.)

Hoy, en un grupo de retail moderno, los datos son el oro. Son lo que te permite negociar mejores condiciones de compra, repartir el stock entre tiendas y personalizar ofertas. Puedes tener algoritmos brillantes, cuadros de mando impecables y los mejores modelos de ML del mundo: si los datos que los alimentan son mediocres, lo que sale por el otro lado también lo será.

Reto n.º 1: la ingeniería de software se olvidó de los datos

La tesis es provocadora a propósito: entre 1995 y 2020, la ingeniería de software se olvidó en buena medida de los datos. Estábamos ocupados con otras cosas.

Hacia 1995, C++ se hizo mainstream, llegó Java y todo el mundo aprendió orientación a objetos: herencia, métodos, acoplamiento y cohesión. La cara funcional del software. En los ochenta, el término «modelo de datos» todavía era habitual; a finales de los noventa casi sonaba mal. Después vino SOA. Luego agile y Scrum (la palabra «datos» no aparece por ninguna parte en la Scrum Guide). Después los microservicios. Todo puesto en el comportamiento, nada en la forma de los datos que circulaban por en medio.

Gernot reconoce sin problema que estuvo justo en el centro de todo aquello. «Mit schuld» (corresponsable, cómplice). No se trata de pedir perdón, sino de darnos cuenta de dónde estamos saliendo ahora.

Reto n.º 2: los datos, el único activo sin dueño

Cualquier otro activo de una empresa tiene un dueño. Los datos, tradicionalmente, no. O más bien todo el mundo cree que son suyos, que es el mismo problema con otra cara.

El ejemplo favorito de Gernot viene de una aseguradora en la que trabajó durante la entrada en vigor del RGPD. Tenían una alegre costumbre de «la dirección para todos»: cada vez que alguien mostraba interés por un producto, su dirección se reenviaba a todos los destinatarios internos que pudieran quererla. Luego llegó el RGPD, «Sylvia» pidió que la borraran y nadie pudo decir con honestidad dónde habían acabado sus datos. Los registros de direcciones no tenían dueño.

Al estado resultante lo llama, con permiso, «Wildwuchs» (crecimiento salvaje, descontrolado). Datos hay de sobra, pero nadie sabe qué copia es la buena, si sigue siendo válida ni si tiene el número correcto de decimales.

Reto n.º 3: imágenes bonitas sobre un pantano

Los data warehouses clásicos producen informes preciosos. El problema es que muchas veces llegan demasiado tarde y están construidos sobre datos malos. Gernot ha estado en muchas reuniones en las que alguien sacaba un Excel de la era de las torres de sobremesa y soltaba: «pues a mí me salen otros números».

Eso es shadow IT, y aparece justo donde la fontanería central de datos ha dejado tirada a la gente. Los data lakes heredaron el mismo problema a mayor escala: mete todo dentro a paladas y espera que salga algo bueno. La esperanza es maravillosa, pero como estrategia de datos deja mucho que desear.

La ola de la IA hizo imposible seguir mirando para otro lado. En cuanto una empresa decidía hacer fine-tuning de su propio modelo y salía a buscar datos de entrenamiento, la respuesta solía ser: tenemos muchísimos datos, pero no sabemos cuáles son correctos. Un modelo entrenado sobre un pantano no es inteligente. Es un pantano.

Esto ya lo hemos resuelto antes

En realidad ya hemos estado en un lío parecido. El «caos de servicios» de los años dos mil se parecía mucho: SOAP/WSDL era pesado, REST era ligero pero no tenía contrato, la documentación vivía en Confluence cuando existía y el ESB era el cuello de botella. Nadie sabía a ciencia cierta qué servicios tenía.

Lo que nos sacó de ahí fue Swagger y después OpenAPI. Un único formato de texto plano, legible por máquinas y neutral respecto al proveedor. Con diez líneas de YAML ya empiezas. Swagger UI te da recompensa inmediata. Como dice Gernot, y usa la expresión con cuidado, aquello fue un auténtico game-changer para la forma en que los equipos producen y consumen servicios.

Ahora esa misma idea tiene que llegar al mundo de los datos.

Toda empresa ya tiene API de datos

REST tiene OpenAPI. Los mensajes y eventos tienen AsyncAPI. ¿Y los conjuntos de datos compartidos?

Porque la verdad es que toda empresa ya tiene decenas de «API de datos». Lo que pasa es que no parecen API. Parecen esto:

• CSV en un SFTP
• Archivos JSON en S3
• Tablas SQL en BigQuery o Snowflake
• Archivos Iceberg en Azure One Lake
• Delta Live Tables en Databricks
• Archivos de Excel en SharePoint

Un equipo produce y otros consumen. Cuadros de mando, informes para el comité de dirección, entrenamiento de modelos y pipelines aguas abajo dependen de que esas interfaces sean estables y de calidad. Y cuando el pipeline que produce cambia en silencio una cabecera de CSV o vacía una columna, el cuadro de mando simplemente enseña otro número. Sin error, sin alerta: el peor modo de fallo posible.

¿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 especificación de API, pero para datos.

El productor es dueño del contrato y declara las garantías. El consumidor lo lee y confía en él. Sin contrato, los consumidores acaban haciendo ingeniería inversa del esquema mirando filas de ejemplo y adivinando que OID2 es el número de pedido, cuando podría ser cualquier otra cosa. Esas lecturas equivocadas y silenciosas son dificilísimas de detectar.

De los formatos a medida a un estándar

Cuando apareció la necesidad, cada empresa se inventó su propio formato. Unos en YAML, otros en JSON, otros en Excel e incluso en documentos de Word. Todos intentaban codificar lo mismo: qué significa cada campo, cuál es su calidad, cuál es el SLA y cuáles son las condiciones de uso.

PayPal liberó su plantilla interna y la donó a la Linux Foundation como ODCS 2.2. Simon entró en el TSC y ayudó a quitar todo lo específico de PayPal para que cualquier empresa pudiera usarla. ODCS 3.0, publicada en 2025, fue la primera versión realmente neutral.

Hoy vive en BITOL, el proyecto de la Linux Foundation para los estándares abiertos de Data Contracts y productos de datos, con un equilibrio sano entre usuarios finales, consultores y proveedores dentro del comité. Ese tipo de gobernanza es lo que hace que «estándar» signifique algo y no sea solo una palabra de marketing.

Qué hay dentro de un contrato ODCS

Un único archivo YAML recoge todo lo que necesita un consumidor:

• Fundamentos: id, nombre, versión y estado (para el ciclo de vida).
• Esquema: tablas y columnas con tipos lógicos y físicos, claves primarias y foráneas, nombres de negocio ("Customer Identifier"), clasificaciones y etiquetas de PII.
• Calidad de datos: enums (order_status ∈ {pending, shipped, cancelled}) o SQL libre («el número de filas debe superar las 100.000»). Y algo clave: se expresa en porcentajes, no como obligatorio u opcional a secas, porque los datos reales son sucios y a un modelo de ML le vale de sobra con un 99 % de completitud.
• Equipo y soporte: owners, canales de Slack, sistemas de tickets.
• Condiciones de uso: qué pueden y qué no pueden hacer los consumidores con los datos (ámbito geográfico, garantías de ausencia de PII, limitación de finalidad).
• SLA: disponibilidad, retención, frescura y latencia. En el mundo de los datos, la latencia y la frescura importan mucho más que el uptime de la plataforma (Databricks, Snowflake o BigQuery simplemente están arriba).
• Servidores: dónde viven realmente los datos, para que un consumidor autorizado pueda conectarse directamente.

«Hacer explícita la propiedad es el gran paso. Lo implícito era esto: los productores daban por hecho que la estructura y la semántica tenían que evolucionar, y los consumidores asumían que se quedarían congeladas para siempre. Ese desajuste es la razón por la que se rompen los pipelines.»

Automatízalo todo

En cuanto un contrato es YAML, puedes hacer muchísimo con él: generar modelos Java, Pydantic, dbt o DDL de SQL, compararlo con los datos reales, tumbar un pull request cuando hay cambios rompedores, monitorizar de forma continua en producción y enviar metadatos a catálogos de datos (Colibra), marketplaces (Entropy Data) y catálogos de software (LeanIX).

La Data Contract CLI, que es open source, hace el trabajo pesado: importa desde DDL de SQL, JSON Schema, Iceberg, Protobuf, BigQuery, Unity Catalog, AWS Glue y Excel; exporta a DDL de SQL, HTML, dbt, Entropy Data, Avro, SodaCL, Pydantic y Excel; y ejecuta tests contra AWS S3, BigQuery, Azure, Databricks, Snowflake y Kafka.

«Las comprobaciones de calidad antes eran invariantes escondidas en nuestro código. Ahora viven junto a los datos, en el contrato, y se ejecutan de forma continua.»

El tooling importa más que el estándar

Si miras las estrellas de GitHub, la Data Contract CLI es más popular que la propia especificación de ODCS. Es otra vez la lección de OpenAPI: los estándares abiertos necesitan buen tooling open source para que la gente los adopte.

El estándar es lo que te regala ese tooling, lo que te evita el lock-in cuando varias herramientas soportan el mismo formato y lo que hace que los equipos se ayuden entre sí en lugar de reinventar el mismo YAML diez veces con diez variantes distintas.

Editores para personas (y para perfiles de negocio)

Escribir YAML a mano es tedioso, así que construimos el Data Contract Editor, también open source. Vista de diagrama, vista de formulario y vista de YAML en crudo, con previsualización y validación. Está integrado con la CLI, así que mientras editas puedes relanzar los tests contra los datos y ver si el contrato se sigue cumpliendo.

Para los compañeros que no quieren aprender ninguna herramienta nueva, existe además una plantilla de Excel para ODCS. La CLI la convierte a YAML. No es bonito, pero es práctico, y Excel no se va a ir a ninguna parte.

Demo en directo: editor y CLI sobre una base de datos real

El editor de editor.datacontract.com pinta un contrato con orders y line_items en forma de diagrama, con una clave foránea que las une. Cada campo tiene tipo lógico y físico, ejemplos ("C-10000001"), clasificaciones (interno, PII) y una descripción entendible para negocio (SKU → Stockkeeping Unit).

El editor está conectado a una base de datos Postgres alojada en Supabase. Al pulsar Run Test, lanza sondas SQL a través de la CLI y devuelve un informe en verde: todos los campos del esquema esperado están presentes y bien tipados, order_status no tiene valores inválidos y el número de filas supera con creces las 100.000 que exigía el contrato.

Todo lo que puedas expresar en SQL se convierte en una comprobación de calidad. Y todo lo que puedas expresar se convierte en un test continuo.

Dónde encajan los Data Contracts en el panorama general

Los Data Contracts encajan de forma natural con Data Mesh: propiedad por dominio, datos como producto, plataforma self-service y gobernanza federada. Los equipos de dominio construyen productos de datos que consumen los contratos de otros productos de datos y publican otros nuevos. Es la mentalidad de API que ya aplicamos a los servicios (pensar en producto, en plataforma, en gobernanza) llevada ahora a los datos.

No hace falta implantar Data Mesh para usar Data Contracts. El mínimo son dos equipos: uno que produce datos y otro que los consume. Data Mesh encaja muy bien, pero no es un requisito previo.

La verdadera razón por la que ganarán los Data Contracts: los agentes de IA

El agentic coding es la parte pequeña y visible. El premio gordo son los agentes hablando con los datos de la empresa. Y un agente no sabe por sí solo qué significan tus tablas, cómo de frescos son los datos, si se pueden usar para marketing ni cómo pedir acceso.

El contrato les da todo eso: semántica, condiciones de uso, acceso, calidad y SLA. Acuérdate de la diapositiva de datos frente a información: el contrato es justo la capa que convierte datos en bruto en información sobre la que un agente puede razonar.

Sin contratos, los agentes acaban adivinando y cruzando con total seguridad las columnas equivocadas. Con contratos, tienen metadatos sólidos sobre los que trabajar. Esa es la apuesta.

Demo en directo: un agente sobre la capa de contratos

El mismo montaje, una capa más arriba. Un agente (Claude Opus) está conectado al MCP server de Entropy Data, que expone el marketplace de datos: productos de datos buscables, cada uno con su contrato ODCS.

Un usuario de negocio pregunta, en alemán: "Wer sind meine Top-Kunden?" («¿quiénes son mis mejores clientes?»). El agente busca en la oferta de datos usando los metadatos de los contratos, elige el producto de datos que puede responder a la pregunta, comprueba si hay acceso (y solicitaría uno automáticamente si no lo hubiera), ejecuta SQL y devuelve una tabla con el top 10: nombre, facturación, categoría de producto preferida y método de pago. Luego llega la repregunta: "und für welche Produkte?" («¿y para qué productos?»), y el agente sigue tirando del hilo, contando con transparencia qué ha encontrado y qué no.

Lo importante no es que el agente sea listo. Lo importante es lo que hace posible el contrato: que la gente de negocio formule hipótesis directamente, en lugar de abrir un ticket y esperar semanas a que un equipo de datos construya un cubo.

La predicción

Swagger 1.0 apareció en 2011. Al principio ni siquiera tenía esquemas, solo endpoints. Hoy cualquier API REST que toques tiene su especificación OpenAPI.

ODCS 3.0, la primera versión realmente neutral, salió en 2025. La apuesta: dentro de cinco años estará donde hoy está OpenAPI. Y ahora las cosas van más rápido que en 2011.

El coste de entrada es bajo. Cualquier editor de texto, diez líneas de YAML y la CLI open source bastan para validar si encaja en tu caso de uso. Puedes anticiparte en lugar de ir a remolque.