Think of IoT as Structure
2026-03-01
A framework for breaking down IoT systems into layers — and why it matters for design.
Introduction
This article is written for those who design or architect IoT systems.
Anyone who has sat through an IoT discussion knows how quickly it can splinter. One person is talking about devices. Another is talking about the network. A third is talking about the cloud. No one is wrong — they're just looking at different layers. And without a shared frame, the conversation goes nowhere.
This article offers one way to fix that: think about IoT as structure.
The Core Idea
An IoT service becomes easier to reason about when you treat it as a set of layers — and understand how those layers connect.
Three Building Blocks
At its foundation, IoT can be broken into three components:
| Layer | Role |
|---|---|
| Device |
generates data at the edge |
Network acting as part of the data pipeline |
moves data, including communication control, relay, and protocol translation |
| Cloud |
receives data and makes it usable |
Each role is straightforward on its own. The complexity emerges from how they interact.
The Three Layers of IoT
On top of these components sit two more concerns: the data pipeline and the data structure / insights layer.
Diagram: IoT works as a flow, not just a stack of layers
The data pipeline is the end-to-end mechanism for collecting, transforming, and forwarding data. And there's a key implication: a service isn't complete until data reaches the cloud in a usable form.
The Pipeline Is the Hard Part
Having a device and a cloud endpoint doesn't mean you have a working IoT system. The data pipeline — everything in between — is where most of the real design decisions live.
Consider the difference between:
- Sending raw sensor data directly to the cloud
- Aggregating and transforming data at a gateway before forwarding it
Both involve "networking," but the architecture and tradeoffs are fundamentally different.
Why the Pipeline Matters
Devices come with real constraints:
- Battery life
- Physical location and signal conditions
- Transmission frequency limits
A smart meter that syncs once a month and an EV charger that needs a persistent connection cannot share the same pipeline design. Forcing them to would mean compromising one — or both.
What Good Pipeline Design Looks Like
The goal is to match the data transport to the characteristics of the device — not to default to whatever worked last time.
Key decisions include:
- Upload frequency
- Communication protocol
- Relay strategy: Direct / Gateway / Edge processing
End-to-end direct transmission is sometimes the right answer — but not always. In many cases, introducing a relay component that accounts for network characteristics is the more practical approach.
Direct end-to-end transmission
Transmission via a relay component
IoT Is a Combination Problem
None of the components described here are novel. Devices, networks, clouds, and data pipelines are all built on established technology.
What actually requires judgment is knowing which combination is right for the problem in front of you.
One Common Pitfall
It's tempting to copy a previous architecture. Resist it.
If the device characteristics, data profile, or transmission frequency differ from the original context, the optimal pipeline will differ too. An architecture that worked well in one deployment can be a poor fit in another.
Where Value Is Actually Created
Once the structural layers are clear, a more important question comes into view:
- Data structure — how is the data modeled and organized?
- Insights — what is the data actually used for?
In most IoT systems, this is where the real value is generated — and where design decisions either pay off or fall short.
Summary
IoT can look complex from the outside. But it becomes manageable when you decompose it:
- Device
- Network (including the data pipeline)
- Cloud
The complexity isn't inherent to IoT — it usually comes from not having a clear picture of the structure and how data flows through it.
The key design questions are:
- Which architecture fits this use case?
- How should data move through the system?
Those two questions — which combination of existing technology to use, and how to handle the data — are where good IoT design begins and ends.
Closing
IoT isn't fundamentally complicated. It's often just under-structured in how people think and talk about it.
If this framework gives you a useful lens for design discussions or architecture reviews, I'd call that a win. If you're working through similar challenges, feel free to reach out — comments and conversation are welcome.
Next up: a closer look at MQTT and CoAP as representative data pipeline protocols, and how to choose between them.