Hace unos meses estaba en una reunión con un colega de profesión, CTO de una gran empresa. No se trataba de una demo, ni un pitch comercial. Era más bien una conversación relajada entre técnicos. Estando allí surgió un tema que no me puedo quitar de la cabeza:
«Cada vez que necesitamos mover datos de Oracle a BigQuery, es un Proyecto (con mayúsculas). Con su presupuesto, su equipo, su timeline. Entre 35.000 y 70.000 euros. Y cuando es de SAP, peor todavía.»
Se reclinó en la silla.
«¿Sabes lo que hacemos? Usamos otra plataforma de datos como plataforma de salto. Sacamos los datos de un sitio, los dejamos en otro, y desde ahí los empujamos al siguiente.»
Una plataforma intermedia. Solo para mover datos de A a B.
Me quedé dando vueltas a la idea de que no estaba describiendo un problema técnico estaba describiendo un impuesto. Un peaje que su empresa pagaba cada vez que necesitaba que sus propios datos estuvieran donde los necesitaba. Multiplicado por decenas de integraciones al año.
Tengo que decir que no lo decía con indignación, sino más bien con resignación. La verdad es que me inquietó que lo expresara como si fuera inevitable. Sin duda era un reflejo de lo que estamos viviendo en el sector.
Cuando salí de esa reunión pensé en algo que ya veníamos viendo en QRY. Nosotros ya nos conectamos con Oracle, SAP HANA, BigQuery, Snowflake, PostgreSQL, Redshift… Tenemos conexiones nativas con múltiples plataformas así que ese ya no era el reto. Sumado a lo anterior, teníamos algo que ninguna herramienta de integración tradicional tiene: un motor de inteligencia artificial que entiende la estructura de los datos, que puede generar SQL, Python o lo que sea necesario y que puede corregirse cuando algo falla.
La pregunta era casi obvia, y sin embargo nadie la estaba haciendo: si ya sabemos leer de cualquier fuente y escribir en cualquier destino, ¿por qué seguimos tratando cada movimiento de datos como un proyecto de ingeniería?
No hace falta inventar un nuevo ETL pero sí cambiar la pregunta. Dejar de pensar en pipelines como infraestructura y empezar a pensarlos como conversaciones: «toma estos datos de aquí, transfórmalos así, y déjalos allí».
Pero mover datos es solo la mitad del problema. La otra mitad es confiar en lo que llega. ¿Cuántas veces un pipeline mueve miles de registros y nadie se da cuenta de que la mitad vienen con valores nulos, con formatos rotos, con claves que ya no existen en destino? ¡Ay, amigo! El dato llega, sí, pero llega mal y alguien lo descubre semanas después, cuando un informe no cuadra o un modelo devuelve resultados absurdos.
Me quedé pensando en cómo lo hacíamos nosotros, casi por pura obsesión profesional, y me dije: Desde el principio diseñamos validaciones como parte del flujo, no como algo que se añade después.
Las reglas de negocio se ejecutan dentro del pipeline y si un campo crítico viene vacío, el registro se descarta. Si una métrica se desvía del rango esperado, el pipeline se detiene antes de contaminar el destino. Y al final, si algo falla, la inteligencia artificial propone la corrección antes de que alguien abra un ticket.
¿Entonces? Si esto lo estábamos haciendo ya (la integración de QRY Forge dentro de QRY, hace justo esto) ¿Por qué se está repitiendo la misma frustración en diferentes empresas de distintos tamaños y sectores?
Mi pensamiento vuelve a la reunión con mi colega y es que el patrón siempre es el mismo: datos atrapados en silos, equipos de ingeniería saturados haciendo fontanería en lugar de generar valor, y un coste oculto que nadie suma pero que todos pagan. Ese proyecto de 50.000€ que se repite cinco, diez, veinte veces al año. Ese mes y medio de espera para algo que conceptualmente es simple.
A veces me preguntan cuál es la ventaja competitiva de integrar inteligencia artificial en una plataforma de datos. Mi respuesta no es «genera SQL más rápido», es que elimina tareas repetitivas que no generan valor, reduce los tiempos y permite a los equipos humanos poner el foco en la estrategia y en innovación.
Aquella conversación me enseñó algo que ya sabía, pero no había articulado: el problema más caro en datos no es el que no sabes resolver, sino el que resuelves una y otra vez.
Sergio Rodríguez de Guzmán.
