Before You Build Real-Time Analytics, Ask How Fast The Business Needs To Act
Govinda, Senior Manager at Cognizant, has 15 years of expertise in SAP & Non-SAP Data Analytics, delivering innovative BI solutions.
gettyIn one utility transformation program I worked on, “real time” came up so often in reporting discussions that it began to sound like a single requirement. It wasn’t. Operations, billing, payments and finance all wanted fresher data, but the decisions behind those requests were very different.
An operational exception might need attention within minutes. A billing reconciliation report could be more useful after the relevant transactions had been processed and validated. Finance might follow another schedule because completeness, controls and cutoffs mattered more than immediate visibility.
That experience changed the way I discuss real-time analytics. I no longer start by asking how fast the platform can move data. I first ask what decision the data will support, how quickly someone needs to act and what could happen if the information is incomplete.
What surprised me most was how quickly the conversation changed once we stopped using “real time” as a blanket term. Business teams were able to explain which delays actually affected customers or operations and which reports simply needed to be fresher than they were today. That helped us separate true low-latency needs from cases where hourly or daily processing was sufficient.
It also made trade-offs easier to discuss. Instead of debating technology first, we could talk about accuracy, timing, reconciliation and the cost of getting the answer wrong. For me, that was the point where real-time analytics became a business design discussion rather than just a data engineering one.
The acceptable latency depends on the business process.
For a service interruption, equipment alert or failed transaction, seconds or minutes may matter because someone needs enough time to intervene. Other use cases can work well with hourly or intraday updates. Work queues, exception monitoring and demand trends may need to be current without requiring continuous streaming.
Billing, finance and regulatory reporting often have a different priority. A report delivered immediately can be less useful if reversals, adjustments or late-arriving transactions are still missing. In those cases, a controlled daily or period-end view may support a better decision than a faster but incomplete one.
This distinction matters because reducing latency can require adding infrastructure, monitoring, data quality controls and operational support. If the business action doesn’t benefit from the added speed, the technical complexity may be solving the wrong problem.
I’ve seen analytics discussions move quickly toward streaming tools, pipelines and dashboards before the business action is clearly defined. That’s where overengineering can begin.
The same source data can lead to very different designs. An operations team may need an immediate alert when a transaction fails. Management may only need an hourly summary. Finance may need a complete daily position that has passed reconciliation checks.
Calling all three “real-time analytics” hides those differences and creates confusion when a live dashboard and a validated enterprise report show different numbers.
In transactional environments, records don’t always arrive in a clean sequence. Updates, reversals and adjustments can follow the original transaction. Reference data can change. One part of a business event may be available before another. A dashboard can refresh every few seconds and still show an incomplete business picture.
I’ve seen this matter particularly in reporting environments where a business measure may depend on several transactions, statuses and master-data relationships. Moving data faster doesn’t automatically preserve that context.
Low-latency pipelines still need rules for duplicate events, late-arriving records, incomplete transactions and changing business definitions. They also need clear ownership when operational and reconciled reports disagree. Without those controls, faster access can simply produce disagreement sooner.
1. What decision or action will the data trigger?
2. How quickly must someone respond for the information to remain useful?
3. What is the risk of acting before the data is complete or validated?
4. Does the use case require immediate visibility or a trusted and reconciled view?
These questions usually make the architecture choice clearer. Some requirements genuinely call for streaming or event-driven processing. Others fit micro-batch, hourly or scheduled processing better. In some cases, the right answer is a combination: an immediate alert for an exception followed by a validated daily view for reporting and reconciliation.
Once the decision window is clear, the technical discussion becomes much more practical.
Real-time processing makes sense when delay directly affects a customer, revenue, safety or an operational response. Intraday processing can be enough for workload management and emerging trends. Scheduled processing may still be the better choice when completeness, historical consistency or auditability matters more than speed.
Business owners also need to be part of that choice. Technical teams can build low-latency pipelines, but the business has to define how quickly action is required and how much uncertainty is acceptable. Without that agreement, a fast dashboard can still be disconnected from the way the organization actually works.
After working across reporting, data warehousing and cloud analytics programs, I no longer treat “real time” as the final requirement. I treat it as the start of a conversation. I ask what needs to happen, who needs to act and how much time they really have. I also ask whether a faster answer is worth more than a complete one.
For me, that’s the practical test. Real-time analytics earns its complexity when the speed changes the decision. When it doesn’t, a simpler and better controlled design may serve the business better.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
