Real-time is a fallacy. I mean, real real-time is a fallacy. No mater how fast it executes, no matter how optimized it is, no matter how low in the stack it resides, code always takes time to run. Therefore, there is always a lag between the input and the output, between the action and the reaction.
The question then becomes: how to shorten this lag, make it as unnoticeable and as unimpactful as possible? Defense systems, aviation, robotics, and medical equipment have been the first to benefit from advances in real-time computing. In the fly-by-the-wire airplanes of today, you don't want the signal to increase thrust or move the rudder to take any longer than it did when this same signal was transmitted by rods and cables. In the self-driving cars of tomorrow, emergency braking for pedestrians needs to happen now -- not in one second, not even in one tenth of a second.
More and more, short -- as in really short -- response times are also needed by certain business applications. Most of the trading on today's stock or currency exchanges is not only computerized, it is also entirely automated. Computers measure spreads and react to minuscule differences, but it is a race, for only the computer that reacts the fastest wins.
However, when putting aside trading systems, real time becomes much less of an issue. When a business executive asks for "real-time data," he usually means he does not want to wait for the end-of-month report, or even for the overnight data extraction, to get access to fresh reports and dashboard. A business transaction that "just occurred" needs to show up on a refreshed report in a "reasonable amount of time". The trick here is to define "reasonable," a highly subjective element. For most applications, waiting for a few minutes is perfectly reasonable. For a stressed-out executive, the kind who refreshes emails on their cellphones all the time, "reasonable" may mean every 15 seconds. And even that would be a stretch.
After all, if the truck leaves the warehouse once a day, what is the point in refreshing the loading manifesto every minute? And if staffing planning is determined a month in advance, an hourly update of vacation requests and sick leaves won't be very helpful.
There is actually a way to define real time: Real-time data provides its consumer with the ability to influence and impact the outcome of a process that is currently under way. A refreshed loading manifesto, updated inventory, initial results of a campaign, can drive adjustments that make the current operation more efficient.
Real-time must be opposed to "post-mortem" -- which also analyze and measure efficiency, but with the purpose of making the process work better next time.
There is actually an even better term than real-time. From now on, let's break free from the fallacy of real-time data. Let's work with right-time data.
This article is published as part of the IDG Contributor Network. Want to Join?