IOX Insights

IoT-Systemarchitektur: warum Integrationsprobleme immer am Ende auftauchen

Integrationsprobleme tauchen am Ende auf, weil das Konzept Kästchen beschreibt statt Nähte. Was zwischen Hardware, Firmware, Cloud und App zu klären ist.

7 Min Lesezeit

Platine, Funk-Gateway, Server-Modul und Smartphone auf einem Werkstatttisch – der letzte Stecker passt nicht ins Smartphone, Sinnbild für die Nähte in der IoT-Systemarchitektur

Die kurze Antwort: weil das Ende der erste Moment ist, in dem die Nähte belastet werden. Bis dahin hat jedes Team in seinem eigenen Bereich recht. Das Gesamtkonzept beschreibt dann meist vier Kästchen – Hardware, Firmware, Cloud, App – und Pfeile dazwischen. Was es nicht beschreibt, ist das, was tatsächlich bricht: die Vereinbarung darüber, wer sich wie schnell ändern darf und wer die Änderung des anderen aushalten muss.

Das ist kein technisches Detail, das man später klärt. Es ist der Teil des Konzepts, der über Termin und Kosten entscheidet – und der in fast keinem Konzept steht.

Das Problem, das auf der Hand liegt

Wenn ein Projekt in der Integration auseinanderfällt, ist die Diagnose schnell gestellt: Das Gesamtkonzept war nicht durchdacht. Der Reflex darauf ist ebenso naheliegend. Ein größeres Architekturbild, mehr Vorlauf für das Design, ein Architekt, der alles überblickt. Und vor allem: mehr Abstimmung. Größere Runden, alle an einen Tisch.

Genau dieser Reflex ist die erste Falle, und zwar gleich doppelt.

Zum einen löst ein besseres Bild das Problem nicht. Ein Diagramm aus Kästchen und Pfeilen zeigt die Bestandteile – und die Bestandteile sind selten das Problem. Jede der vier Schichten kann für sich sauber gebaut sein, und das Produkt funktioniert trotzdem nicht. Was bricht, liegt nicht in den Kästchen, sondern zwischen ihnen.

Zum anderen scheitert die Integration nicht erst in der Integration. Sie scheitert bei der Beauftragung. Drei Lieferanten lesen dieselbe Anforderung, jeder legt sie in seinem Kontext plausibel aus, und niemand liegt für sich genommen falsch. Weil es keine verbindliche gemeinsame Grundlage gab, als die Verträge unterschrieben wurden, kommen die drei Auslegungen erst dann miteinander in Kontakt, wenn alles zusammengesteckt wird. Dann ist es teuer, weil dann alle drei bereits gebaut haben.

Bevor du also mehr abstimmst, lohnt sich ein Blick darauf, was zwischen den Kästchen eigentlich vereinbart werden muss.

Was du jetzt nicht übersehen solltest

Wir nennen diese Stellen Nähte: die Punkte, an denen zwei Schichten aufeinandertreffen, die von verschiedenen Menschen gebaut, verschieden schnell verändert und verschieden lange betrieben werden. Vier Dinge entscheiden darüber, ob eine Naht hält.

Da ist zuerst die Taktung. Deine vier Schichten laufen in vier völlig verschiedenen Geschwindigkeiten. Die Hardware ist mit dem Werkzeug eingefroren und bleibt es für Jahre. Die Firmware ändert sich in Monaten, muss aber auf Geräte gelangen, die zeitweise offline sind, in fremden Netzen hängen oder in einer Maschine verbaut sind, die nicht angehalten werden darf. Die Cloud kann sich wöchentlich ändern. Und die App ist überhaupt nicht von euch getaktet: Die Plattformbetreiber erzwingen jedes Jahr Anpassungen, die niemand bei euch geplant hat. Seit Ende April 2026 nimmt Apple nur noch App-Updates an, die mit dem iOS-26-SDK gebaut sind; Google Play verlangt seit dem 31. August 2026 für jedes Update Android 16 als Zielversion. Beide fragen nicht, ob eure Hardware da mitkommt. Eine Naht ist die Stelle, an der diese Uhren aufeinandertreffen.

Daraus folgt der zweite Punkt: Eine Schnittstelle ist eine Vereinbarung über Veränderung. Eine Spezifikation, die nur festhält, welche Daten in welchem Format fließen, ist eine halbe Spezifikation. Die andere Hälfte beantwortet, was passiert, wenn eine Seite alt bleibt. Wie lange muss die neue Cloud ein Gerät aus dem ersten Produktionsjahr bedienen? Wer vergibt Versionen, und wer darf eine alte abkündigen? Funktioniert ein Gerät noch, wenn seine App drei Generationen weiter ist? Wie dringend diese Fragen sind, zeigt der Cyber Resilience Act: Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden melden, auch für Geräte, die längst im Feld sind. Spätestens wenn darauf ein Sicherheitsupdate folgen muss, zeigt sich, ob die Naht zwischen Firmware und Cloud eine alte Geräteversion noch bedienen kann. Steht das nicht im Konzept, wird es trotzdem entschieden – nur eben unter Termindruck, von dem, der am lautesten ist.

Der dritte Punkt entscheidet früher, als die meisten annehmen: das Datenmodell. Jede Schicht bindet sich daran, und zwar dauerhaft. Wie ein Gerät, ein Zustand, ein Ereignis beschrieben wird, legt fest, was Firmware senden muss, was die Cloud speichern kann, was die App anzeigen darf und was ihr später auswerten könnt. Seit dem 12. September 2026 ist das auch eine Rechtsfrage: Vernetzte Produkte, die neu in der EU auf den Markt kommen, müssen nach dem Data Act so konzipiert sein, dass Nutzer ihre Gerätedaten samt der nötigen Metadaten einfach und maschinenlesbar abrufen können. Das ist keine App-Funktion, die man nachrüstet, sondern eine Anforderung an das Datenmodell. In der Industrie gibt es dafür standardisierte digitale Abbilder von Komponenten – die Verwaltungsschale ist das bekannteste – und es gibt sie aus genau einem Grund: Bilaterale Absprachen zwischen je zwei Beteiligten skalieren nicht. Heute kostet dieses Modell ein paar Workshops. Später kostet es eine Migration im Feld.

Und schließlich der Punkt, an dem die anderen drei hängen: Die Naht gehört niemandem. Vier Schichten heißt fast immer vier Teams, oft vier Lieferanten, jeder mit einem sauber abgegrenzten Auftrag. Die Naht liegt zwischen den Aufträgen. Sie taucht deshalb in keinem Statusbericht auf, niemand meldet sie als Risiko, und alle Beteiligten sind bis zuletzt im grünen Bereich. Dazu kommt, dass Integration, Verifikation und Validierung drei verschiedene Dinge sind, die im Projektplan regelmäßig zu einem Punkt namens „Test“ zusammenschrumpfen – am Ende, in der Woche vor dem Termin.

Hier liegt auch der Grund, warum mehr Abstimmung das Problem nicht löst. Nähte werden nicht in großen Runden geklärt, sondern in kleinen. Was in der Praxis hilft, ist ein kleiner Kreis auf Projektebene, der harte Informationen austauscht – nicht eine große Runde auf Organisationsebene mit guter Stimmung. Je mehr Funktionen am Tisch sitzen, desto mehr Abstimmungsaufwand und desto weniger Klarheit. Und eine sehr harmonische Runde hat eine unangenehme Eigenschaft: Sie hört auf, das Gesagte zu prüfen. Wohlwollen ersetzt keine schriftliche Vereinbarung.

Unser Rat: beschreibe Nähte, nicht Kästchen

Die gute Nachricht: Du brauchst dafür kein größeres Konzept, sondern ein anderes. Nimm dein Architekturbild und markiere jede Stelle, an der zwei Schichten aufeinandertreffen. Das sind selten mehr als fünf oder sechs. Für jede beantwortest du vier Fragen.

Die vier Fragen pro Naht

✓

Welche zwei Schichten treffen hier aufeinander, und welche ändert sich schneller?

✓

Was passiert, wenn eine Seite alt bleibt – wie lange muss die neue die alte bedienen?

✓

Wem gehört diese Naht, namentlich, über die gesamte Laufzeit?

✓

Woran merken wir vor dem Integrationstest, dass sie nicht trägt?

Die vierte Frage ist die unbequemste und die wichtigste. Prüfen gehört nicht ans Ende, sondern in den Verlauf: Wenn zwei Schichten erst dann zum ersten Mal miteinander sprechen, wenn beide fertig sind, hast du dir das teuerste aller Testverfahren ausgesucht. Steck früh zusammen, was noch unfertig ist. Ein Gerät mit halber Firmware, das eine echte Cloud erreicht, sagt dir mehr über euer Konzept als drei Monate Spezifikationsarbeit.

Zwei Dinge kommen dazu. Erstens: Klär das Datenmodell, bevor du die Schichten beauftragst. Es ist die einzige Entscheidung, die alle vier Teams gleichzeitig bindet, und die einzige, bei der ein Nachziehen alles andere mitreißt. Prüf dabei gleich mit, ob Nutzer an ihre Daten kommen, wie es der Data Act verlangt. Zweitens: Schreib die Nähte in die Verträge. Nicht als Anlage, sondern als Gegenstand – wer wem wie lange Kompatibilität schuldet, ist eine kaufmännische Frage, keine technische.

Und wenn du unsere beiden vorigen Beiträge gelesen hast: Eine Schnittstelle ist einer der frühesten Härtungspunkte überhaupt, und jede Naht kostet pro Gerätejahr Geld – denn ein System, das alte Geräte weiter bedienen muss, bedient sie jedes Jahr aufs Neue.

Fazit

Ein Gesamtkonzept ist nicht dann durchdacht, wenn alle Bestandteile darin vorkommen. Es ist durchdacht, wenn es die Stellen zwischen den Bestandteilen beschreibt: wer sich schneller ändert, wie lange Altes bedient wird, wem die Naht gehört und woran ihr vorher merkt, dass sie nicht hält. Alles andere ist ein Bild – und Bilder halten der Integration nicht stand.

Vier Schichten, vier Uhren, ein Produkt. Der Integrationstest ist nur der Moment, in dem sie zum ersten Mal dieselbe Zeit anzeigen müssen.

Der IOX Schnittstellen-Check

Du willst wissen, ob euer Konzept die Nähte trägt? Im Schnittstellen-Check gehen wir mit dir durch, wo eure Nähte liegen, welche Seite sich schneller ändert, wie lange Altes bedient werden muss und wem jede Naht gehört. Am Ende steht eine Seite mit Ampel und den zwei Nähten, die du zuerst schließen solltest. Kostenfrei.

Check anfragen

Newsletter

Insights, die dich weiterbringen.

Neue Fachartikel, Praxiswissen und Learnings aus unseren IoT-Projekten – direkt in dein Postfach.

Danke! Deine Anmeldung ist eingegangen.

Nach oben scrollenWordPress Cookie Plugin von Real Cookie Banner