En resumen
Un data product no es un dataset con mejor documentación. Es un activo de datos gestionado como cualquier producto de software: con propietario accountable, consumidores identificados, SLAs comprometidos, versionado y proceso de deprecación. Las seis propiedades que lo definen son: descubrible, direccionable, confiable, auto-descriptivo, interoperable y seguro. Organizaciones que adoptan esta disciplina reducen el tiempo de resolución de incidentes de datos en 60–80% y multiplican la confianza de los consumidores en los números que usan para decidir.
Definición
Un data product es un conjunto de datos — o interfaz de datos — que una organización trata explícitamente como un producto gestionado, con propietario responsable, consumidores conocidos, acuerdos de nivel de servicio (SLAs) formales y un ciclo de vida definido que incluye lanzamiento, mantenimiento y deprecación. El concepto fue sistematizado por Zhamak Dehghani en su trabajo sobre arquitectura data mesh (2019–2022), pero la disciplina subyacente — tratar los datos analíticos con el mismo rigor con que se gestionan los productos de software — es aplicable en cualquier organización con datos, independientemente de si adopta data mesh como arquitectura.
La distinción fundamental entre un data product y un dataset convencional no es técnica sino organizacional. Un dataset existe mientras el pipeline que lo genera funciona; no tiene propietario claro, no tiene SLAs comprometidos, nadie es accountable cuando falla, y sus consumidores no saben si pueden confiar en él. Un data product, en cambio, tiene un equipo o persona que responde por su calidad, documentación actualizada accesible para cualquier consumidor, métricas de calidad monitoreadas automáticamente, y un proceso formal para notificar a los consumidores cuando cambia o se depreca. La diferencia es la diferencia entre un activo de datos y una deuda de datos.
Cómo se implementa
Implementar un data product requiere abordar cuatro dimensiones simultáneamente: propiedad, descubribilidad, calidad y acceso. La propiedad implica designar un domain team o Data Product Owner que sea accountable del SLA, de la documentación y del roadmap del producto de datos — no un equipo central de datos que recibe tickets, sino el equipo de negocio más cercano al dominio (el equipo de finanzas es dueño del data product de ingresos; el equipo de ventas es dueño del data product de pipeline).
Checklist de lanzamiento de un data product
- — Propietario designado con SLA de respuesta a incidentes documentado
- — Registrado en el catálogo de datos con descripción, columnas, frecuencia de actualización
- — Tests de calidad automatizados (completitud, unicidad, frescura, rangos esperados)
- — Canal de notificación a consumidores ante cambios de esquema o degradaciones
- — Versionado semántico: consumidores saben qué versión usan y cuándo se deprecan versiones antiguas
- — Política de acceso: quién puede leer, quién puede escribir, qué campos son PII
La descubribilidad requiere que el data product esté indexado en un catálogo de datos — Atlan, Castor, DataHub, OpenMetadata — con metadatos suficientes para que un consumidor nuevo pueda encontrarlo, entender su semántica y evaluar si cubre su caso de uso sin necesidad de hablar con el equipo propietario. La calidad requiere tests automatizados que se ejecuten con cada actualización y que generen alertas cuando los SLAs se incumplen. El acceso requiere controles de seguridad que permitan a los consumidores autorizados acceder directamente al data product sin solicitudes manuales.
Ejemplo práctico
Considere una empresa de tecnología financiera con sede en Bogotá que ofrece crédito a PYMEs. Su equipo de datos mantiene actualmente 47 tablas en BigQuery sin propietarios formales, sin documentación y sin tests de calidad. El equipo de riesgo usa una tabla llamada clientes_activos para calcular el scoring de crédito; el equipo de finanzas usa otra llamada portfolio_vigente. Ambas tablas deberían reportar el mismo número de clientes activos, pero frecuentemente difieren en 3–8% sin que nadie sepa por qué. Los modelos de riesgo que se alimentan de datos inconsistentes subestiman o sobrestiman la exposición en hasta $420 millones de pesos colombianos por ciclo de aprobación.
La solución no es técnica — es organizacional. El equipo decide crear un data product llamado portafolio-crediticio con las siguientes características: propietario formal (el Director de Riesgo), SLA de frescura de 15 minutos desde el cierre de operaciones, tests automatizados de reconciliación con el core bancario cada hora, documentación en el catálogo con definición precisa de "cliente activo" (crédito vigente con al menos un pago realizado, sin mora mayor a 60 días), y política de acceso que permite lectura a los equipos de riesgo y finanzas sin solicitud manual. Dos meses después del lanzamiento, las discrepancias entre los reportes de riesgo y finanzas desaparecen. El tiempo de resolución de incidentes de datos cae de 4.2 días a 6 horas porque el propietario está identificado y el SLA es contractual.
Análisis en profundidad
El problema que los data products resuelven no es nuevo: las organizaciones han lidiado con datos inconsistentes, sin propietario y difíciles de encontrar desde que existen los sistemas de información. Lo que cambió en la década de 2010 fue la escala: la proliferación de fuentes de datos (SaaS, APIs, eventos, streams) y la democratización de las herramientas de analítica crearon un número de datasets mucho mayor de lo que los equipos centrales de datos podían gestionar con rigor. El resultado fue lo que la industria comenzó a llamar el "pantano de datos" (data swamp): lagos y warehouses llenos de tablas que nadie sabe si son confiables, qué significa cada columna, o qué equipo las mantiene. Los data products son la respuesta disciplinada a esa proliferación.
Las seis propiedades que Dehghani define para un data product — descubrible, direccionable, confiable, auto-descriptivo, interoperable y seguro — no son independientes entre sí. La confiabilidad sin descubribilidad produce datos de alta calidad que nadie usa porque nadie sabe que existen. La descubribilidad sin confiabilidad lleva a consumidores que encuentran los datos pero no saben si pueden fiarse de ellos. La interoperabilidad sin seguridad crea datos accesibles pero expone información sensible de clientes. Un data product que cumple cinco de las seis propiedades y falla en una de ellas tiene un déficit estructural que tarde o temprano genera un incidente — de datos o de seguridad.
La gestión del ciclo de vida es el aspecto más frecuentemente ignorado en implementaciones iniciales de data products. Los equipos dedican energía al lanzamiento — documentación, tests, registro en el catálogo — pero no establecen procesos claros para el versionado ni para la deprecación. El resultado es data products con versiones múltiples que coexisten silenciosamente, consumidores que no saben qué versión están usando, y cambios de esquema que rompen pipelines downstream sin aviso. Un data product maduro tiene una política explícita de versionado semántico (mayor.minor.patch), un SLA de comunicación ante cambios breaking (mínimo 30 días de aviso), y un registro de deprecación accesible en el catálogo.
La arquitectura data mesh adopta los data products como unidad de despliegue de datos y los combina con tres principios adicionales: propiedad descentralizada por dominio (cada equipo de negocio es dueño de sus datos), plataforma de datos como infraestructura compartida (el equipo de plataforma provee las herramientas para que cualquier equipo pueda crear y publicar data products sin conocimiento profundo de infraestructura), y gobernanza federada (políticas centrales de seguridad, privacidad e interoperabilidad que cada dominio aplica de forma autónoma). Sin embargo, adoptar data mesh sin los fundamentos organizacionales — cultura de producto, equipos con suficiente madurez técnica en cada dominio, plataforma de datos madura — produce exactamente el caos que intenta resolver, solo que distribuido.
La relación entre data products y las herramientas del modern data stack (dbt, catálogos, plataformas de observabilidad) es de habilitación mutua. dbt permite definir modelos de datos como código versionado, lo que facilita establecer propietarios, generar documentación automática y ejecutar tests de calidad en cada ejecución. Los catálogos de datos (Atlan, Castor, DataHub) proveen la capa de descubribilidad y auto-descripción. Las plataformas de observabilidad (Monte Carlo, Soda, Datafold) monitorean la confiabilidad en tiempo de ejecución. Un equipo que ya usa estas herramientas tiene la infraestructura técnica para implementar data products — la brecha es organizacional: asignar propietarios, definir SLAs y establecer los procesos de comunicación a consumidores.
Errores frecuentes
- ✗
Confundir data product con dataset bien documentado. La documentación es necesaria pero insuficiente. Un data product requiere propietario accountable con SLA comprometido, tests de calidad automatizados, proceso de versionado y mecanismo de notificación a consumidores. Un dataset con un README actualizado es un dataset con mejor documentación — no un data product. La confusión lleva a organizaciones a "declarar" data products sin establecer las estructuras organizacionales que los hacen sostenibles.
- ✗
Centralizar la propiedad de todos los data products en el equipo de datos. Si el equipo central de datos es el propietario formal de todos los data products de la organización, el modelo colapsa bajo su propio peso — el equipo no tiene el contexto de dominio para mantener la calidad semántica de datos de finanzas, ventas, operaciones y producto simultáneamente. La propiedad debe estar en los equipos de dominio que tienen el conocimiento para definir qué significa "cliente activo" en el contexto de crédito o "orden completada" en el contexto de logística.
- ✗
Lanzar data products sin plataforma de datos que los soporte. Equipos de dominio sin experiencia en infraestructura de datos no pueden construir y operar data products de forma autónoma si no existe una plataforma de datos que abstraiga la complejidad — plantillas de pipelines, catálogo auto-poblado, monitoreo de calidad automatizado, control de acceso centralizado. Pedir a equipos de negocio que construyan data products sin esta plataforma es equivalente a pedir a los equipos de producto que gestionen su propia infraestructura de servidores.
Cómo lo rastrea Fairview
Fairview actúa como una capa de operating intelligence sobre los data products existentes en la organización. Cuando los datos operativos — ingresos, costos, métricas de retención, pipeline de ventas — están organizados como data products con SLAs y propietarios definidos, Fairview puede consumirlos con confianza y construir sobre ellos las métricas de operating intelligence que los COOs y operadores necesitan para tomar decisiones. La plataforma conecta con las fuentes de datos subyacentes — warehouses como Snowflake o BigQuery, plataformas de facturación como Stripe, CRMs como Salesforce — y aplica las mismas propiedades de confiabilidad, frescura y consistencia que definen a un data product maduro. Las alertas de degradación de calidad llegan al operador responsable antes de que los números incorrectos lleguen a los reportes de dirección.
Preguntas frecuentes
¿Cuál es la diferencia entre un data product y un dataset?
Un dataset es un conjunto de datos sin compromisos de calidad, propietario claro ni ciclo de vida definido. Un data product tiene un propietario responsable, SLAs de frescura y calidad, documentación actualizada, consumidores identificados y un proceso formal de versionado y deprecación. La diferencia es organizacional, no técnica.
¿Qué propiedades debe tener un data product según la arquitectura data mesh?
Zhamak Dehghani define seis propiedades: descubrible, direccionable, confiable, auto-descriptivo, interoperable y seguro. Un data product que incumple alguna de estas propiedades es un dataset convencional con un nombre diferente. Cada propiedad tiene requisitos técnicos y organizacionales específicos que deben implementarse explícitamente.
¿Un data product tiene que formar parte de un data mesh para existir?
No. Aunque el data product es el concepto central de data mesh, la disciplina de tratar datasets como productos gestionados es útil en equipos de datos centralizados. Una organización puede aplicar los principios de data product sin adoptar la descentralización de data mesh. La confusión entre ambos conceptos lleva a muchos equipos a descartar el concepto creyendo que requiere una reorganización corporativa completa.
¿Cómo se mide la calidad de un data product?
La calidad se mide mediante completitud (porcentaje de registros sin valores nulos en campos críticos), frescura (tiempo desde la última actualización versus el SLA comprometido), unicidad (ausencia de duplicados), consistencia (coherencia entre tablas relacionadas) y exactitud (concordancia con la fuente de verdad). Herramientas como dbt tests, Great Expectations, Monte Carlo y Soda automatizan estas comprobaciones. Un data product maduro tiene un scorecard de calidad visible para sus consumidores.