Arquitectura de datos para empresas que no son grandes

Buena parte del material sobre arquitectura de datos está escrito para empresas con petabytes y equipos dedicados. Para una empresa de tamaño medio, aplicar ese recetario suele producir una plataforma cara que nadie usa.

El problema real casi nunca es el volumen

Es la dispersión. Cuatro sistemas que no se hablan generan un problema de datos mucho antes de que el volumen sea relevante: el ERP tiene una versión del cliente, el punto de venta otra, y el área comercial una tercera en su propio archivo.

Empezar por la pregunta, no por la herramienta

La forma más rápida de acotar el alcance es listar las preguntas que hoy no se pueden responder sin trabajo manual. Ese listado define qué fuentes se integran primero y qué se puede postergar sin costo.

• ¿Cuál es el margen real por línea de producto, incluyendo devoluciones?
• ¿Qué rota y qué está inmovilizado, por sucursal?
• ¿Cuánto tiempo pasa entre el pedido y la entrega, y dónde se pierde?

Una arquitectura suficiente

Para este tamaño, una base analítica separada de la operativa, con cargas programadas y un modelo dimensional simple, resuelve la mayor parte de los casos. El orden importa más que la tecnología.

• Capa cruda: copia fiel de la fuente, sin transformar. Permite reprocesar sin volver a extraer.
• Capa limpia: tipos, nombres y reglas de negocio aplicadas una sola vez.
• Capa de consumo: tablas pensadas para responder preguntas, no para reflejar el sistema origen.

La métrica se define una vez, en la capa de datos. Si cada tablero la calcula a su manera, el problema vuelve.

Escalar a un lakehouse, streaming o procesamiento distribuido es una decisión posterior, y se toma cuando aparece una restricción concreta que la justifique. Tomarla antes es pagar complejidad por adelantado.