Most analytics discussions begin after the data has already moved.
A transaction reaches a database, a sensor reading reaches a platform, a file lands in storage, and then the familiar work starts: clean it, combine it, model it, analyze it, and turn it into something people can use.
That model makes sense, and in many cases it is exactly what we need.
But there is an assumption hiding inside it: the data has to travel before intelligence can happen.
Edge computing asks a different question.
What if some of the processing happens where the data is created?
That does not mean replacing the cloud, the data warehouse, or the central analytics platform. It means deciding whether every piece of data really needs to make the full journey before the system can understand it, filter it, validate it, or react to it.
The original carousel describes edge computing simply: processing happens near the data source instead of relying only on a central server.
That definition is short, but the architectural consequences can be significant.
The easiest way to understand edge computing
Imagine a supermarket.
A modern store may have point-of-sale terminals, scanners, shelf sensors, refrigeration equipment, cameras, handheld devices, and other systems producing data throughout the day. Some of that information belongs in a central analytics platform because management needs to compare stores, track sales, understand inventory movement, study customer behavior, and see performance over time.
But not everything needs to wait for that central platform.
Suppose a freezer starts moving outside its safe temperature range. The important question at that moment is not how the freezer compares with the other 200 freezers in the company. Someone needs to know that this freezer has a problem now.
A local device can detect the condition immediately, while the event is still sent to the central system afterward for reporting, history, maintenance analysis, and management visibility.
Both levels matter.
The local system handles the immediate situation. The central system keeps the wider business picture.
That is edge computing in practical terms.
Why send less data when you can send better data?
There is a tendency in data architecture to treat collection as the goal: capture everything first and decide what matters later.
Sometimes that is reasonable. Sometimes it is expensive and unnecessary.
Consider a machine producing thousands of sensor readings every minute. If almost all of those readings simply say that the machine is operating normally, sending every raw event to a central platform may not add much value.
An edge process could inspect those readings locally and send a more useful result: the normal operating summary, a few unusual spikes, a sustained temperature change, and perhaps an alert when something crosses an agreed threshold.
The central platform still receives the information it needs for historical analysis. It simply does not have to receive every raw signal before something useful can happen.
This is one reason edge computing is associated with lower latency, reduced bandwidth use, and greater resilience in environments where an immediate response matters.
And those benefits are connected.
If less unnecessary data has to travel, bandwidth pressure falls. If some processing can happen locally, the system does not always have to wait for a round trip to a remote platform. If the network becomes unavailable, certain local functions may still continue rather than becoming useless until connectivity returns.
Sometimes a few seconds are irrelevant. Sometimes they are the whole problem.
Latency sounds like an infrastructure term until you put it inside a real situation.
A finance team reviewing last month's profitability does not care whether a calculation took another 200 milliseconds.
A connected vehicle responding to something directly in front of it does.
The same applies in factories, retail environments, smart cameras, mobile applications, and other systems where something physical or operational is happening in real time. These are among the use cases highlighted in the original carousel.
The point is not that every application in those areas should use edge computing.
The point is that the value of central processing changes when the cost of waiting becomes important.
If the decision can comfortably wait, central processing may remain the simpler option.
If the decision cannot wait, the architecture needs another answer.
Where edge computing starts making sense
There are four situations where the case for local processing becomes much easier to understand: real-time decisions, very large data streams, unreliable connectivity, and situations where some data should remain local for privacy reasons. These are also the four fit conditions identified in the carousel.
Take connectivity.
A piece of equipment operating at a remote site may lose its connection for several minutes. If every useful action depends on continuous access to a central system, the equipment becomes dependent on something it cannot control.
Local processing can allow selected functions to continue while the connection is unavailable, then synchronize the information that needs to travel once communication is restored.
Now take data volume.
A smart camera may generate far more raw data than a business actually needs to keep. Processing near the camera can allow the system to identify an event or extract useful information without automatically treating the full raw stream as something that belongs in the analytical platform.
The question changes from "How do we move all of this data?" to "What information do we actually need to move?"
That is a much better architectural question.
This matters to Business Intelligence more than it first appears
At first glance, edge computing can look like an infrastructure topic rather than a BI topic.
After all, BI normally lives farther down the chain. We think about data warehouses, ETL, semantic models, KPIs, reports, dashboards, alerts, and analysis.
But the quality of BI is already being decided before any dashboard opens.
If poor data enters the pipeline, the BI layer inherits the problem.
If thousands of meaningless events enter the platform, someone eventually has to remove the noise.
If an important event reaches the analytical environment too late, the dashboard may describe what happened perfectly while doing nothing for the decision that needed to happen five minutes earlier.
This is where edge computing becomes relevant to BI.
The carousel makes the connection directly: processing closer to the source can improve data quality and help create cleaner, faster, more actionable intelligence.
I would push that idea slightly further.
The real BI value is not simply "faster data."
It is the ability to make better decisions about what becomes analytical data in the first place.
A factory gives us a useful example
Imagine a production machine with several sensors measuring temperature, vibration, pressure, and operating speed.
A traditional architecture might send every reading to the central platform.
That may be necessary if the business genuinely needs every observation. But often, the central analytical system is more interested in patterns, exceptions, trends, and events than in receiving thousands of identical "everything is normal" messages.
An edge layer could handle a portion of the first-stage processing close to the machine.
It might validate readings, reject obviously invalid values, identify a threshold breach, summarize a short operating period, or flag an unusual pattern for immediate attention.
The central platform can then do what it is good at: compare that machine with others, examine the previous six months, connect maintenance activity with production output, identify repeated failures, and show management what is happening across the operation.
The edge sees the moment.
The BI platform sees the story around the moment.
That division of work is much more useful than arguing about which side should "own" the intelligence.
Edge computing does not automatically make an architecture better
This matters because useful technologies often become bad designs when they are applied everywhere.
If a workload is not time-sensitive, connectivity is reliable, data volumes are reasonable, and central processing already works well, adding another processing layer may simply create more things to maintain.
You also have to think about consistency.
When business rules are distributed across many devices or locations, updates can become harder to manage. A centrally controlled calculation is easier to change once than the same logic running in hundreds of places.
And some analysis only makes sense centrally.
A branch can understand what is happening inside that branch. It cannot, by itself, tell management how the entire company is performing.
A machine can detect an immediate condition. It cannot see the full maintenance history of every machine across every facility unless that broader information is brought together somewhere.
So edge computing should not begin with the question, "Where can we use it?"
A better question is:
What problem are we solving by processing this closer to the source?
If there is no strong answer, keeping the architecture simpler is usually the better choice.
Edge and central analytics solve different problems
I do not see edge computing as a replacement for centralized analytics.
They provide different kinds of intelligence.
A local system may know that a machine is overheating right now. The central platform can tell us whether overheating has become more frequent over the last quarter.
A retail device may react to something happening inside one store. The central analytics platform can compare that store with every other location.
A camera may identify an event without uploading an entire video stream. The central system can still collect the resulting events and study patterns across sites and over time.
This is why the argument should not become edge versus cloud, or local versus central.
Most useful architectures will contain a mix.
Some processing belongs close to the source because speed, connectivity, data volume, or privacy makes locality valuable.
Other processing belongs centrally because comparison, history, governance, consolidation, and enterprise-wide analysis require a wider view.
The more interesting question is where intelligence belongs
For years, the default analytical architecture has often been straightforward: move the data first, then work with it.
Edge computing gives us another option.
Maybe the data should be checked before it travels.
Maybe an event should be identified locally.
Maybe the immediate action belongs at the source while the long-term analysis belongs centrally.
Maybe raw data does not need to travel at all, and only the useful result does.
There is no single answer because the decision depends on what the system is trying to achieve.
That is why I see edge computing less as a technology choice and more as an architectural decision about where intelligence should happen.
Central analytics still matters. In many cases, it remains the place where the most valuable business understanding is created.
But intelligence does not always need to wait for the data to arrive there.
Sometimes the smarter design is to let part of the thinking happen where the data is born.