No toda obra necesita el proveedor de emergencias 🏗️
Hay una creencia instalada en muchos equipos de datos: migrar todo a tiempo real es señal de madurez tecnológica. Piden que cada reporte se actualice al minuto, que cada indicador refleje lo que acaba de pasar. Lo que no se cuestiona es si el negocio realmente toma decisiones a ese ritmo.
El procesamiento por lotes no es una tecnología vieja que hay que reemplazar. Es la herramienta adecuada para decisiones que no necesitan operar al segundo.
El procesamiento por lotes, conocido como batch, agrupa datos y los ejecuta en bloque en un momento programado. El procesamiento en tiempo real, o streaming, actúa sobre cada dato en el instante en que llega. Son herramientas distintas para necesidades distintas.
Una constructora tiene dos tipos de proveedores. Uno entrega cualquier material en 24 horas: costoso, eficiente para emergencias. El otro consolida pedidos semana a semana, agrupa por volumen y entrega en bloque: más económico, predecible, confiable. Para los acabados de cerámica que instalan mañana, el proveedor rápido tiene sentido. Para los bloques, el cemento y las varillas que llegan en toneladas, esperar no es ningún problema.
Un proyecto que le exige al proveedor de emergencias todo lo que necesita, sin distinguir urgencias, termina pagando más sin obtener mejor obra. No toda obra necesita el proveedor de emergencias.
Un reporte mensual de cartera, un cierre contable, el inventario al final del día son procesos donde la precisión importa más que la velocidad. El batch los resuelve con eficiencia y menor costo. El tiempo real tiene sentido para detección de anomalías, monitoreo de equipos o alertas de inventario crítico.
Según IBM, muchas organizaciones usan ambos enfoques dentro de una misma plataforma, asignando cada proceso según la latencia necesaria. El error no es mantener el batch. Es migrar por moda lo que ya funciona, sin revisar qué decisión de negocio cambia con esa inversión.
El equipo que reemplaza un cierre nocturno confiable por un stream que nadie consulta hasta el día siguiente no ganó agilidad. Gastó infraestructura. No toda obra necesita el proveedor de emergencias.
Primero, haga un inventario de sus reportes y clasifíquelos por frecuencia de decisión. Luego, identifique cuáles requieren datos al instante y cuáles funcionan bien con cierres diarios. Después, no reemplace lo que ya opera con confiabilidad sin una razón de negocio clara. Por último, antes de aprobar una migración a tiempo real, pregunte qué decisión concreta no puede esperar hasta el cierre del día.
¿Cuál de sus reportes actuales se actualizaría a tiempo real sin que eso cambie ninguna decisión de negocio? 🏗️
Versión en inglés
Not Every Project Needs the Emergency Vendor 🏗️
There's a belief installed in many data teams: migrating everything to real-time is a sign of technological maturity. They ask for every report to update by the minute, for every indicator to reflect what just happened. What doesn't get questioned is whether the business actually makes decisions at that pace.
Batch processing is not old technology to replace. It's the right tool for decisions that don't need to operate by the second.
Batch processing, known as batch, groups data and executes it in blocks at a scheduled time. Real-time processing, or streaming, acts on each piece of data the instant it arrives. They're different tools for different needs.
A construction company has two types of suppliers. One delivers any material in 24 hours: expensive, efficient for emergencies. The other consolidates orders week by week, groups by volume, and delivers in blocks: more economical, predictable, reliable. For the ceramic finishes being installed tomorrow, the fast supplier makes sense. For blocks, cement, and rebar that arrive in tons, waiting isn't any problem.
A project that demands the emergency supplier provide everything it needs, without distinguishing urgencies, ends up paying more without getting better construction. Not every project needs the emergency vendor.
A monthly portfolio report, an accounting closure, the inventory at end of day are processes where precision matters more than speed. Batch solves them with efficiency and lower cost. Real-time makes sense for anomaly detection, equipment monitoring, or critical inventory alerts.
According to IBM, many organizations use both approaches within the same platform, assigning each process by needed latency. The error is not maintaining batch. It's migrating out of fashion what already works, without reviewing what business decision changes with that investment.
The team that replaces a reliable overnight closure with a stream that no one checks until the next day didn't gain agility. It spent infrastructure. Not every project needs the emergency vendor.
First make an inventory of your reports and classify them by decision frequency. Then identify which require data instantly and which function well with daily closures. Then don't replace what already operates with reliability without a clear business reason. Finally, before approving a migration to real-time, ask what concrete decision can't wait until end of day closure.
Which of your current reports would update to real-time without that changing any business decision? 🏗️