IOX Insights
IoT System Architecture: Why Integration Problems Always Show Up at the End
Integration problems surface late because the concept describes boxes, not seams. What needs to be agreed between hardware, firmware, cloud and app.
The short answer: because the end is the first moment the seams are put under load. Until then, every team is right within its own domain. The overall concept usually describes four boxes – hardware, firmware, cloud, app – with arrows in between. What it doesn't describe is the thing that actually breaks: the agreement on who is allowed to change how fast, and who has to cope with the other side's changes.
That's not a technical detail to sort out later. It's the part of the concept that decides deadlines and costs – and it's missing from almost every concept.
The obvious problem
When a project falls apart during integration, the diagnosis comes quickly: the overall concept wasn't thought through. The reflex that follows is just as obvious. A bigger architecture diagram, more lead time for design, an architect who keeps track of everything. And above all: more alignment. Bigger meetings, everyone around one table.
That reflex is the first trap – twice over.
First, a better diagram doesn't solve the problem. A diagram of boxes and arrows shows the components – and the components are rarely the problem. Each of the four layers can be built cleanly on its own, and the product still doesn't work. What breaks isn't inside the boxes but between them.
Second, integration doesn't fail during integration. It fails when the work is commissioned. Three suppliers read the same requirement, each interprets it plausibly in their own context, and none of them is wrong on their own terms. Because there was no binding common basis when the contracts were signed, the three interpretations only meet when everything is plugged together. By then it's expensive, because all three have already built their part.
So before you align even more, it's worth looking at what actually needs to be agreed between the boxes.
What you shouldn't overlook
We call these points seams: the places where two layers meet that are built by different people, changed at different speeds and operated for different lengths of time. Four things decide whether a seam holds.
First, pace. Your four layers run at four completely different speeds. The hardware is frozen with the tooling and stays that way for years. The firmware changes over months, but has to reach devices that are intermittently offline, sit on third-party networks or are built into a machine that can't be stopped. The cloud can change every week. And the app isn't on your clock at all: platform operators force changes every year that nobody on your side planned for. Since the end of April 2026, Apple only accepts app updates built with the iOS 26 SDK; since 31 August 2026, Google Play requires every update to target Android 16. Neither asks whether your hardware can keep up. A seam is the place where these clocks meet.
That leads to the second point: an interface is an agreement about change. A specification that only records which data flows in which format is half a specification. The other half answers what happens when one side stays old. How long does the new cloud have to serve a device from the first production year? Who assigns versions, and who may deprecate an old one? Does a device still work when its app is three generations ahead? The Cyber Resilience Act shows how urgent these questions are: since 11 September 2026, manufacturers have had to report actively exploited vulnerabilities within 24 hours – including for devices that have long been in the field. At the latest when a security update has to follow, it becomes clear whether the seam between firmware and cloud can still serve an old device version. If none of this is in the concept, it still gets decided – just under deadline pressure, by whoever is loudest.
The third point is decided earlier than most people think: the data model. Every layer binds itself to it, permanently. How a device, a state or an event is described determines what the firmware has to send, what the cloud can store, what the app may display and what you can analyse later. Since 12 September 2026, this has also been a legal question: under the EU Data Act, connected products newly placed on the EU market must be designed so that users can access their device data, including the necessary metadata, easily and in a machine-readable format. That's not an app feature you add later; it's a requirement for the data model. Industry has standardised digital representations of components for this – the Asset Administration Shell is the best known – and they exist for exactly one reason: bilateral agreements between pairs of parties don't scale. Today this model costs a few workshops. Later it costs a migration in the field.
And finally, the point the other three hinge on: nobody owns the seam. Four layers almost always means four teams, often four suppliers, each with a neatly scoped contract. The seam lies between the contracts. That's why it doesn't appear in any status report, nobody flags it as a risk, and everyone stays green until the very end. On top of that, integration, verification and validation are three different things that regularly shrink into a single item called “testing” in the project plan – at the end, in the week before the deadline.
This is also why more alignment doesn't solve the problem. Seams aren't resolved in big meetings but in small ones. What helps in practice is a small group at project level that exchanges hard information – not a big round at organisational level with a good atmosphere. The more functions at the table, the more coordination effort and the less clarity. And a very harmonious meeting has an unpleasant property: it stops checking what's being said. Goodwill is no substitute for a written agreement.
Our advice: describe seams, not boxes
The good news: you don't need a bigger concept, you need a different one. Take your architecture diagram and mark every point where two layers meet. There are rarely more than five or six. For each one, answer four questions.
The four questions per seam
Which two layers meet here, and which one changes faster?
What happens if one side stays old – how long does the new side have to serve the old one?
Who owns this seam, by name, over the entire lifetime?
How will we know before integration testing that it won't hold?
The fourth question is the most uncomfortable and the most important. Testing doesn't belong at the end but throughout: if two layers talk to each other for the first time only once both are finished, you've chosen the most expensive test method there is. Plug together early what is still unfinished. A device with half its firmware reaching a real cloud tells you more about your concept than three months of specification work.
Two more things. First: settle the data model before you commission the layers. It's the only decision that binds all four teams at once, and the only one where catching up later drags everything else along. Check at the same time whether users can access their data, as the Data Act requires. Second: put the seams into the contracts. Not as an appendix, but as a subject matter – who owes whom compatibility, and for how long, is a commercial question, not a technical one.
And if you've read our previous articles: an interface is one of the earliest points at which an assumption becomes irreversible, and every seam costs money per device-year – because a system that has to keep serving old devices serves them again every single year.
Conclusion
An overall concept isn't well thought through because all the components appear in it. It's well thought through when it describes the points between the components: who changes faster, how long old versions are served, who owns the seam and how you'll know in advance that it won't hold. Everything else is just a diagram – and diagrams don't survive integration.
Four layers, four clocks, one product. Integration testing is simply the first moment they all have to show the same time.
The IOX Interface Check
Want to know whether your concept holds at the seams? In the Interface Check, we work through with you where your seams are, which side changes faster, how long old versions have to be served and who owns each seam. You get a one-page summary with a traffic-light rating and the two seams to close first. Free of charge.
Request a checkNewsletter
Insights that move you forward.
New articles, practical know-how and lessons learned from our IoT projects – straight to your inbox.
No spam, unsubscribe at any time. For details on data protection, see our privacy policy.