DataDriven · por Jorge Mercado JMCOACH
Comencé a trabajar con datos cuando a muy temprana edad, cuando era un archivo secuencial en cinta magnética o cartucho y después discos flexibles y la "consulta" era un programa en COBOL, BASIC, PASCAL, C que leía registro por registro de principio a fin. No había SQL Accesible en México. No había índices. No había joins. Solo registros de longitud fija, posición de byte y la disciplina brutal de saber exactamente qué ibas a necesitar antes de escribir la primera línea.
Tres décadas después, con todo el poder de la nube, de los data lakes, del procesamiento distribuido y ahora de la inteligencia artificial generativa, sigo viendo el mismo error de origen que veía en 1987 (siendo niño ya programaba): sistemas diseñados sin visión de datos, sin escalabilidad pensada desde el inicio, sin un modelo de datos que refleje cómo funciona realmente el negocio.
La tecnología cambió radicalmente. El error no. Y ya existía metodología de análisis, siendo niño aún aprendí Yourdon, después OMT y Booch, después CMM, RUP, etc + ISOs. Pasando por Togaf, Zachman, NIST, DDD, ADM. Las modas driven: Event, data, flow, etc.
He visto nacer y morir más modas tecnológicas de las que puedo contar. He visto que se decía que"el data warehouse nos va a resolver todo" en los 90s e incluso a fechas recientes se sigue usando igual que en ese tiempo, el "Hadoop va a cambiar todo" en los 2010s, "el IoT nos volverá locos con tan información en tiempo real" en los 2015, y hoy "la IA lo va a hacer por nosotros". Y en cada ciclo, las empresas que se quedan atrapadas en el mismo problema son las que corrieron hacia la tecnología sin resolver primero la arquitectura de datos sobre la que esa tecnología va a operar.
Por cierto, en ese tiempo ya leía sobre inteligencia artificial, redes neuronales, programación orientada a objetos, modem, hackers, etc.
No importa si estás migrando de COBOL, C, Java, .Net u otro a microservicios, de un ERP monolítico a una arquitectura de servicios, de un data warehouse a un data lake, o de análisis descriptivo a IA generativa. El primer obstáculo siempre es el mismo: datos inconsistentes entre sistemas, sin definición común, sin dueño, sin calidad medida. Ese problema no lo resuelve ninguna tecnología nueva. Solo lo amplifica. Sin olvidar que no se alinean a las necesidad y estrategia del negocio.
— Jorge Mercado · Cuatro décadas de observación de campo
El problema real no es la IA.
Cuando la gente me llama hoy diciéndome que "sus proyectos de IA no funcionan", mi primera pregunta siempre es la misma: ¿cuántos sistemas tienes con datos del mismo cliente? Si la respuesta es más de uno —y casi siempre es más de tres—, el problema no es la IA. El problema es exactamente el mismo que tenías en 1995 cuando tu sistema de ventas y tu sistema de cobranza no se ponían de acuerdo en el saldo del cliente. Lo que cambió es el costo de ese error: antes se traducía en un reporte incorrecto. Hoy se traduce en un modelo que aprende patrones equivocados a gran escala.
Pero ojo: el patrón que voy a mostrarte no es exclusivo de iniciativas de IA. Lo veo en migraciones a cloud que fracasan porque los datos que se migran están sucios y sin esquema. Lo veo en implementaciones de ERP que van 3 años de retraso porque nadie limpió los datos maestros antes de arrancar. Lo veo en integraciones de sistemas post-fusión donde dos empresas llevan 4 años "integradas" pero operan con dos versiones del mismo cliente. Lo veo en proyectos de automatización de procesos (RPA, BPM) que se caen porque los datos de entrada son impredecibles. Los veo en juntas no se concoe el negocio lo que esperan de los datos.
El síntoma cambia. La causa raíz es invariablemente la misma: sistemas diseñados sin visión de datos, acoplados de forma frágil, con componentes que nunca fueron diseñados para escalar ni para ser confiables a largo plazo.
El proceso de ahorcamiento: cómo se sanean sistemas que no puedes apagar
Una de las preguntas que más me hacen cuando presento diagnósticos con este nivel de deuda técnica es: "¿Y cómo lo arreglamos sin detener la operación?" Es la pregunta correcta. La respuesta, que he aplicado docenas de veces con variaciones según el contexto, es lo que en arquitectura de software se conoce como el patrón Strangler Fig —o lo que yo llamo desde hace años, sin eufemismos, el proceso de ahorcamiento.
La imagen es precisa y no es gratuita: la higuera estranguladora tropical crece alrededor de un árbol huésped, tomando su forma y su lugar gradualmente, hasta que el árbol original desaparece y la higuera queda en pie, sola, con su propia estructura. Así es exactamente como se sanea un sistema de datos heredado sin detener el negocio.
El proceso de ahorcamiento aplicado a sistemas de datos y componentes deficientes
El objetivo no es reemplazar el sistema de la noche a la mañana. Es rodear gradualmente cada componente deficiente con una capa nueva, validada y gobernada, hasta que el componente original puede ser desconectado sin impacto en el negocio.
- Diagnóstico de componentes deficientes. Antes de ahorcar nada, hay que saber exactamente qué está fallando y por qué. No qué tecnología es vieja, sino qué componente entrega datos con qué nivel de calidad, hacia qué sistemas, con qué frecuencia. El diagnóstico tiene que cuantificar el impacto de negocio de cada deficiencia —no en términos técnicos, sino en términos de decisiones incorrectas, reprocesos o riesgo regulatorio.
- Envoltura y captura (Wrap & Capture). Sin tocar el sistema origen, se implementa una capa intermediaria —un API gateway, un bus de datos, un consumer de Kafka, un proceso ETL— que intercepta la salida del componente deficiente y la normaliza, valida y enriquece antes de distribuirla. El sistema original sigue corriendo igual. Los consumidores downstream empiezan a recibir datos limpios desde la nueva capa.
- Saneamiento progresivo de datos. Con la capa de captura activa, se ejecuta el saneamiento retroactivo: deduplicación, corrección de formatos, normalización de catálogos, resolución de inconsistencias históricas. Este proceso no interrumpe la operación. Se trabaja en paralelo con datos históricos mientras el flujo en tiempo real ya sale limpio. La prioridad de saneamiento la define el impacto de negocio, no la antigüedad del dato.
- Validación de calidad antes de cada promoción. Ningún dato pasa de la capa de captura a los sistemas de consumo sin pasar por reglas de calidad automatizadas (Great Expectations, dbt tests, SQL assertions). Si no cumple: se rechaza, se alerta al Data Steward y se registra el incidente. No hay excepciones. Esta es la parte del proceso que más resistencia genera —y la que más valor produce a largo plazo.
- Migración de consumidores downstream. Uno a uno, los sistemas que consumían datos del componente deficiente son migrados para consumir de la nueva capa saneada. Este paso se hace de forma controlada, con período de coexistencia (ambas fuentes activas) y validación de consistencia entre la vieja y la nueva salida antes de cortar la dependencia con la fuente original.
- Desconexión del componente ahorcado. Cuando el último consumidor se ha migrado y la nueva capa ha operado en producción de forma estable el tiempo acordado (típicamente 30-90 días), el componente original se puede desconectar. No con un big-bang, sino con un switch silencioso que nadie nota porque el negocio ya no depende de él.
- Documentación del linaje y el catálogo. El proceso no termina con la desconexión. Termina cuando el nuevo componente tiene su ficha completa en el catálogo de datos: metadatos técnicos y de negocio, Data Owner, clasificación, regulación aplicable, retención, score de calidad. Sin esto, el ciclo se repite en 5 años con el componente que hoy es nuevo.
Este proceso no es rápido. Un componente de mediana complejidad toma entre 3 y 6 meses para completar el ciclo. Pero es seguro y produce resultados visibles desde las primeras semanas porque la nueva capa ya empieza a entregar datos más limpios a los consumidores, incluso antes de que el componente original sea desconectado. OJO: con herramientas CASE se puede hacer refactor, más el apoyo de la IA correctamente preparada que reduce estos tiempos ahora.
El estado de partida: lo que casi todos comparten
Antes de los tres casos, hay que ver el estado real del que partimos. No importa la industria —aerolínea, logística, seguros, fintech, retail, manufactura, gobierno. El diagnóstico inicial tiene siempre los mismos elementos:
La diferencia entre esas dos columnas no es de años. Es de diseño, de secuencia y de quién lidera con qué convicción en los primeros 90 días. Ahora los tres casos.
En la parte 2, usaré unos caso simulados para comprender cómo se leva la práctica del gobierno de datos en tres escenarios diferentes, que abrirán tu mente y sin duda alguna te caerá el veinte, varias veces.
#JMCoach
