IoT Integration Explained

Most integration work lives entirely inside the software world: one database talking to another, one API calling the next, structured records moving between systems that were all designed to be talked to. IoT integration is different, and the difference is what makes it hard. Here you are reaching down into the physical world, into pumps, chillers, meters, valves and sensors that were engineered to run machinery, not to publish clean JSON. Bridging that gap between the operational-technology floor and the enterprise-IT stack is a discipline of its own, and it is the corner of integration I have spent much of the last two decades in. This guide explains the layers and the protocols honestly, without pretending the plumbing is simpler than it is.

Start with the bigger picture: IoT integration is one specialised branch of enterprise integration, and it shares the same core problems of protocols, data models and reliable delivery. If you have not read it yet, the enterprise system integration pillar lays out the general principles that everything below inherits. This article is the IoT-specific chapter of that story.

1. What IoT integration is

IoT integration is the practice of connecting physical devices, the sensors and controllers that measure and act on the real world, to the software systems that plan, record and decide. A temperature sensor on a chiller is useless as an isolated reading. It becomes valuable only when its data flows somewhere it can be trended, compared against a threshold, and turned into an alert, a work order or a report. The integration is the set of layers and translations that carry a reading from a device pin all the way to a row in an enterprise database, and carry a command back the other way.

What separates IoT integration from ordinary system-to-system integration is the starting point. Enterprise systems were built to be integrated. They expose APIs, they speak modern web protocols, they return structured, self-describing data. Field devices were built to run equipment reliably for twenty years, often long before anyone imagined they would need to talk to a cloud platform. They speak old industrial protocols, they expose raw register values with no context, and they were never designed for the security posture of an internet-connected system. IoT integration is the work of meeting those devices where they are and lifting their data, cleanly and safely, into the enterprise world.

This is also why the field is full of terminology that overlaps and confuses. Operational technology (OT) is the world of the devices and control systems on the plant or building floor. Information technology (IT) is the world of servers, databases and business applications. IoT integration is, at its heart, OT/IT convergence: getting two cultures, two protocol families and two very different attitudes to risk to cooperate. The technology is only half the challenge. The other half is that the people who own the devices and the people who own the software have historically never had to work together.

2. The layered architecture

The single most useful thing you can carry into an IoT project is a clear mental model of the layers that data passes through on its way up. Nobody builds a direct wire from a sensor to an ERP. Instead the data climbs a stack, and at each rung it is aggregated, translated, buffered or enriched. Understanding the stack keeps you from being sold a single black box that supposedly does everything, because in reality each layer has its own vendors, its own trade-offs and its own failure modes.

The diagram below shows the path a reading takes: from the devices at the bottom, through an edge gateway that collects and translates, up to an IoT platform that stores and analyses, and finally into the enterprise systems where the data drives work.

Read the stack from the bottom up and a useful principle emerges: each layer narrows and enriches the flow. The devices produce a firehose of raw values. The edge gateway thins that firehose, translates it and gives it names. The platform stores and reasons over it. By the time data reaches the enterprise systems it should be sparse, meaningful and actionable, not a raw stream of register dumps. Programs that fail usually do so because they tried to skip a layer, pushing raw device data straight at an enterprise system that had no way to make sense of it.

3. Device connectivity and protocols

The protocol layer is where IoT integration earns its reputation for difficulty, because there is no single standard and there never will be. Devices from different eras, different vendors and different industries speak different languages, and the integrator's job is to make them intelligible. Four protocols cover most of what you will meet in facilities, utilities and industrial settings.

• MQTT is a lightweight publish-and-subscribe messaging protocol maintained as a standard by OASIS. Devices publish messages to named topics on a broker, and any system that cares subscribes to those topics. It was designed for constrained devices and unreliable networks, so it is efficient, tolerant of dropped connections, and ideal for pushing sensor readings up to a platform. MQTT is the default choice for modern, cloud-connected sensing. See the MQTT explained pillar for the topic model, quality-of-service levels and broker patterns in detail.
• OPC UA (Open Platform Communications Unified Architecture), maintained by the OPC Foundation, is the industrial heavyweight. Unlike MQTT, which just moves opaque messages, OPC UA carries a rich, self-describing information model: it knows that a value is a temperature, in these units, belonging to this piece of equipment, with this data type. That structure makes it the standard for serious industrial and OT integration where context and interoperability matter. It is heavier than MQTT but far richer. The OPC UA explained pillar covers its address space and information modelling.
• Modbus is old, simple and everywhere. It exposes device data as numbered registers with no built-in meaning: register 40001 might be a pressure, but the protocol will not tell you that. You need external documentation to interpret it. Modbus has no security and no self-description, but its sheer ubiquity across meters, drives and controllers means every integrator meets it constantly. Reading Modbus and giving its registers names is often the first real job at the edge.
• BACnet is the native language of building automation: HVAC, lighting, access control and the building management system. If you are integrating a smart building, BACnet is unavoidable. Like OPC UA it carries object and property structure, but it is specific to the buildings world. Bridging BACnet from the BMS into an enterprise platform is a recurring pattern in facilities integration.

The practitioner's reality is that a single site rarely speaks just one of these. A typical facility might have BACnet from the BMS, Modbus from the energy meters, OPC UA from newer plant, and a wish to publish everything upward over MQTT. The edge gateway is where all of that gets reconciled, which is exactly why the edge layer deserves its own attention.

4. Edge versus cloud processing

One of the defining design decisions in any IoT integration is how much work happens at the edge, close to the devices, versus in the cloud or central platform. This is not a fashion choice; it changes cost, latency, resilience and bandwidth in concrete ways, and getting it wrong is expensive.

Edge processing means running logic on or near the gateway itself: filtering noisy data, aggregating high-frequency readings into meaningful summaries, applying local thresholds, and buffering data when the uplink drops. The arguments for the edge are strong. It cuts the volume of data you ship and store, because sending every millisecond of vibration data to the cloud is wasteful when a summary and an exception flag carry the real information. It cuts latency, because a local rule can react in milliseconds rather than waiting on a round trip. And it adds resilience: a gateway that buffers locally keeps working through a network outage and back-fills when the link returns, so you do not lose data every time connectivity hiccups.

Cloud or central processing means shipping data up to a platform where storage is cheap, compute is elastic, and you can run heavier analytics across many sites at once. The cloud is where cross-asset trending, fleet comparisons, long-term history and machine-learning models belong, because that is where you have the scale, the aggregate data and the processing power. What the cloud is bad at is anything that needs to be fast, anything that needs to keep working when the network does not, and anything where shipping the raw data would cost more than the insight is worth.

The honest trade-off: teams new to IoT often default to sending everything to the cloud because it feels simpler, then discover the bandwidth bill, the storage cost and the fragility when the link drops. The mature pattern is almost always hybrid: filter and react at the edge, aggregate and analyse in the cloud. Decide deliberately what each reading needs, rather than shipping the firehose upward and sorting it out later.

5. The integration layers

It helps to lay the stack out explicitly, layer by layer, with the job each one does and the kind of technology you would expect to find there. The table below is the reference I come back to when scoping an IoT integration, because it forces the conversation to name a responsible technology and owner at every level rather than hand-waving over the middle.

Laying it out this way exposes the layer most projects underinvest in: the application layer at the top, where data has to become a decision inside a system a person actually uses. It is easy to spend the whole budget on sensors and a shiny platform and treat the connection into the CMMS or ERP as an afterthought. That afterthought is where the value either lands or leaks away, which brings us to the layer I care most about.

6. Connecting IoT to CMMS and ERP

This is the part of the stack I have lived in, and it is where IoT projects most often succeed or quietly fail. A sensor detecting a developing fault, a platform trending it and raising an alert, all of that is impressive on a dashboard and worthless in isolation. The value only materialises when that alert becomes a work order in the CMMS or EAM that a technician is assigned, schedules, executes and closes, and when the asset, the parts consumed and the cost land in the ERP where the business actually accounts for them. Everything below the application layer is preparation; this is where the return is realised.

The integration into a maintenance system of record is harder than it looks because the two worlds model reality differently. The IoT platform thinks in tags, points and time-series streams. The CMMS thinks in assets, work orders, failure codes and cost centres. A meaningful integration has to map a stream of readings onto the enterprise data model: this tag belongs to that asset; this threshold breach should raise that class of work order; this alert should carry enough context that a planner can act on it without going back to the platform. That mapping is unglamorous data-model work, and it is exactly the work that gets skipped when the excitement is all about sensors and analytics.

I have watched more IoT programs stall on this integration gap than on any sensor or algorithm problem. The technology worked. The vibration sensor saw the bearing. The platform trended it correctly. But the insight arrived as an email to an inbox nobody owned, or a dashboard nobody had time to watch, disconnected from the system where maintenance actually happens. Within weeks the alerts were noise, and the program was quietly shelved. The lesson is blunt: an IoT insight that does not become a closed-out work order in the maintenance system of record is not an integration, it is a demo.

The insight worth keeping: the hard, valuable part of IoT integration is not getting data off the device, it is landing that data as an action inside the enterprise system of record and closing the loop back. Design the CMMS and ERP integration first, then work down to the sensors, and you build a program that changes behaviour rather than one that generates charts. For a full worked treatment of this specific bridge, see the IoT integration with CMMS pillar, and for how this plays out live across a building, the smart building real-time monitoring pillar.

7. Security and scale challenges

Two problems grow faster than any others as an IoT integration matures: security and scale. Both are easy to underestimate at pilot size and painful to retrofit once you are in production across many sites.

Security is the harder of the two because the devices were never designed for it. A field controller built to run a chiller for twenty years assumes it sits on a trusted, isolated control network. Connect that network to an IoT platform and, through it, to the wider enterprise and the internet, and you have joined a device with no authentication, no encryption and no patching path to a network of attackers who very much do have those things. IoT integration widens the attack surface every time it connects a new device, and the OT world's traditional answer, air-gapping the control network, is precisely what you are undoing. The disciplines that matter are network segmentation so that a compromised sensor cannot reach the enterprise core, encrypted and authenticated transport wherever the protocol supports it, and a clear boundary, usually enforced at the edge gateway, between the OT and IT sides. Treat the gateway as the guarded border crossing between two networks with very different trust levels.

Scale creeps up differently. A pilot with fifty sensors on one building is trivial to manage by hand. The same architecture at five thousand sensors across forty sites is a different animal: provisioning devices, keeping firmware current, monitoring which gateways are alive, handling the volume of time-series data, and doing all of it without a small army of people. This is why device management is a first-class concern of any serious IoT platform rather than an afterthought. If you cannot answer how you will onboard the ten-thousandth device as easily as the tenth, the architecture will not survive contact with growth.

Both problems share a root cause: an IoT integration is a distributed system with a very large number of small, unreliable, long-lived and physically exposed nodes. Ordinary enterprise integration deals with a handful of well-maintained servers. IoT integration deals with thousands of cheap devices in the field, and every design decision has to account for that difference in cardinality and trust.

8. A practical IoT integration approach

If you are scoping an IoT integration, the sequence matters more than the brand of platform. The approach I would advise any team to follow keeps the focus on value and avoids the classic trap of buying technology before defining the outcome.

• Start from the decision, not the sensor. Name the business action you want the data to drive, a work order raised, a cost avoided, a report produced, and work backward to the data you actually need. Data with no decision attached is a cost, not an asset.
• Design the enterprise integration first. Map how a reading becomes a work order in the CMMS or a record in the ERP before you choose a single sensor. If the top of the stack is vague, the whole program will leak value there.
• Survey the protocols you already have. Walk the site and catalogue what speaks Modbus, what speaks BACnet, what could speak OPC UA or MQTT. The protocol reality on the ground dictates the edge design.
• Put a real edge layer in. Do not plan to ship raw data to the cloud and sort it out later. Decide what filters, aggregates and buffers at the edge, and let only meaningful data climb.
• Treat security as a boundary, not a bolt-on. Segment the OT network, harden the gateway as the border, and encrypt transport from the start. Retrofitting security after a breach is a much worse project.
• Pilot narrow, then scale on a proven pattern. Prove the full loop, device to closed work order, on a small set of assets before spreading. A pilot that skips the enterprise integration has proven nothing that matters.
• Plan for device management from day one. Assume the pilot will grow tenfold and choose an architecture that can provision, monitor and update devices at that scale without heroics.

Notice how much of this happens before any hardware is purchased. The most consequential IoT decisions are made at the whiteboard, in the mapping of physical signals to enterprise actions and in the honest survey of what the site can actually speak. Teams that reverse the order, buying a platform and then hunting for a use case, are the ones that end up with an impressive dashboard and no change in how the operation runs.

9. References

The two protocols that anchor most serious IoT integration are maintained as open standards, and it is worth knowing who stewards them:

• MQTT is standardised by OASIS (the Organization for the Advancement of Structured Information Standards), which maintains the protocol specification.
• OPC UA (Open Platform Communications Unified Architecture) is developed and maintained by the OPC Foundation, which publishes the specification and certifies conformant products.

Both organisations publish their specifications openly, and any team building on these protocols should read the primary specification rather than relying solely on vendor documentation.

Final thoughts

IoT integration looks, from a distance, like a wiring problem: connect the sensors, ship the data, read the dashboard. Up close it is a layered discipline that spans two worlds that were never designed to meet. The devices speak old industrial protocols and carry no context. The enterprise systems speak modern APIs and expect clean, meaningful records. Between them sit the edge, the platform and a set of design decisions, edge versus cloud, security boundaries, scale, that determine whether the whole thing delivers or disappoints.

The part that separates a working IoT integration from an expensive demo is the same part that most projects underinvest in: landing the data as an action inside the CMMS or ERP and closing the loop back. Get the sensors and the platform right and skip the enterprise integration, and you have built a beautiful instrument that changes nothing. Design from the decision downward, respect each layer of the stack, treat security as a boundary from the start, and the physical world and the enterprise world finally cooperate. That cooperation, quiet and unglamorous, is what IoT integration is actually for. For the wider principles this all sits on, return to the enterprise system integration pillar.

Related reading: Enterprise system integration explained, MQTT explained, OPC UA explained, IoT integration with CMMS, Smart building real-time monitoring.