Der Digitalisierungsgrad der deutschen Wirtschaft stieg von 2020 bis 2024 um 13,6 Prozent. Und mit wachsender Digitalisierung reicht es nicht mehr, Daten von A nach B zu bewegen. Für den industriellen Datenfluss bedarf es einer Middleware.
Strategisches Eigentum?
Viele Firmen betrachten Middlewares als strategisches Eigentum, das intern entwickelt und fest ans Unternehmen gebunden sein sollte. Obwohl ihre Kernkompetenz in anderen Bereichen liegt, investieren sie oft erhebliche Ressourcen, um etwa aus einem Node-RED-Prototypen eine eigene Lösung zu entwickeln. Dies kann zu monolithischen Systemen führen, die mittelfristig nur schwer neuen Szenarien standhalten. Denn zu oft spielen solche Projekte im Tagesgeschäft nur eine Nebenrolle. Beispielsweise sind Maschinenbauer durch den EU Data Act verpflichtet, ihren Kunden Zugang zu Maschinendaten zu geben. Um eigene IT-Lösungen zu entwickeln, fehlt es jedoch oft an Kapazitäten. Es entstehen häufig studentische Projekte – mit allen Risiken.
Dem gegenüber stehen Plattformen etablierter Anbieter. Sie bieten vordergründig offene Ökosysteme, bringen aber eigene Middleware-Bausteine in den Markt. Externe Entwickler liefern Apps, doch die Plattformanbieter behalten Kontrolle über Datenflüsse und Integration. Auch wenn Unternehmen die Plattform nur als Fundament nutzen, binden sie sich: Denn einmal entwickelte Anwendungen sind oft nicht portabel – ein erneuter Vendor-Lock-in entsteht.
Unabhängig von der ‚Make or Buy‘-Entscheidung sollten Digitalstrategien auch langfristige Anforderungen berücksichtigen. Oft werden sie nicht als ganzheitliche Maßnahme verstanden und zudem nicht in realistische Meilensteine unterteilt. Im Ergebnis scheitern Strategien oder führen zu Parallelprojekten, die bestehende Lösungen erweitern oder ersetzen sollen. Schnelle Entwicklungen führen dabei oft zu Insellösungen – unterschiedlich in Architektur, Plattform und Verantwortung. Statt Interoperabilität entsteht ein Flickenteppich und damit genau das Problem, das eine Middleware lösen sollte.
Auch werden grundlegende technische Anforderungen oft nicht berücksichtigt, etwa Echtzeitfähigkeit, Effizienz und Flexibilität. Einen einzelnen Wert von A nach B zu übertragen ist trivial. Aber was passiert, wenn zehntausende Werte aus hunderten Teilnehmern verarbeitet werden sollen?
Echtzeitfähigkeit wird oft falsch verstanden. Spätestens bei wachsendem Datenvolumen entscheidet nicht nur die verfügbare Bandbreite, sondern auch das Knowhow über Parallelisierung, Kommunikation und Protokolloptimierung. Effizienz beginnt beim Protokoll. Dazwischen braucht es Architektur, die mehr kann als nur Daten erheben. Da keine Digitalstrategie von Beginn an perfekt ist, braucht es eine flexible Grundlage, die offen, robust und ausbaufähig ist. Nur so wird aus einem Proof-of-Concept eine tragfähige Infrastruktur.
Eine Middleware als SDK
Wer eine eigene Middleware anstrebte, kennt es: Je nach Protokoll bedarf es anderer SDKs (Software Development Kits). Dabei obliegt die eigentliche Herausforderung in der Architektur – also darin, eine möglichst beliebige Anzahl an Protokollen über eine zentrale Komponente hinweg miteinander zu integrieren. Genau hier werden die zuvor beschriebenen Anforderungen entscheidend.
Oft entsteht dabei der Wunsch nach einem SDK, das mehrere Protokolle abdeckt und gleichzeitig die nötige Architektur mitbringt. Im besten Fall genügt die eigene Logik oder ein Frontend – ohne tieferes Knowhow zu Protokollen oder Architektur. Ein solches System bietet Traeger Industry Components mit Codabix an. Dieses unterstützt unternehmenseigene Logiken und Schnittstellen zur Headless-Integration. Codabix adressiert die technischen Herausforderungen industrieller Kommunikation sowie architektonische Anforderungen an die Integration. Heterogene Systeme werden ohne Vendor-Lock-in harmonisiert. Dies geschieht über offene Schnittstellen.
Klassische Middlewares beschränken sich auf standardisierte Protokolle und auf die Konfiguration häufig wiederkehrender Szenarien. Unternehmen mit Anforderungen abseits dieser Norm bleiben dabei außen vor oder müssen zusätzliche Lösungen anbinden. Codabix ist eine Middleware, die wie ein SDK nutzbar ist. Sie ermöglicht auch die Integration der Middleware selbst in bestehende Architekturen, Applikationen oder OEM-Produkte. In Version 2 von Codabix liefert Traeger eine durchgehende Suite zur Datenintegration.
Integrierte Entwicklungs- und No-Code-Umgebung
Vom Teilnehmer-Scan bis zur Historisierung, Visualisierung und Integration deckt die neue Version zentrale Bausteine industrieller Datenverarbeitung ab – inklusive integrierter Entwicklungsumgebung für eigene Logik und No-Code-Umgebung für die schnelle Umsetzung auch ohne Entwicklerressourcen. Das neue Asset-Management macht die Middleware zur Data Orchestration Plattform.
Unternehmen wie etwa aus dem Maschinenbau stehen zunehmend vor der Entscheidung, industrielle Datenintegration selbst zu entwickeln oder auf bestehende Systeme zurückzugreifen. Regulatorische Anforderungen wie auch betriebliche Zielsetzungen erfordern flexible Ansätze für die heterogene Datenverarbeitung. Middlewares liefern hierfür die technische Grundlage. Eigenentwicklungen bringen jedoch oft mehr Herausforderungen als Vorteile. Auf der anderen Seite stehen Plattformanbieter, deren Systeme es oft an Flexibilität fehlt. Zudem besteht die Möglichkeit eines Vendor-Lock-ins und auch die Nutzung der Cloud ist oft obligatorisch.
Gefragt sind Systeme, die sich ohne komplexe Eigenentwicklungen nahtlos integrieren lassen und industrielle Datenströme orchestrieren. Codabix Version 2 bietet hier eine Data Orchestration Plattform für Digitalstrategien vom Onboarding bis zur Headless-Daten-Integration.
