Por qué pensar los datos desde el diseño del producto puede definir lo que una organización será capaz de aprender en el futuro.

En un lugar donde trabajé teníamos un proceso de solicitudes que atravesaba distintos estados.

Cada vez que una solicitud avanzaba, el sistema actualizaba su estado. Si estaba en iniciada y pasaba a validación, simplemente reemplazábamos un valor por otro.

Operacionalmente, funcionaba. El sistema siempre sabía cuál era el estado actual de cada solicitud y eso era suficiente para continuar con el proceso.

Hasta que apareció una pregunta de negocio bastante sencilla.

Queríamos entender cuánto tiempo tardaban los clientes en pasar de un estado al siguiente. Queríamos identificar en qué momentos quedaban detenidos para evaluar si podíamos intervenir, enviar un recordatorio o generar algún estímulo que los ayudara a terminar el flujo.

Y no pudimos responderlo.

Sabíamos dónde estaba cada solicitud, pero no cómo había llegado hasta ahí. El estado anterior había sido sobrescrito. No teníamos los timestamps de cada transición ni la historia necesaria para reconstruir el recorrido.

En ese momento, el problema ya no era de analytics.

El dato simplemente no existía.

Guardar el estado actual nos permite operar. Guardar la historia nos permite aprender.

Un sistema puede funcionar perfectamente y aun así perder información valiosa

Cuando diseñamos software, naturalmente pensamos primero en lo que el sistema necesita hacer.

¿Qué información necesitamos para ejecutar este proceso? ¿Qué estado tiene una solicitud? ¿Qué saldo tiene una cuenta? ¿Qué producto eligió un cliente? ¿Qué resultado tuvo una operación?

Son preguntas necesarias. El problema aparece cuando diseñamos exclusivamente para responderlas.

Esta tensión entre operar el presente y conservar la historia está bien documentada en patrones de arquitectura como Event Sourcing. Mientras que en un modelo tradicional solemos actualizar el estado actual de una entidad y perdemos su historia si no incorporamos mecanismos adicionales de auditoría, Event Sourcing conserva la secuencia de eventos que produjo ese estado.

No creo que todos los sistemas deban implementar Event Sourcing. Introduce complejidad y trade-offs que no siempre se justifican.

Pero sí creo que todos los sistemas deberían hacerse una pregunta antes de decidir qué información conservar:

¿Qué vamos a querer entender mañana sobre lo que está ocurriendo hoy?

Porque son dos problemas diferentes.

Un sistema puede estar perfectamente diseñado para ejecutar una operación y pobremente diseñado para aprender de esa operación.

La temporalidad también es parte del dato

Hay algo a lo que intento prestar especial atención cuando pienso datos: el tiempo.

Supongamos que tenemos esta información:

estado = aprobado

Puede ser suficiente para ejecutar el proceso.

Pero para analizarlo quizás necesitemos saber mucho más: cuándo se aprobó, cuánto tiempo permaneció en el estado anterior, qué ocurrió antes de la aprobación, cuántas veces cambió de estado, qué regla estaba vigente cuando se tomó la decisión o si hubo una intervención manual.

Muchas de las preguntas interesantes que hacemos sobre un negocio no son solamente preguntas sobre qué ocurrió.

Son preguntas sobre cuándo ocurrió, en qué orden y bajo qué contexto.

En la gestión de datos existe un concepto particularmente útil: la procedencia del dato (data provenance). Se refiere a conservar información sobre el origen de un dato y las transformaciones que atravesó durante su ciclo de vida.

En un producto digital no necesitamos llevar este concepto necesariamente al nivel de rigurosidad de un entorno científico, pero la idea de fondo me parece muy potente:

Tu sistema no debería guardar solamente lo que pasó. Debería permitir entender cómo pasó.

Porque una vez que perdemos la secuencia, podemos conservar el resultado y aun así haber perdido una parte fundamental de la información.

El dato más caro puede ser el que decidiste no guardar

Hoy almacenar datos es relativamente barato.

Eso no significa que los datos sean gratis.

Hay costos de procesamiento, pipelines, calidad, observabilidad, gobierno, seguridad, privacidad y consulta. Cuantos más datos conservamos, más tenemos que administrar.

Por eso tampoco creo en guardar absolutamente todo "por las dudas". Hay que tomar decisiones.

Lo interesante es que esas decisiones tienen una asimetría.

Si guardamos un dato y dentro de tres años descubrimos que nunca lo utilizamos, probablemente asumimos un costo innecesario. Pero si decidimos no guardarlo y dentro de tres años descubrimos que era fundamental para responder una pregunta, puede que ya no exista ninguna forma de recuperarlo.

Podemos decidir eliminar información más adelante. Lo que no siempre podemos hacer es volver atrás para capturar algo que nunca registramos.

El dato más caro puede ser el que decidiste no guardar.

No porque todos los datos vayan a tener valor.

Sino porque algunas oportunidades de capturarlos ocurren una sola vez.

El problema es que todavía no sabemos qué vamos a necesitar

Esto aparece muchísimo en Data Science.

Alguien puede preguntar:

"¿Esta variable realmente va a servir para el modelo?"

Y muchas veces la respuesta correcta es:

No lo sabemos.

Podemos tener una intuición. Por experiencia podemos pensar que determinada variable debería estar relacionada con el comportamiento que queremos predecir, pero necesitamos probarlo.

Si el dato ya existe, podemos analizarlo, construir la variable, evaluar su capacidad predictiva y decidir si vale la pena incorporarla. Si podemos reconstruirlo retrospectivamente desde otra fuente, también tenemos una alternativa.

El problema aparece cuando no existe y tampoco podemos inferirlo.

Ahí necesitamos modificar el sistema para empezar a capturarlo y después esperar a generar historia. Pueden ser semanas, meses o incluso más, dependiendo del fenómeno que queremos estudiar.

Por eso la falta de un dato no genera solamente una limitación analítica.

Puede generar tiempo de espera para poder tomar una decisión.

Y ese costo puede ser mucho mayor que el de haber conservado una variable o un evento que finalmente nunca utilizamos.

Data debería estar en la génesis del producto

Por eso intento que los equipos de desarrollo también piensen de manera data-driven.

Tradicionalmente podemos imaginar un flujo parecido a este:

Negocio define → Desarrollo construye → El sistema genera datos → Data analiza

El problema es que cuando Data aparece solamente al final, muchas decisiones ya fueron tomadas: qué eventos se registran, qué timestamps existen, qué información se sobrescribe, qué identificadores permiten relacionar sistemas, qué contexto conservamos de una decisión y qué historia podemos reconstruir.

Después podemos construir un pipeline extraordinario, un warehouse impecable y dashboards muy sofisticados.

Pero ninguna de esas cosas puede inventar información que el producto nunca generó.

Por eso prefiero pensar el proceso de otra manera:

Negocio + Desarrollo + Data diseñan → El producto opera → El producto genera conocimiento

No significa que Data tenga que aprobar cada funcionalidad ni que agreguemos burocracia al desarrollo.

Significa incorporar algunas preguntas desde la génesis:

  • ¿Qué queremos medir?
  • ¿Qué podríamos querer entender más adelante?
  • ¿Qué decisiones futuras podría alimentar esta funcionalidad?
  • ¿Qué historia necesitamos conservar para poder reconstruir lo que ocurrió?

La infraestructura de datos empieza mucho antes del data warehouse.

Empieza en el diseño del producto.

Diseñar para aprender no significa guardar todo

Hay un equilibrio importante.

Podríamos llevar este argumento al extremo y concluir que deberíamos guardar absolutamente todo.

No creo que sea una buena solución.

Además del costo de procesamiento y gobierno, existen datos que no deberíamos conservar indefinidamente por razones de privacidad, seguridad o regulación. Y cuantos más datos acumulamos, mayor es nuestra responsabilidad sobre ellos.

El objetivo no es maximizar la cantidad de datos.

Es aumentar nuestra capacidad de tomar buenas decisiones sobre qué vale la pena capturar, durante cuánto tiempo y con qué nivel de detalle.

Al principio probablemente exista una cuota inevitable de intuición. No conocemos todas las preguntas que el negocio va a hacer dentro de dos años.

Pero podemos prestar especial atención a la información que suele ser difícil o imposible de reconstruir después: cambios de estado, eventos, timestamps, contexto de una decisión, versiones de reglas o modelos y relaciones entre entidades.

Después podremos decidir qué conservar y durante cuánto tiempo.

Capturar y preservar no necesariamente tienen que ser la misma decisión.

La IA hace que esta discusión sea todavía más importante

Estamos entrando, además, en un momento particular.

Cada vez tenemos mejores herramientas para procesar grandes volúmenes de información, encontrar patrones y trabajar con datos menos estructurados. Al mismo tiempo, los coding agents y el vibe coding están reduciendo muchísimo el esfuerzo necesario para construir determinadas funcionalidades.

Eso puede producir una consecuencia interesante.

Si necesitamos dedicar menos energía a escribir mecánicamente cada línea de código, podemos dedicar más energía a pensar qué estamos construyendo, por qué y qué queremos obtener de ello.

Por eso creo que las specs van a ganar importancia.

Una especificación podría decir simplemente:

Cuando ocurra X, cambiar el estado a Y.

Pero una buena spec debería llevarnos un poco más lejos.

¿Qué evento queremos registrar? ¿Cuándo ocurrió? ¿Qué provocó la transición? ¿Qué información necesitamos conservar? ¿Cómo vamos a medir si la funcionalidad produjo el resultado esperado? ¿Qué vamos a querer analizar sobre este proceso dentro de seis meses?

La IA puede ayudarnos a construir más rápido.

Pero construir más rápido también aumenta la importancia de decidir bien qué conocimiento queremos que nuestros sistemas produzcan.

Diseñar software también es diseñar evidencia

En el artículo anterior planteaba que ser data-driven no significa tener respuestas para todo.

Significa construir un método que nos permita formular hipótesis, probarlas y descubrir rápidamente cuándo estamos equivocados.

Pero para poder hacer eso existe una condición previa:

necesitamos evidencia.

Si queremos experimentar con un proceso, necesitamos poder medirlo. Si queremos entender un comportamiento, necesitamos haber capturado sus señales. Si queremos comparar una decisión con otra, necesitamos conocer qué ocurrió en cada momento. Si queremos entrenar un modelo, necesitamos historia.

Por eso cada vez pienso menos el diseño de datos como algo que ocurre después de desarrollar un producto.

Diseñar software también es diseñar la evidencia que mañana vamos a tener disponible para entender si ese software funcionó.

Y eso cambia bastante dónde debería comenzar una estrategia de datos.

No comienza cuando conectamos el producto al warehouse.

Comienza cuando decidimos qué va a registrar el producto.

La historia que no guardamos

Volvamos al ejemplo del principio.

Teníamos las solicitudes. Teníamos el estado actual. Teníamos un sistema funcionando.

Lo que no teníamos era la historia.

Y sin esa historia no podíamos responder una pregunta que nadie había imaginado cuando se construyó el sistema.

Podíamos modificarlo para empezar a guardar las transiciones desde ese momento. Lo que no podíamos hacer era reconstruir perfectamente todo lo que ya había ocurrido.

Esa experiencia me dejó una pregunta que intento incorporar mucho antes en el desarrollo:

¿Qué vamos a querer aprender de esto cuando lleve un año funcionando?

No siempre vamos a acertar.

Vamos a guardar cosas que nunca utilizaremos y seguramente vamos a olvidarnos de otras que después hubiésemos querido tener.

El objetivo no es predecir todas las preguntas futuras.

Es reconocer que la capacidad de aprender mañana también se diseña hoy.

Podemos cambiar una arquitectura. Podemos refactorizar código. Podemos reemplazar una tecnología.

Pero hay algo mucho más difícil de recuperar:

La historia que decidimos no guardar.

Fuentes y lecturas

  • Microsoft Azure Architecture Center — Event Sourcing pattern. Referencia sobre conservación del historial de cambios mediante eventos y los trade-offs asociados a este patrón arquitectónico.
  • NIST Research Data Framework (RDaF). Marco sobre gestión del ciclo de vida de los datos, metadata, procedencia, preservación, uso y reutilización.
  • NIST — Data Provenance. Concepto de procedencia del dato y conservación de información sobre su origen y transformaciones.