It started, the way these things usually do, with a maintenance problem. A quick-service restaurant chain with a few thousand sites began pulling data off the equipment in its kitchens: fridge and freezer temperatures, fryer and grill status, oven cycles, drive-thru timers, and the order and payment stream from every till, all reporting continuously from each restaurant. The first goal was narrow and sensible, to stop losing stock to a fridge that failed overnight and to stop losing lunch service to a fryer that went down at noon. It worked, so the same feeds were turned toward speed of service, which found real money in the drive-thru, and then toward labour scheduling and demand forecasting, which found more. Somewhere in that sequence the data stopped being a maintenance tool and turned into something else. By the time anyone gave it a name, the telemetry coming off the estate was arguably the most strategically valuable asset the company owned, and the finance team first learned this from a single line in a board paper. Nobody had set out to build a strategic asset. They had built a monitoring feed, and it had grown into one while no one was managing it as such.
That progression, from by-product to primary asset, is now playing out across quick-service restaurants, retail, media, financial services, and increasingly healthcare. The signal a business throws off while doing its actual work, its operational telemetry, is becoming one of the things the business is most valuable for knowing. The trouble is that almost nobody’s data infrastructure was built for that. It was built for telemetry as exhaust: cheap to store, quick to sample, safe to discard. This post follows the restaurant chain’s estate through each stage of the shift, because the architecture that has to change is easiest to see through the thing that changed it.
The telemetry moment
Go back to the moment the data changed jobs. For the first years of the programme, the restaurant telemetry lived where operational signals always live, in the hands of the people who keep the sites running. It fed equipment-monitoring portals and a facilities dashboard, it was watched by store operations and maintenance teams, and it answered exactly one kind of question, which was whether a given restaurant was operating normally right now. That was the job, and the setup did it well.
The moment arrived when a different kind of question needed the same data. Someone at the centre wanted to lower cost per order and lift speed of service across the whole estate, which meant understanding how equipment health, prep times, drive-thru flow, and staffing interacted across thousands of restaurants over months, not one site over one shift. The data to answer that existed. It had been flowing for years. But it was trapped in systems built to alarm on a single failing appliance, not to be queried across time or joined with rosters, weather, promotions, and sales. The question was strategic and the data was operational, and the gap between them was pure architecture. Answering it took a one-off extraction that nobody owned: store operations had no remit to serve analytics, the analytics team had never been granted access to the equipment systems, and the data had to be lifted out by hand, cleaned, and stitched to context that lived in four other places. The answer, when it eventually came, was good enough to prove the point and slow enough to prove the problem.
This is the general shape of the telemetry moment, and it recurs in every business that runs on instrumented operations. It is the first time an operational feed is asked a question its owners never anticipated, and the data turns out to be present but unusable in the form it was kept. The signal was always valuable. It was simply filed under maintenance.
How telemetry got demoted
To understand why the architecture is wrong, look at how operational telemetry came to be treated as exhaust in the first place, because the demotion was deliberate and, at the time, correct. For years the entire purpose of this data was to answer one question in the present tense: is this site behaving normally. Everything about how it was handled followed from that. It was captured at high frequency, kept for a short window, downsampled or discarded once the window passed, and stored in store controllers and equipment-vendor portals tuned for live monitoring rather than historical analysis.
It was also walled off. The equipment feeds lived on the operational side of each restaurant, owned by facilities and store operations, deliberately kept apart from the corporate systems for sound reliability and payment-security reasons. This was industrial IoT in a commercial-kitchen setting, connected refrigeration, cooking equipment, and point-of-sale hardware, and it was governed as site infrastructure, not as information. The data engineering teams who build analytical platforms mostly never saw it, and had no reason to expect to.
None of that was a mistake. It was the right design for the question being asked. Storing every reading forever, at full fidelity, in a warehouse an analyst could reach, would have been waste when the only consumer was a technician checking whether a freezer was holding temperature. The demotion of telemetry to a disposable by-product was a rational response to its narrow use. It stopped being rational the moment the use widened, and the architecture did not notice the moment had come.
What it is now
What the chain discovered is that the same feed, unchanged at the sensor, had become several different things at once. It was training data for the models that forecast demand and optimise labour. It was the evidence base for menu, pricing, and new-site selection. It fed supply-chain replenishment and gave the food-safety team continuous proof that the cold chain had held, rather than a clipboard checked twice a day. The restaurants were doing the same job they always had. The telemetry had become the raw material of data-driven operations across the business.
The precise word for what it had become is a data product: a dataset deliberately built to be consumed by people and systems beyond the team that produced it, with the discoverability, quality, and reliability that implies. The idea that data should be treated as a product with real consumers, rather than as a by-product of the system that emits it, is one of the load-bearing principles of the data mesh approach (Dehghani, 2022), and operational telemetry is where it now bites hardest. The shift is from operational data as a means to an operational end, to operational data as an asset with its own standing, its own consumers, and, in a growing number of cases, its own external market. Some chains now benchmark across franchisees or sell insight derived from their estates, and the years of history behind those numbers are a moat a competitor cannot replicate quickly. The exhaust became inventory.
The data architecture this actually requires
Once telemetry is a strategic asset, the infrastructure built for exhaust starts failing in specific, predictable ways, and the fixes define the telemetry architecture the asset actually needs. The first is retention and fidelity. A system that downsamples readings to death because storage was once precious destroys exactly the history a model needs. The asset requires purpose-built time-series data storage that keeps long, high-resolution history and supports both real-time analytics on the live stream and retrospective analysis across years. The elastic capacity for that, without overbuilding a private estate for a load that spikes at every lunch rush and subsides, is one of the reasons this work tends to land on cloud foundations, which is a large part of what Sakura’s Cloud practice builds underneath it.
The second is movement and contract. The data has to flow off tens of thousands of devices across the estate into an IoT data platform that can absorb millions of events without dropping them, and it has to arrive with a schema, an owner, and a quality guarantee. Treating each telemetry stream as a data product means giving it a contract and an owner responsible for it, so the analysts and models downstream can find it and trust it rather than reverse-engineering it every time. It also means separating the two clocks the asset runs on: a streaming path that carries the live signal for real-time analytics and alerting within seconds, and a batch path that lands the full-fidelity history the models and long-range analysis depend on. Systems built only for monitoring tend to have the first and not the second, which is why the historical asset, when someone finally reaches for it, so often turns out to be full of holes. This is where telemetry crosses back into the ground the earlier posts in this series covered, because a data product without governed provenance is not one you can build decisions on (see Part 3).
The third is security, and it is the one most often underestimated. The instant operational telemetry leaves the store network to feed corporate analytics, the separation that protected the restaurant environment, where connected kitchen equipment sits alongside payment terminals, is breached, and the attack surface widens in both directions. Piping equipment and till data into a lake without rebuilding that boundary is how an analytics convenience becomes a path into store systems. The discipline for doing it properly is well established in the operational-technology security standards (ISA/IEC, n.d.), and getting the segmentation, identity, and monitoring right is exactly the kind of work Sakura’s Security practice does at the seam between operations and IT.
Who is doing it well
The organisations getting this right look similar across very different industries. The leading quick-service and retail chains treat their store and equipment telemetry as products with owners and service levels rather than as monitoring feeds, and keep the long, high-fidelity history that demand forecasting and cold-chain assurance need. Grocers do the same with shelf, refrigeration, and supply-chain signals. The pattern extends well beyond the shop floor: media businesses treat playback and engagement telemetry as a governed audience asset, and financial services firms treat platform and transaction telemetry the same way. The common thread is not the industry or the tooling. It is that the telemetry was given an owner, kept at fidelity, secured across the operations-to-IT boundary, and made discoverable across the business.
The tell of doing it badly is just as consistent. The data still lives only where it was produced, every strategic question that needs it becomes a fresh extraction project, and the value everyone can see in the signal never quite becomes value anyone can use. In each case where it goes right, the change was organisational as much as technical: someone was made accountable for the telemetry as a product, with a budget and a service level, instead of leaving it as a shared cost that nobody owned and everybody assumed. The chain in this story eventually got there too, but only after the board paper, which is a more expensive way to find out than deciding it in advance.
The organisations pulling ahead engineer the signal their operations throw off with intent, giving it an owner, a contract, and a deliberate place in the architecture, which is the work Sakura’s Data & AI practice does when it turns raw operational telemetry into data products the whole business can rely on.
References
Dehghani, Z., 2022. Data Mesh: Delivering Data-Driven Value at Scale. Sebastopol, CA: O’Reilly Media. Available at: https://www.oreilly.com/library/view/data-mesh/9781492092384/ [Accessed 8 July 2026].
ISA/IEC, n.d. ISA/IEC 62443 Series of Standards: Security for Industrial Automation and Control Systems. International Society of Automation and International Electrotechnical Commission. Available at: https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards [Accessed 8 July 2026].