Event-getriebene IT-Architekturen: Was die Produktion von der Software-Entwicklung lernen kann

Vision Industrie 4.0 vs. Realität

Der Begriff Industrie 4.0 begleitet uns seit nun mehr als einem Jahrzehnt. Die vierte digitale Revolution verspricht uns, in ein digitales Zeitalter vorzudringen und dessen Potentiale zu heben. Die Rede ist von flexiblen, intelligenten und effizienten Fabriken durch die Vernetzung und Smartifizierung von Maschinen und Anlagen sowie die Digitalisierung von Prozessen. Allerdings zeigt sich zunehmend, dass ein vollumfänglicher Nutzen von Industrie 4.0 in vielen Unternehmen ausbleibt. Jede:r Digitalisierungsmanager:in hat mit der Herausforderung zu kämpfen, dass einzelne Piloten und Use Cases zwar einen gewissen Nutzen erzeugen, jedoch bleibt der unternehmensweite Nutzen aufgrund einer erschwerten unternehmensweiten Einführung häufig aus. Das führt in vielen Unternehmen dazu, dass Digitalisierungsmaßnahmen wie gewöhnliche interne Optimierungs- und Verbesserungsprojekte betrachtet werden, die mit einer starren Aufwand-/Nutzen-Betrachtung belegt werden. Dass der erhoffte Nutzen von Industrie 4.0 aber erst mit der Interoperabilität der Use Cases auf Basis einer zielführenden Infrastruktur freigesetzt werden kann, wird nicht betrachtet bzw. erkannt. So bleibt das Zielbild Industrie 4.0 für viele Unternehmen nur schwer umzusetzen. Vielmehr ist sie heute noch eine Vision – keine Realität.

Produktionssysteme haben sich historisch zu mächtigen Datenökosystemen entwickelt

Die Erfahrung zeigt, dass Digitalisierungsprojekte häufig mithilfe komplexer Systemlösungen und proprietärer Datenökosystemen gelöst werden – ohne eine ganzheitliche unternehmensweite Betrachtung. Es steht der Gedanke im Vordergrund: „Wenn ich Daten suche, frage ich mich heute in welchem System diese liegen und wie ich dieses System anbinden muss”. Die Kompetenz zur Beantwortung dieser Frage liegt häufig jedoch nicht bei den Unternehmen selbst, sondern bei den Systemhäusern. Die Unternehmen erwarten funktionierende Lösungen von der Stange ohne viel Anpassungsaufwand. Das Resultat dieser Vorgehensweise war und ist Inflexibilität und ein Vendor-Lock-In – eine starke Abhängigkeit vom Anbieter. Die Realität zeigt, dass die Systeme effektiv erst dann ihren vollen Umfang bieten, wenn das gesamte Ökosystem des Anbieters im Einsatz ist. Dieser Umstand führt dazu, dass die Nutzung kostenintensiv und nur schwer zu managen ist, weil unzählige 1:1-Schnittstellen konfiguriert werden müssen. Zusätzlich ergibt sich immer noch keine ordentliche Datenverfügbarkeit für eine schnelle und flexible Realisierung von Use Cases, weil ein Silodenken unterstützt wird.

Das grundsätzliche Problem ist, dass keine geeignete architekturelle Betrachtung erfolgt. Die Realität wird in Systemen abgebildet, aber nicht in durch Domänen kontextualisierte Daten. Ein Umdenken in Domänen führt zwangsläufig zu folgender richtigen Betrachtungsweise: „Wenn ich datenorientiert arbeiten und entwickeln möchte, sollte ich lediglich den Datenpunkt benennen müssen, um ihn nutzen zu können.“

Entwickler:innen liefern die Lösung: Business meets EDA

Analog zu Conway‘s Law [1] muss ich stets mit Reibungen in einem Unternehmen rechnen, wenn ich Systeme nicht entlang der Kommunikationsstrukturen in der Organisation entwickle. Dieses Prinzip scheint für Fachbereiche in vielen Unternehmen nicht offensichtlich zu sein; für Entwickler:innen hingegen ist diese Anforderung, nämlich auf Datenebene domänenspezifisch zu entwickeln, schon längst erfüllbar. Die Lösung liegt in der sogenannten eventgetriebenen Architektur (event-driven architecture, kurz EDA) begründet. In einer solchen Architektur werden die verschiedenen betrieblichen Systeme auf einer zentralisierten Ebene miteinander vernetzt und deren Zusammenspiel durch eine einheitliche Sprache ermöglicht – durch Ereignisse. Namenhafte Unternehmen im E‑Commerce sowie Finanz- und Versicherungswesen haben EDA bereits als IT-Architektur verstanden und erfolgreich umgesetzt, um diese sehr datengetriebenen Branchen auch digital souverän zu meistern. Die Lösung der aufgezeigten Problemstellung beim Umgang mit Industrie 4.0 besteht also darin, EDA als Prinzip zu verstehen, welches die Grundlage für die unternehmensweite IT-Architektur bildet. Denn die Vorteile einer EDA liegen auf der Hand: Sie eignet sich hervorragend dazu, datengetriebene Systemlandschaften modular bzw. Domänen-präzise zu entwickeln und dennoch Systeme horizontal miteinander vernetzen zu können – ganz ohne komplexitätssteigernde systemische Abhängigkeiten. Auch produzierende Unternehmen wie BMW und Bosch haben dieses Potential bereits erkannt und teilweise implementiert.

So funktioniert die eventgetriebene IT-Architektur in der Produktion

Realisiert wird diese lose Kopplung von Systemen der Produktion durch Applikation einer universellen Vernetzungsbasis. Dies wird im Kontext einer eventgetriebenen IT-Architektur durch einen Event-Broker bzw. einer „Eventstreaming-Plattform“, wie etwa Apache Kafka, Solace PubSub oder RabbitMQ, erzielt. Solche Broker dienen dazu, kontextualisierte Datenpakete von kleinsten Sensoren bis zu mächtigen Drittsystemen in Form von Events aufzunehmen und in Echtzeit zu verteilen. Solche Events können demnach reale Ereignisse abbilden, wie das Fertigstellen eines Produkts oder das Anmelden eines/einer Mitarbeiter:in. Gleichermaßen können Events von Systemen selbst als Benachrichtigungen einer Zustandsänderung oder eines Informationsgewinns getriggert werden, etwa wenn Planläufe für die Fertigungsplanung erfolgt sind oder eine Warenentnahme eine Materialunterdeckung erzeugt. Mit einem serviceorientierten Ansatz ist es dann möglich, domänenspezifische Services auf Basis dieser hochverfügbaren Events flexibel zu etablieren, die wandlungsfähige funktionale Bedarfe in der Produktion decken – ganz ohne die Konfiguration von Drittsystemen oder gar die Störung des Gesamtsystems. Letztlich wird durch diesen Ansatz sogar die Grundlage für die oftmals angestrebte Datensouveränität gelegt.

Die heutige Herausforderung liegt dabei weniger in der Motivation zu einem solch strategischen Unterfangen oder gar die technische Realisierbarkeit dieser IT-Architektur. Sie besteht vielmehr in der dazu notwendigen Spezifikation eines zentralen Eventmodells, also einem einheitlich verwendeten Datenmodells, das aktuell noch mangels Vorarbeiten individuell aufwändig entwickelt werden muss. Diese Hürde zur Adaption wird in aktuellen Forschungs- und Industrieprojekten durch Entwicklung allgemein applizierbarer Events der Produktion erforscht.

[1] Das Gesetz von Conway ist eine nach dem US-amerikanischen Informatiker Melvin Edward Conway benannte Beobachtung, dass die Arbeitsergebnisse von Systemen durch die Kommunikationsstrukturen der sie umsetzenden Organisationen vorbestimmt sind (s. Wikipedia-Artikel).