What if everything people think they know about IoT is only the surface?
Most conversations about the Internet of Things begin with sensors. They end with dashboards. Somewhere in the middle, people assume the magic just happens on its own. But between the sensor that reads temperature in a factory and the chart that appears on a manager’s screen, there is a complex architecture doing the heavy lifting. And at the centre of that architecture sits something that most people cannot name, let alone describe: the IoT platform.
This is not a niche technical discussion. Getting this wrong has real consequences. Organisations have invested in hardware, deployed hundreds of devices, and still found themselves drowning in data they cannot act on. The reason, more often than not, is that nobody built the right foundation beneath it all.
The Seven-Layer Problem Everyone Ignores
Networking engineers will recognise the OSI model. It stands for Open Systems Interconnection, and it is a conceptual framework that breaks down how data travels from one point to another across a network. The model has seven layers, each with a distinct role, from the physical cables at Layer 1 all the way up to the application interface at Layer 7.
What most IoT practitioners miss is that the IoT stack maps reasonably well onto this model. Understanding where each component lives helps explain why an IoT platform is not just another piece of software. But it also requires an honest admission: the OSI model was designed for network communication, not application architecture. Mapping IoT onto it is a useful teaching tool, not a strict blueprint. The higher layers in particular, Layers 5, 6, and 7, are frequently collapsed in real-world implementations and treated as a single application concern.
At the bottom sits the physical world: sensors, actuators, and embedded devices generating readings. These correspond to Layer 1, the Physical Layer. The signals those devices transmit move through connectivity protocols at Layers 2 and 3, whether that is Bluetooth, Zigbee, Wi-Fi, LoRaWAN, or cellular. By the time data reaches Layer 4, the Transport Layer, TCP and UDP take over, breaking data into packets and routing them with reliability guarantees. An IoT platform does not manage any of this directly. The underlying OS and network stack handle Layers 1 through 4 transparently.
Layer 5, the Session Layer, is where persistent connections are established and maintained. MQTT, one of the most common IoT protocols, manages long-lived sessions between devices and a broker. The platform sits on top of that broker, consuming what arrives through it. Layer 6, the Presentation Layer, is where data encoding and serialisation happen: JSON, XML, Protobuf, CBOR. The platform is responsible for deserialising and normalising those incoming payloads into a consistent structure. Both of these are real concerns for an IoT platform, but they are not where most of its work lives.
The bulk of what an IoT platform actually does sits at Layer 7, the Application Layer. The device registry, the rule engine, the APIs, the data storage and retrieval logic, the authentication and access control systems: all of this is application-level work. This is where end-user software and downstream systems connect. Dashboards. Mobile apps. Business intelligence tools. ERP integrations. The things people see and act on.
The most precise answer to where an IoT platform lives is this: it is a Layer 7 application that draws on Layer 5 and Layer 6 characteristics, and sits entirely above the networking layers it relies on but does not control. Saying it starts at Layer 4 or is confined to Layers 5 and 6 both miss the point. A platform that only managed sessions and serialised data would be a message broker with a parser attached, not a platform. The intelligence, the integration, and the value are all at Layer 7.
So What Exactly Is an IoT Platform?
An IoT platform is the middleware infrastructure that connects physical devices to the digital services that need their data. It is the layer that makes sense of the chaos.
More precisely, a proper IoT platform handles several distinct functions that no single protocol, no database, and no visualisation tool can manage alone.
Device Management is the foundation. Every connected device needs to be registered, authenticated, and monitored throughout its lifecycle. When a sensor goes offline at 4am, something needs to notice, log it, and potentially trigger an alert. That something is the platform.
Data Ingestion and Normalisation comes next. Devices speak different languages. A temperature sensor from one manufacturer sends Celsius values in JSON. Another sends Fahrenheit in XML. A third uses a proprietary binary format. The platform receives all of them, translates them into a consistent structure, and stores them in a way that applications can query reliably.
APIs and Integration are what turn raw telemetry into business value. A platform exposes well-documented APIs so that applications, third-party systems, dashboards, and analytics tools can pull exactly the data they need, in real time or historically. Without APIs, every application would need to talk directly to every device, which scales catastrophically.
Rules and Automation are where a platform starts to behave intelligently. When a value crosses a threshold, the platform can trigger a webhook, send a notification, invoke a script, or feed an event into a downstream workflow. This is not a dashboard feature. It is platform logic.
Security and Access Control underpin everything else. In a world where a compromised sensor can become an entry point into an enterprise network, the platform must manage credentials, enforce encryption, and ensure that only authorised systems and users can access device data.
The Confusion That Costs Millions
Most people, when they first encounter IoT, assume the journey goes like this: buy sensors, connect them to Wi-Fi, open a dashboard, and done. That assumption is the root of most failed IoT projects.
What they have built in that scenario is a point solution. It works for one device type, in one location, for one use case. Scale it to a hundred sensors, add a second device manufacturer, try to feed the data into an ERP system, and the whole thing falls apart. The dashboard shows nothing because the data pipeline was never built to handle variety. The IT team has no visibility because devices were never registered in any system. The operations team cannot automate a response because nobody built a rule engine into the architecture.
The organisations that avoid this failure share one common trait: they chose a platform before they chose a dashboard.
Where Favoriot Fits in This Picture
Favoriot was built to occupy exactly this space. It is not a dashboard builder. It is not a simple database. It is the platform layer, the infrastructure that sits between devices and the applications that need to act on their data.
In practical terms, Favoriot gives organisations a place to register devices and manage their credentials, ingest data from multiple device types and connectivity protocols, expose APIs so that any application can access structured data without needing to understand the underlying hardware, define rules that trigger automated responses when conditions are met, and monitor device health across an entire deployment.
For a student building a final year project, Favoriot removes the need to build a backend from scratch. For a company deploying environmental sensors across a manufacturing plant, Favoriot provides the infrastructure that turns raw readings into operational intelligence. The dashboard, if one is needed, sits on top of the platform, not in place of it.
Why This Distinction Matters Right Now
The IoT market is maturing. The early days of deploying sensors for the novelty of seeing live data on a screen are over. Organisations are now asking harder questions: Can this scale? Can this integrate with our existing systems? Can this actually change how we operate, or does it just create a new screen for someone to monitor?
Those questions have the same answer, and the answer is always about the platform. The platform is what makes IoT scalable. It is what makes integration possible. It is what transforms data collection into operational intelligence.
Understanding what a platform is, and what it is not, is the first step toward building IoT that actually works. The OSI model taught the networking world that every layer has a job, and that confusing one layer for another leads to systems that cannot communicate. The same principle applies to IoT. The dashboard is a Layer 7 application. The IoT platform is also a Layer 7 application, but one that powers everything the dashboard depends on. Confusing the two is like mistaking the instrument panel for the engine room.
The next time someone shows a room full of executives a beautiful chart of sensor readings and calls it their IoT solution, the right question to ask is: what is running underneath it?
If there is no good answer, the real work has not started yet.
What layer of your IoT stack are you most uncertain about? The platform conversation is one that most organisations have too late. Start it now.
Leave a Reply