“Hey, we need that report refreshed more often.”

“What’s the lowest latency we can get? We know there’ve been updates in the last hour, but our dashboard doesn’t show them.”

If you’re getting these types of questions, you’ve likely fallen for a trap. You are almost certainly doing operational reporting from your analytics system. While you haven’t broken any laws, the constraints subtly placed on you have the possibility of tanking your analytics system.

How will that happen? By merging SLAs of operational reporting onto an existing analytics system.

Operational Reporting: A typical operational report will answer a question like this: How many widgets of type ‘X’ do we have in warehouse ‘Y’? Or, how many customers does sales rep ‘X’ have assigned to them?

The latency requirements are not trivial here. If an operator needs to know how many widgets are in the warehouse, they need to know the up-to-date number. Knowing what it was four hours ago and that it may have changed makes the data useless.

For operational purposes, only recent data is needed. Knowing that 15 months ago we had 12 of widget ‘X’ is not something an operator will care about.

Operational reports typically require 100% accuracy. For the widget example, if I plan to ship 12 of them, and the system shows that there are 12 in stock, and I go check and there are only 10, my operational workflow is broken.

Analytical Reporting has entirely different requirements. A typical report would show something like ‘sales trends by region per quarter’ or ‘on-hand inventory trends by month.’

Acceptable latency is much higher. If you’re viewing quarterly numbers, you aren’t going to be caring about activity in the last fifteen minutes. Changing the numbers while you’re working on the report could even be considered a bug.

The span of time is much larger for analytical reports. The time frame of data is typically measured in months, at the smallest all the way up to years being fairly common. This will require much more processing time to generate the underlying data sets.

The accuracy requirements may be fuzzier as well. One VP might consider transfers to a particular company be considered sales, where another VP doesn’t. Some might want the booking date instead of the invoice date. If any of these change the report is erroneously considered ‘inaccurate.’ Analytics data may infer information based on available data, and getting information that’s “close enough” might give enough insight to be useful. This would be heresy in operational reporting.

In this situation, the trap is to create a system with analytical reporting needs and SLA’s, and sprinkling in a few operational reports. Even if technically possible, refreshing your yearly sales numbers every 15 minutes is a massive waste of resources. You’ll almost certainly be unable to meet the operations requirements.

These two use cases are best off treated like separate projects with separate requirements.