Data product

¿Qué es?

Un data product (producto de datos) es un activo de datos tratado con la misma disciplina con la que se gestiona un producto de software: tiene un equipo dueño responsable, una documentación clara, un contrato con sus consumidores, un SLA medible y un ciclo de vida explícito. No es solo una tabla en el data warehouse: es esa tabla más todo lo que la rodea para que se pueda usar con confianza por equipos externos al que la produce.

El concepto se popularizó con la propuesta de data mesh de Zhamak Dehghani (2019) y desde entonces ha sido adoptado, con variaciones, por organizaciones de cualquier tamaño que buscan profesionalizar la entrega de datos.

Las propiedades que distinguen un data product de un dataset

Zhamak Dehghani propuso un conjunto de propiedades observables (las “DATSIS” en algunas formulaciones, simplificado aquí) que deben cumplirse para hablar de data product:

• Discoverable (descubrible): existe en un catálogo donde otros equipos pueden encontrarlo.
• Addressable (direccionable): tiene una URI o identificador único estable.
• Understandable (comprensible): documentación clara del esquema, semántica y reglas de negocio.
• Trustworthy (confiable): SLA explícitos de frescura, calidad y disponibilidad.
• Interoperable (interoperable): formato y vocabulario consistentes para integrarse con otros productos.
• Secure (seguro): control de acceso y gobernanza explícitos.
• Natively accessible (accesible nativamente): se consume con las herramientas habituales del sector (SQL, API REST, Iceberg, Kafka topic, etc.), no con conectores ad hoc.

Si un dataset cumple estos requisitos, es un data product. Si no, es un dataset y conviene no llamarlo de otra forma.

Por qué importa la distinción

Antes del enfoque “data-as-a-product”, los datos en las organizaciones tendían a un patrón conocido:

• El equipo de datos central producía tablas para los analistas internos.
• Cuando otro equipo quería usar esas tablas, hacía screenshots de SQL o copiaba el modelo a mano.
• Cualquier cambio en origen rompía cosas en sitios que nadie sabía que existían.
• La calidad y la frescura eran “esfuerzo razonable”, no compromisos verificables.

El enfoque data product cambia las expectativas: si el equipo A publica clientes_unificados como producto, el equipo B puede construir su dashboard sobre él con la misma confianza con la que un equipo de software construye sobre una API de Stripe o de Twilio. Hay contrato, hay SLA, hay versionado, hay deprecación anunciada.

Cómo se materializa en la práctica

Construir un data product implica varias decisiones explícitas:

• Definir el contrato (data contract): esquema, tipos, semántica, política de cambios.
• Asignar dueño: persona o equipo responsable, con tiempo asignado al mantenimiento.
• Documentar el caso de uso primario: para qué se diseñó. Otros casos pueden funcionar pero no son contractuales.
• Publicar SLA: frescura (cada X horas), disponibilidad (% del tiempo), calidad (porcentaje de filas que cumplen reglas).
• Versión y deprecación: cuando el esquema cambia, hay un proceso anunciado para que los consumidores se adapten.
• Métricas de uso: el equipo dueño sabe quién consume y para qué, y puede priorizar mejoras.

Ejemplo

Una empresa de comercio electrónico decide publicar producto_canonico como data product del equipo de catálogo:

• Identificador: s3://lake/products/canonical/iceberg/v2/
• Esquema: 47 columnas documentadas (SKU, nombre, marca, atributos jerárquicos, precios por mercado, disponibilidad).
• Dueño: equipo de catálogo. Responsable: Marta López. Slack: #data-product-catalog.
• SLA: actualización máxima cada 30 minutos; disponibilidad mensual 99,5 %.
• Contrato: cualquier cambio breaking se anuncia con 60 días de antelación. Cambios aditivos pueden ocurrir en cualquier release.
• Consumidores conocidos: e-commerce frontend (vía Kafka mirror), reporting financiero (vía Iceberg directo), modelo ML de personalización (Feature Store derivado), DAM (vía API REST).

Cuando el equipo de pricing necesita información de productos, no construye su propia tabla. Consume producto_canonico. Si necesita extender campos específicos para pricing, construye su propio data product que referencia al de catálogo como dependencia explícita.

Diferencia con un data product comercial (producto que se vende)

El término “data product” se usa también para describir productos comerciales basados en datos (un dashboard SaaS, un modelo de ML como servicio, un API que sirve enriquecimiento). En el contexto interno organizativo, el significado es el descrito arriba: un activo de datos producido y consumido internamente con disciplina de producto. Ambos usos coexisten y el contexto suele aclararlo.

Tecnologías y prácticas que lo soportan

• Catálogos modernos: Atlan, OpenMetadata, DataHub publican data products como entidades de primera clase.
• Data contracts: herramientas como dbt contracts, Soda Contracts, Schemata permiten codificar el contrato.
• Plataformas data mesh: Confluent (para productos de streaming), Snowflake Sharing, Databricks Unity Catalog facilitan la publicación de productos federados.
• Disciplinas asociadas: DataOps, observabilidad de datos, gobernanza activa.

Más información

• Data mesh — la propuesta organizativa donde nace el concepto
• Data contract — el contrato que define el data product
• Data fabric — la pieza tecnológica complementaria
• Guía de arquitectura de datos — la guía completa de Dataprix, con el índice de todos los capítulos.