Diseñar una arquitectura de datos: quien no define la propiedad, construye sobre arena

La falta de propiedad clara sobre los datos es la causa más frecuente de informes contradictorios, cadenas de procesamiento frágiles e iniciativas de gobernanza fallidas. Una arquitectura que aborda este problema de forma estructural se ve muy distinta a la que hoy operan la mayoría de las organizaciones.

El problema tiene nombre, y no es “datos de mala calidad”

Data Lakes, informes contradictorios, procesos de tratamiento frágiles. En casi todas las empresas a las que acompañamos en CONVOTIS, la raíz del problema es la misma: los datos no tienen propietario. No porque nadie quiera asumir la responsabilidad, sino porque la arquitectura no contempla la propiedad de los datos como un principio estructural.

Toda organización debe responder tres preguntas antes de seleccionar la primera herramienta:

• ¿Quién es responsable de la calidad?
  En la práctica, responder “todos” equivale a responder “nadie”. La propiedad basada en dominios – donde el equipo que genera los datos asume la responsabilidad – parece algo simple, pero requiere un anclaje organizativo real. Una matriz RACI no basta.
• ¿Dónde está definido oficialmente qué significa “cliente activo”?
  Normalmente en una hoja de cálculo con tres versiones distintas y ninguna considerada oficial. Una capa semántica en el repositorio resuelve el problema técnicamente, pero solo si también está claro quién tiene autoridad sobre esa definición.
• ¿A partir de qué etapa de procesamiento un conjunto de datos se considera apto para la toma de decisiones?
  Sin zonas de calidad explícitas, todo termina sin filtrar en las herramientas analíticas. El resultado: informes que se contradicen entre sí y discusiones sobre cuál es correcto, en lugar de debatir lo que realmente muestran los datos.

Una arquitectura que deja abiertas estas tres preguntas desplaza la confianza hacia la intuición.

¿Cuándo vale la pena la transformación y cuándo no?

Antes de entrar en la arquitectura, una valoración honesta: el modelo de productos de datos gestionados no es una solución universal.

Menos de cinco equipos y menos de veinte conjuntos de datos – las convenciones ligeras son completamente suficientes. La inversión adicional solo compensa cuando los equipos dependientes se bloquean entre sí, cuando el coste de una caída de datos supera el esfuerzo de gobernanza o cuando una solicitud GDPR tarda actualmente tres semanas en resolverse.

Introducirlo demasiado pronto genera complejidad sin retorno. Introducirlo demasiado tarde implica reconstruir sobre una base inestable, cargando además con deuda técnica y organizativa acumulada.

Qué es un producto de datos y por qué fallan los pipelines tradicionales

El cambio decisivo es conceptual: dejar de pensar que los datos “fluyen” y empezar a pensar que los datos “se entregan”.

Un producto de datos es una unidad delimitada, versionada, documentada y monitorizada, comparable a un contrato de interfaz entre equipos. Tiene un punto de acceso estable, un nivel de servicio definido y un equipo responsable. Data Mesh describe este enfoque como propiedad de datos orientada a dominios: no es una herramienta ni un stack tecnológico, sino un principio organizativo con consecuencias técnicas.

Un producto de datos maduro cumple seis condiciones:

• Localizable: en el catálogo de datos, no mediante mensajes informales o cadenas de correo internas
• Documentado: definiciones de campos legibles por máquina, no escondidas en un wiki abandonado
• Compromiso de calidad: SLOs medibles, no frases como “debería estar correcto”
• Punto de acceso estable: sin cambios silenciosos de esquema ni caos de migraciones
• Propiedad clara: un equipo responsable, no un comité ni responsabilidades difusas
• Validación automatizada de calidad: en cada etapa del procesamiento, no al final

Quien omite una sola de estas condiciones no está construyendo productos de datos. Está construyendo tablas bien intencionadas.

Los errores más costosos casi siempre aparecen en torno a la quinta condición, no porque nadie supervise, sino porque no está claro quién debe reaccionar ante una alerta. En un proyecto que asumimos en CONVOTIS, las alertas de monitorización llevaban meses sin respuesta porque ningún equipo tenía responsabilidad formal. Los datos siguieron circulando. También las decisiones.

Los tres fundamentos: trazabilidad, semántica y calidad

El producto de datos es la unidad, pero se sostiene sobre tres capas. Si falta una, las demás colapsan.

Trazabilidad: saber de dónde proviene un dato

Sin lineage, cualquier búsqueda de errores se convierte en un juego de adivinanzas. Con ella, preguntas que normalmente tomarían horas pueden resolverse en minutos: ¿el error surgió en el sistema origen, durante la transformación o en la entrega final?

Para comenzar, el seguimiento a nivel de tablas es suficiente. OpenLineage define el formato abierto de intercambio y Marquez ofrece una implementación ligera. DataHub es la alternativa más completa: un catálogo integral con lineage, búsqueda y clasificación, aunque requiere más esfuerzo operativo.

El seguimiento a nivel de columna se vuelve obligatorio cuando debe demostrarse cumplimiento con GDPR. Quien lo implementa solo tras recibir la primera solicitud de acceso descubre rápidamente cuánto trabajo se ha acumulado y cuánto puede demorarse una obligación legal.

Capa semántica: una única verdad, versionada

Dos informes, una pregunta, dos respuestas: el síntoma clásico de la falta de autoridad semántica.

MetricFlow (parte de dbt) mantiene las definiciones de términos versionadas en el repositorio: una única definición validada de clientes_activos, accesible desde cualquier herramienta analítica. Sin hojas de cálculo, sin acuerdos informales, sin versiones paralelas en otros departamentos.

El cuello de botella habitual aparece cuando diferentes áreas compiten entre sí. Ventas y Finanzas definen “ingresos” de forma distinta, y ambos tienen razones válidas. Lo que ayuda es una propiedad clara de las métricas y un proceso de escalado que involucre a las áreas de negocio antes de incorporar la definición al repositorio. Las herramientas hacen visibles estos conflictos; resolverlos sigue siendo tarea de las personas.

Supervisión de calidad en el pipeline: validar antes, reaccionar explícitamente

Las validaciones de calidad pertenecen al pipeline de procesamiento, no al informe final. Descubrir errores únicamente en el dashboard significa que ya se han tomado malas decisiones.

Un patrón probado divide el pipeline en tres zonas:

• Zona de entrada: integridad, validez y cumplimiento de formato
• Zona de transformación: consistencia de volúmenes, reglas de negocio e integridad referencial
• Zona de entrega: desviaciones respecto al día anterior, puntuación de calidad y estado de aprobación

El factor decisivo es la estrategia de respuesta cuando falla una validación: interrupción total para datos financieros, cuarentena para grandes volúmenes, advertencias visibles para análisis exploratorios. Esta decisión debe tomarse explícitamente; no puede surgir de manera implícita porque nadie la definió. Herramientas como Great Expectations o dbt Tests implementan este patrón.

Gobernanza: por qué las reglas de acceso y la eliminabilidad deben formar parte de la arquitectura

Solicitudes GDPR, peticiones de eliminación, auditorías: todas plantean la misma pregunta. ¿Dónde están almacenados los datos de esta persona? Quien primero tenga que buscar la respuesta ha tratado la gobernanza como algo secundario.

Cuatro medidas lo previenen estructuralmente:

• Políticas de acceso como código mediante Open Policy Agent. Sin ello: aprobaciones manuales, sin auditabilidad ni reproducibilidad.
• Etiquetado de sensibilidad a nivel de campo en los metadatos del esquema. Sin esto, la plataforma no puede aplicar automáticamente mascarado o bloqueo de datos.
• Períodos de retención como configuración en el repositorio versionado. De lo contrario, las cadenas de correos y procesos manuales terminan controlando los plazos.
• Eliminabilidad como principio de diseño, incorporado desde el primer día.

La eliminabilidad implementada a posteriori es uno de los problemas arquitectónicos más costosos que conocemos. Varios equipos, varias semanas y una sola solicitud de acceso, simplemente porque nadie puede responder dónde están realmente esos datos.

Cómo empezar sin reconstruir todo el sistema

El error más frecuente durante la implementación es empezar demasiado a lo grande. El enfoque correcto es empezar de forma específica.

Paso 1: identificar el flujo de datos crítico: donde los informes se contradicen, donde los equipos se culpan mutuamente o donde una caída tendría el mayor impacto.

Paso 2: implementar lineage para ese flujo concreto, incorporar validaciones automáticas de calidad y definir estrategias de respuesta.

Paso 3: aclarar explícitamente la propiedad: con nombres, rutas de escalado y recursos reales. La responsabilidad sin recursos ni autoridad sigue siendo solo una declaración de intenciones.

Solo cuando este flujo funcione de forma estable y el equipo asuma realmente la propiedad tiene sentido escalar el modelo.

El punto donde termina la tecnología

Quien trate la calidad de los datos como un objetivo de proyecto tendrá un nuevo problema tras el go-live. Las herramientas para operaciones estables existen: son maduras, probadas y están bien documentadas. Lo que casi siempre falta es alguien que se sienta realmente responsable cuando importa. Con autoridad. Con recursos. Y con un proceso de escalado que funcione.