The inexorable increase in competition around the globe has led to an explosion of interest in real-time and near real-time systems.
Yet despite all this understandable attention, many businesses still struggle to define what “real-time” actually means.
A merchandiser at a big box retailer, for example, may want a sales dashboard that is updated several times a day, whereas a marketing manager at a mobile Telco wants the capability to automatically send offers to customers within seconds of them tripping a geo-fence. Her friend in capital markets trading, meanwhile, may have expectations of “real-time” systems that are measured in microseconds.
Since appropriate solutions to these different problems typically require very different architectures, technologies and implementation patterns, knowing which “real-time” we are dealing with really matters.
Before you start, think about your goals
Real-time systems are usually about detecting an event – and then making a smart decision about how to react to it. The Observe-Orient-Decide-Act or “OODA loop” gives us a useful model for the decision-making process. Here are some tips for business leaders about how to minimise confusion when engaging with I.T. at the start of a real-time project:
- Understand how the event that we wish to respond to will be detected. Bear in mind that this can be tough – especially if the “event” we care about is one when something that should happen does not. Or which represents the conjunction of multiple events from across the business.
- Clarify who will be making the decision – man, or machine? Humans have powers of discretion that machines sometimes lack, but are much slower than a silicon-based system, and only able to make decisions one-at-a-time, one-after-another. If we chose to put a human in the loop, we are normally in “please-update-my-dashboard-faster-and-more-often” territory.
- It is important to be clear about decision-latency. Think about how soon after a business event you need to take a decision and then implement it. You also need to understand whether decision-latency and data-latency are the same. Sometimes a good decision can be made now on the basis of older data. But sometimes you need the latest, greatest and most up-to-date information to make the right choices.
- Balance decision-sophistication with data-availability. Do you need to use more, potentially older, data to take a good decision, or can you make a “good enough” decision with less data? Think that through.
Can you win at both ends?
Let’s consider what is required if you want to send a customer an offer in near real-time when she is within half-a-mile of a particular store or outlet. It can be done solely because she has tripped a geo-fence, which means all that is required is the information about where the customer is now.
But you will certainly need access to other data if you want to know if the same offer has been made to her before and how she responded. Or, if you want to know which offers customers with similar patterns of behaviour have responded to an offer in the last six months. That additional data is likely to be stored outside the streaming system.
Providing a more sophisticated and personalised offer to this customer will cost the time it takes to fetch and process that data, so “good”, here, may be the enemy of “fast”. We might need to choose between “OK right now” or “great, a little later”. That trade-off is normally very dependent on use-case, channel and application.
Rigging the game in your favour
Of course, I can try and manipulate the system – by working out beforehand the next-best actions in relation to a variety of different scenarios I can foresee. This is instead of retrieving the underlying data and crunching it in response to events that I have just detected. With this kind of preparation, I can at least try to be fast and good.
But then the price I pay is reduced flexibility and increased complexity. And the decision is based on the data from our previous interactions, not the latest data.
All these options come with different costs and benefits and there is no wrong answer – they are all more or less appropriate in different scenarios. But make sure that you understand your requirements before IT starts evaluating streaming and in-memory technologies for a real-time system.