Data contracts: el data lake no está roto, los acuerdos sí

Por qué los contratos de datos, responsables y reglas semánticas deben definirse antes de cargar información en un data lake empresarial.

Este artículo también está disponible en inglés.
Data contracts: el data lake no está roto, los acuerdos sí

🏗️ El data lake no está roto, están rotos los acuerdos

El problema aparece antes de que el dato llegue al lake

Cuando un proyecto de datos sale mal, lo primero que señala la empresa es la plataforma. Que si fue una mala elección, que si el equipo técnico no supo implementarla, que si el proveedor no cumplió lo que prometió. Ese ciclo de culpa es muy común en Colombia y casi siempre apunta al lugar equivocado.

El caos en un data lake empieza mucho antes de que el primer dato llegue al sistema.

Un data lake es un repositorio central donde la empresa almacena grandes volúmenes de datos en su estado original, antes de procesarlos. Piénselo como la bodega de una obra de construcción donde llegan ladrillo, tubería, cable y madera sin etiquetar ni categorizar. El depósito en sí no tiene la culpa de que la obra quede mal. El desorden empieza en el pedido.

Cuando el área de ventas manda un archivo donde la columna ventas netas incluye devoluciones y el área financiera manda otro donde no las incluye, los dos entran al sistema con el mismo nombre de campo. El analista tarda días en descubrir la diferencia y el informe se devuelve. Es como cuando llega ladrillo sin especificación de medida, entra igual que el demás y nadie lo nota hasta que no cupo donde debía ir.

Ese reproceso ocurre en muchas empresas colombianas con una regularidad que ya nadie cuestiona. Las reuniones de conciliación se vuelven rutina, los controles manuales no cuadran y alguien siempre tiene su propia versión del reporte. Se arman tablas en Excel para compensar lo que el sistema debería mostrar solo. El desorden no empezó en la bodega; empezó en el pedido.

La gobernanza del dato, que son los acuerdos y reglas que definen qué información entra al sistema, quién la genera y con qué criterio de calidad, casi siempre se aplaza. Se asume que es un asunto técnico que el equipo de datos resolverá por su cuenta. Pero cuando ese equipo llega, el desorden ya está adentro, y separarlo cuesta mucho más que haberlo controlado en la entrada.

Poner orden después de que todo entró sin control es como intentar clasificar materiales cuando ya van cuatro pisos construidos. Ese tiempo se resta de proyectos, de decisiones y de confianza en los reportes. Y ese era exactamente el problema que se quería resolver desde el principio.

Primero acuerde con sus áreas qué significa cada indicador clave antes de que el dato salga de la fuente. Luego asigne un responsable por cada dominio, alguien que responda por su calidad y no solo por generarlos. Después defina reglas mínimas de ingreso al sistema, como campos obligatorios y formatos estándar. Por último revise esos acuerdos cada vez que cambien los procesos, porque en la obra siempre llegan materiales nuevos.

Explora el hub completo de Arquitectura de Datos →