Encuentra las 7 diferencias: Mantener la consistencia en un revamp
Las herramientas de data building y los nuevos entornos de desarrollo en los equipos de datos están facilitando la automatización, comprobación y despliegue de procesos de data y la independencia de los analistas para generar sus propios checks y modelos.
Pero las data building tools y los nuevos procesos no solo traen mejoras, también algún dolor de cabeza cuando no se trata de construir desde cero, si no mover información de un sistema legacy a un nuevo sistema, lo que conocemos como revamp.
¿Qué es un revamp?
Técnicamente, un revamp es la mejora de un proceso. Si una data building tool ya facilita el testeo y despliegue de forma automatizada, procesos que antes no se desarrollaban, es una mejora.
Pero en el ámbito de data y en los entornos en los que últimamente me muevo, donde se están implementando estas soluciones, estas herramientas también acogen procesos de entornos anteriores a estas nuevas implementaciones y aquí, en este proceso de traducir de un procedimiento legacy a un proceso innovador, tienen mucho que aportar. Y los equipos mucho que debatir sobre cómo se construye el proceso desde cero y cómo mejorarlo.
Un ejemplo con el que nos encontramos muy frecuentemente son las tablas de información que históricamente se han mantenido a mano, donde se inputan datos en una hoja de cálculo o en un csv con pipelines arcaicos que actualizan un input de la base datos, sin cuestionarse el valor ni la mejora, generando dependencias que a la larga pueden suponer un problema.
¿Cuándo un proceso manual genera un problema?
¿Un problema? ¡Varios! Y siempre. Más aún, cuando tenemos que hacer un revamp de un proceso. Te traigo un ejemplo con el que me he tropezado en varias ocasiones. El caso de los cambios de moneda.
El equipo de finanzas tiene una hoja de cálculo donde cada mes incluye una media de cambio de una moneda a otra consultando en alguna página web.
Una tabla arcaica que se ingesta mediante un pipeline en la base de datos.
Primer problema:
- No hay comprobación de que la información ingestada es correcta 🤦🏻♀️
Asumimos que la información de la hoja de cálculo es válida, sin testear contra ninguna API de organismos oficiales o contra la fuente original.
Segundo problema:
- ¿Qué dato de conversión disponibilizamos: diario, semanal, mensual? Por lo general, hay una media diaria disponible en diferentes APIs o ERPs. Lo habitual es ingestar un dato medio mensual, con lo que se pierde precisión para los cierres de mes 🙄
Perdemos precisión con respecto a una información disponible que podría facilitarle la vida al equipo de finanzas, pero asumimos que este workaround ha echo más sencilla la vida de alguien en algún punto.
Asumiendo pequeñas desviaciones, se sobrevive. Pero llegamos al momento del revamp del legacy y...
Disponibilizamos información diaria de una API del Banco Central Europeo, ingestamos información con una data building tool con intención de que al mejorar el proceso, sustiyamos la tabla manual por la info del BCE.
Tercer problema:
- Al reconstruir el histórico de datos, no hay consistencia entre la información que se ha reportado anteriormente y la información que se genera nueva 😱
¿Cómo mantener la consistencia en un revamp?
Hay diferentes soluciones, pero puestos a evitar los workaround que van a dejar problemas a futuro, lo ideal es ir al equipo de negocio y debatir con ellos el proceso, puesto que es el equipo el owner del conocimiento.
La aproximación más frecuente es hacer una partición entre histórico y nuevo con lo que el equipo de negocio no tiene que tocar datos anteriores y todo lo nuevo se genera desde un proceso automatizado y testeado.
En términos técnicos, el proceso se resume:
- Generar una seed o tabla externa con el histórico de la información de cambio de moneda. Puestos a confiar en lo que teníamos, confiemos hasta el final.
- Hacer una partición en base a la fecha de automatización. En el modelo, los datos anteriores se cruzan con la información de la seed; los nuevos, con la información de la API.
Con este procedimiento se mantiene la consistencia entre los datos anteriores, para no darle un dolor de cabeza al equipo de negocio y se genera un proceso automatizado, fiable desde el punto de vista de data que evite errores de cara a futuro.
Happy Coding!
