Revisited from the Foresaw archive. The argument and structure have been updated for this edition.
Where should a computation happen? Close to the device, in a central service, or across both? The answer depends on the work and the constraints rather than a general preference for “edge” or “cloud.”
Placing computation near its inputs can be useful, but it also distributes software, state, and operational responsibility.
Measure the actual delay
Break down the path from an event to a useful response. Network travel may be only one part of the delay; application processing, queues, and device behavior also matter.
Move work only when the change addresses a measured constraint. A local computation cannot repair an unrelated bottleneck in the workflow.
Decide what happens offline
If a device loses connectivity, which decisions can continue locally? Which require coordination with another system? Specify what information becomes stale and how the user or operator will know.
The reconnection path deserves equal attention. Local changes may need reconciliation rather than a simple upload.
Plan the operational model
Distributed devices require a way to deploy updates, observe health, manage access, and recover from failure. Include the environments where physical access is difficult or expensive.
Processing information locally changes where controls must be applied; it does not automatically make the system more secure.
Keep the split understandable
Define a small, clear boundary between local and central responsibilities. Evaluate the full cost of running both sides. Edge architecture earns its place when it makes the complete system more useful within real constraints.
Adapted from “The Power of Edge Computing: Enhancing Performance and Connectivity in the IT Industry.”
First published on Foresaw. Reworked for this edition.