Arquitectura de datos: qué conviene a una operación mediana

Un almacén de datos guarda información ya estructurada y modelada para responder preguntas conocidas. Un lago guarda datos en su forma original para preguntas que aún no se han formulado. La decisión entre ambos no depende del volumen sino de qué tan definidas están las preguntas que la organización necesita responder.

A continuación: qué resuelve cada modelo, por qué el volumen no decide, qué cuesta realmente cada opción, cómo se elige sin sobredimensionar y qué construir primero.

La conversación sobre arquitectura de datos suele llegar con nombres de producto antes que con preguntas de negocio, y eso produce decisiones caras. Conviene empezar por lo que cada modelo resuelve, que es más sencillo de lo que la terminología sugiere.

Y conviene decir algo incómodo desde el principio: buena parte de las operaciones medianas de la región no necesita ninguna de las dos cosas todavía. Necesita que sus sistemas transaccionales expongan datos confiables y una capa de consulta ordenada encima.

Qué resuelve cada modelo

El almacén resuelve la pregunta repetida. Se define un modelo —clientes, ventas, productos, tiempo—, se transforma el dato al entrar y se consulta con rapidez y consistencia. Su fortaleza es que la respuesta a la misma pregunta es siempre la misma, y esa es exactamente la propiedad que hace falta para gestionar.

El lago resuelve la pregunta desconocida. Se guarda el dato como llegó, sin decidir de antemano cómo se usará, y se transforma en el momento de analizarlo. Su fortaleza es la flexibilidad; su costo es que sin gobierno se convierte rápidamente en un depósito donde nadie encuentra nada.

Los dos modelos no compiten: responden a necesidades distintas. El error frecuente es adoptar el segundo esperando los beneficios del primero.

Por qué el volumen no decide

La justificación que más se escucha es el crecimiento del volumen, y suele ser la menos relevante. Las herramientas actuales manejan sin dificultad los volúmenes de una operación mediana, incluso los que parecen grandes desde dentro.

Lo que sí decide es la variedad y la incertidumbre. Si los datos vienen de tres sistemas conocidos y las preguntas son de gestión —ventas, cartera, inventario—, un almacén bien modelado es más barato, más rápido y mucho más fácil de gobernar.

Si en cambio hay datos de origen diverso y poco estructurado —registros de actividad, sensores, texto libre— y las preguntas todavía se están formulando, la flexibilidad de un lago justifica su costo de gobierno.

Qué cuesta realmente cada opción

El costo visible es infraestructura y licencias, y es el menor de los tres.

El segundo es el modelado. Un almacén exige decidir cómo se representa el negocio, y esa decisión consume tiempo de gente que conoce el negocio, no solo de gente técnica. Es la inversión que más rinde y la que más se subestima.

El tercero es el gobierno continuo. Ambos modelos se degradan sin mantenimiento: el almacén cuando el negocio cambia y el modelo no, el lago cuando se acumulan datos que nadie catalogó. El segundo se degrada más rápido y de forma menos visible.

Una regla práctica: si no hay alguien con tiempo asignado para gobernar el resultado, el modelo más simple es el correcto, sea cual sea el problema.

Cómo se elige sin sobredimensionar

Con tres preguntas. ¿Las preguntas están definidas? Si el negocio sabe qué necesita responder, un almacén. Si está explorando, un lago o directamente un entorno de análisis sobre copias controladas.

¿Cuántas fuentes hay y qué tan estables son? Pocas y estables favorecen el modelado previo. Muchas y cambiantes lo penalizan, porque cada cambio obliga a rehacer transformaciones.

¿Quién va a mantenerlo? La respuesta honesta a esta pregunta descarta más arquitecturas que las otras dos juntas.

Cuando el dato debe permanecer en el país, la elección incluye además dónde se aloja: conviene revisar las regiones disponibles para Colombia y México antes de comprometer una plataforma, porque no todos los servicios están presentes en todas ellas.

Qué construir primero, en cualquiera de los dos casos

Tres cosas, en este orden, y ninguna depende de la arquitectura elegida.

Primero, una fuente confiable para las cifras que ya se usan. Antes de habilitar preguntas nuevas conviene que las actuales tengan una sola respuesta. Es el trabajo menos atractivo y el que desbloquea todo lo demás.

Segundo, la trazabilidad del origen: poder decir de qué sistema y de qué extracción salió cada cifra. Cuesta poco al construir y es imposible de reconstruir después.

Tercero, el control de acceso, que en Colombia y México está condicionado por la norma de protección de datos —Habeas Data (Ley 1581) y la LFPDPPP— cuando el conjunto contiene información personal. Es una restricción de diseño, no un ajuste posterior.

La opción que casi nadie considera

Entre no tener nada y construir una plataforma hay un punto intermedio que resuelve más casos de los que se admite: una réplica de solo lectura de los sistemas transaccionales, con una capa de vistas encima que traduzca las tablas al vocabulario del negocio.

No es elegante y tiene límites claros: no sirve para histórico profundo, no consolida bien fuentes muy distintas, y las consultas pesadas pueden competir con la operación si la réplica no está bien aislada. Dentro de esos límites, entrega informes confiables en semanas y con un costo de gobierno mínimo.

La razón para considerarlo no es el ahorro sino el aprendizaje. Seis meses operando así revelan qué preguntas hace realmente el negocio, y esa información vale más para diseñar el modelo definitivo que cualquier taller de requisitos. Se construye la arquitectura sabiendo, en lugar de suponiendo.

El error que más cuesta deshacer

Copiar todo «por si acaso» a un entorno analítico. Es la decisión que más rápido genera valor aparente y más difícil resulta de revertir: al cabo de dos años hay copias del maestro de clientes en varios lugares, cada una con sus propios consumidores, y nadie sabe cuántas hay.

La alternativa no es prohibir el acceso sino acordar dónde vive el dato identificable y trabajar contra esa fuente. Lo que se replique a entornos de análisis debería salir ya seudonimizado, salvo que el caso justifique lo contrario y alguien lo autorice explícitamente.

Cómo se decide con evidencia

Con un inventario de fuentes, un mapa de las preguntas que el negocio necesita responder y una evaluación honesta de quién va a sostener el resultado. Es un ejercicio de semanas, no de meses.

Un assessment de madurez de datos y analítica produce ese punto de partida calificando origen, calidad, gobierno, modelo y consumo por separado, que es lo que permite invertir en el tramo débil en lugar de en el que se sospechaba. De ahí sale el plan de analítica, y cuando la decisión toca dónde reside el dato, se coordina con la de nube en lugar de tomarse por separado.

Preguntas frecuentes

¿Qué diferencia hay entre un almacén y un lago de datos?

El almacén guarda información ya modelada para responder preguntas conocidas con consistencia. El lago guarda el dato en su forma original para preguntas que aún no se han formulado. No compiten: resuelven necesidades distintas.

¿El volumen de datos decide la arquitectura?

Rara vez. Las herramientas actuales manejan sin dificultad los volúmenes de una operación mediana. Lo que decide es la variedad de fuentes y si las preguntas están definidas o todavía se están formulando.

¿Qué es lo que más se subestima al presupuestar?

El modelado y el gobierno continuo. El modelado consume tiempo de gente que conoce el negocio, no solo de perfiles técnicos; el gobierno es lo que evita que el resultado se degrade, y el lago se degrada más rápido y de forma menos visible.

¿Qué conviene construir primero?

Una fuente confiable para las cifras que ya se usan, la trazabilidad del origen de cada cifra, y el control de acceso. Ninguna de las tres depende de la arquitectura elegida.

¿Cuál es el error más difícil de revertir?

Copiar todo a un entorno analítico por si acaso. A los dos años hay copias del maestro de clientes en varios lugares con consumidores propios, y nadie sabe cuántas existen.

¿Qué pasa si el dato no puede salir del país?

Condiciona la plataforma: hay que revisar qué regiones están disponibles para Colombia y México y qué servicios existen en cada una, antes de comprometer una arquitectura. No todos los servicios están presentes en todas las regiones.