Zusammensetzbare vs. monolithische Architekturen

:::(Info) (App Builders Make Critical Decisions About Solution Architecture) Wenn Sie Anwendungen mit Tulip erstellen, treffen Sie Entscheidungen über die Lösungsarchitektur, einschließlich der Anwendungsstruktur, Datenmodelle und Integrationen. Ob beabsichtigt oder zufällig, Ihre Architekturentscheidungen haben erhebliche Auswirkungen auf die Akzeptanz, Skalierbarkeit und Wartbarkeit Ihrer Anwendungen. In diesem Artikel werden zwei kritische Entwurfsparadigmen vorgestellt: zusammensetzbar und monolithisch. Wir bei Tulip raten Entwicklern von Anwendungen dringend zur Verwendung von komposiblen Architekturen:::

Warum ist Composable dem Monolithischen vorzuziehen?

Eine monolithische Lösung ist durch Folgendes gekennzeichnet:

• Sie basiert auf einem Top-Down-Datenmodell
  • Prozess- und Aktivitätsmodelle werden durch Daten in Tabellen definiert und monolithische Anwendungen werden zur Ausführung des Prozess- oder Aktivitätsmodells verwendet. Datenmodelle in Tulip Tables bieten eine Abstraktion der Komplexität der Operationen in einem einheitlichen Ansatz.
• Prozess-zentriert
  • Monolithische Anwendungen werden gebaut, um eine Funktion zu erfüllen, die auf einer funktionalen Zerlegung der Komplexität der Operationen basiert. Die endliche Menge an monolithischen Apps soll den Frontline-Operatoren überall im Betrieb dieselbe Funktion bieten.
  • Monolithische Lösungen bestehen in der Regel aus zwei Anwendungen: einer Konfigurationsanwendung und einer Ausführungsanwendung, wobei die Konfiguration in der Regel Arbeitsanweisungen und Prozessrouting in Datentabellen und nicht in der/den zusammensetzbaren Anwendung(en) selbst enthält.
• Konzipiert für zentralisierte Wartbarkeit
  • Monolithische Apps sind so konzipiert, dass sie die Wartung und Verwaltung der Lösung durch ein zentrales Team erleichtern, indem sie die Anzahl und Vielfalt der verwendeten Apps reduzieren. Die monolithische Lösung ist von oben nach unten in einer starren Hierarchie aufgebaut, in der die Frontline-Operatoren die Apps mit Informationen versorgen, indem sie auswählen, welche Funktion anwendbar ist, anstatt unterstützt und befähigt zu werden, ihre Arbeit zu erledigen.

Wir raten dringend von monolithischen Lösungsansätzen ab und empfehlen stattdessen einen kompatiblen Ansatz, da Tulip kein traditionelles MES ist. Tulip ist NICHT dafür konzipiert, monolithische Anwendungen zu entwickeln - d.h. eine Anwendung für alle Branchen, alle Modalitäten, alle Szenarien, alle Maschinen und alle Bediener. Monolithische Lösungen führen zu dem, was wir JAM (Just Another MES) nennen.

Monolithische Lösungen haben zwangsläufig Defizite

Monolithische Lösungsansätze führen unweigerlich zu einer Lösung, die bestenfalls "genauso gut" ist wie andere MES und von Natur aus alle damit verbundenen Mängel aufweist: * Monolithische Lösungen benötigen Monate/Jahre und einen hohen Aufwand für die Bereitstellung - lange Zeit bis zur Wertschöpfung.* Monolithische Lösungen erschweren inhärente Plattformfunktionen wie Vision, IIoT, AI und sind manchmal nicht nutzbar. Monolithische Lösungen sind nicht menschenzentriert und neigen zu einem klumpigen Benutzererlebnis, bei dem der Bediener das System bedient, während das System dem Bediener dient. Monolithische Lösungen sind von Natur aus komplex und schwer zu warten, sie erfordern ein spezielles Team mit einzigartigen Kenntnissen über die Lösung - genau wie eine maßgeschneiderte Softwarelösung * Monolithische Lösungen lassen sich nicht gut skalieren, da sie erwarten, dass sich alle Vorgänge an ein Standarddatenmodell halten.

Es handelt sich um einen strikten Top-down-Ansatz, bei dem davon ausgegangen wird, dass die Änderungen minimal und allgemein bekannt sind.

Monolithische Lösungen werden entwickelt, um einen Prozess zu automatisieren, bei dem sich Menschen an ein strenges Regelwerk halten müssen. Dabei wird davon ausgegangen, dass es nur sehr wenige Änderungen gibt und dass alle Variationen bekannt sind.

Der Aufbau einer kompatiblen Lösung ist einfach, erfordert aber eine Änderung der Denkweise.

Composable-Lösungen nutzen die Möglichkeiten der Tulip-Plattform, um den Bedienern an der Frontlinie eine einzigartige und spezifische Art der digitalen Interaktion zu bieten und sie zu befähigen, produktiver zu sein. Sie bieten dem Bediener eine digitale interaktive Lösung, bei der die physische und die virtuelle Welt miteinander verbunden sind. Dies ist ein entscheidender Grundsatz für die Erzielung von Produktivitätszuwächsen und ein wesentlicher Bestandteil kompositionsfähiger Lösungen.

Merkmale von Composability & Composable Solutions

• Die Lösung ist in kleinste logische Blöcke (Lösungskomponenten) unterteilt, die für einen bestimmten Shop Floor sinnvoll sind.
  • Die Lösung könnte z.B. in separate Apps aufgeteilt werden, die auf folgenden Kriterien basieren: Ort, Zeit und Persona
• Die Lösungskomponenten haben ein gemeinsames Tabellenmodell.
• Lösungskomponenten werden mit gemeinsamen , auf den Kunden zugeschnittenen Best Practices entwickelt
• Die Lösung und ihre Komponenten können von einem anderen Citizen Developer verstanden und unterstützt werden
• Die Lösung und ihre Komponenten sind parametrisiert, wo es sinnvoll ist

Die Tulip-Plattform ist eine Software (SaaS), aber Tulip-Anwendungen sollten nicht als Software betrachtet werden. Es handelt sich um zweckbestimmte, hoch konfigurierbare digitale Inhalte, die ständig geändert und an die Bedürfnisse der Frontline-Operationen angepasst werden sollten. Das Ändern oder Verbessern einer App ist dasselbe wie das Ändern von Stammdaten, denn Apps sind in der Tat Stammdaten! Die Tulip-Plattform bietet eine Möglichkeit, App-Änderungen durch einen geregelten, versionsgesteuerten Lebenszyklusprozess zu verwalten, um diese Konfigurierbarkeit zu unterstützen. Apps werden mit No-Code zusammengestellt und die App-Lösung besteht aus Apps. Der Aufbau von Lösungen in Tulip mit einem monolithischen, funktionalen Ansatz, als ob es sich um eine Softwarelösung handeln würde, schränkt die Fähigkeit ein, Lösungen schnell aufzubauen und die Vorteile eines komponierbaren Systems zu nutzen.

Andere wichtige Vorteile von Composable Solutions sind:

• Bereitstellung eines erweiterten Arbeitsbereichs an der Frontlinie zur Steigerung der Produktivität
• Nutzung nahtlos integrierter digitaler Technologien wie Bildverarbeitung, KI/ML, intelligente Geräte usw.
• Instrumentierung/Digitalisierung von Prozessen und Frontline-Operationen, um datengesteuerte Entscheidungen und CI zu ermöglichen.
• Steuerung der Produktionsausführung mit gemeinsam genutzten Informationen aus Tables und externen Systemen.

Composable-Lösungen bieten einen Mehrwert durch ihre Fähigkeit, sich leicht in andere Systeme zu integrieren und mit ihnen zusammenzuarbeiten. Dies ist der Kern des IIoT, bei dem verschiedene autonome Geräte und Systeme problemlos miteinander kommunizieren und interagieren. Tulip ist eine IIoT-Plattform und bietet von Haus aus die Möglichkeit, die Integration mit anderen Systemen durch seinen No-Code-Ansatz zu ermöglichen. Mit der Plattform, die Daten konsumiert und an andere IIoT-Systeme sendet, können Endpunkte innerhalb von Stunden von Personen mit wenig IT-Hintergrund erreicht werden. Dies alles erfordert einen kompositionsfähigen Ansatz, bei dem Apps spezifische Abläufe und Verbindungen mit der lokalen physischen Welt haben.

Gemeinsame Lösungsmuster im Tulip-Lösungsdesign

Das High-Level-Design einer Composable Solution kann vielen Mustern folgen. Nachfolgend finden Sie gängige Muster für Tulip-Lösungen. Beachten Sie, dass es sich hierbei weder um eine exklusive Gruppe handelt, noch schließen sie sich gegenseitig aus. Abhängig von den Anwendungsfällen in einer bestimmten Einrichtung können viele dieser Muster und andere verwendet werden.

Implementierung eines traditionellen monolithischen Systems vs. Implementierung einer komponierbaren, von Bürgern entwickelten Lösung

Der traditionelle Ansatz zur Implementierung eines Unternehmenssystems ist in der Regel ein langfristiger, risikoreicher Ansatz mit verzögertem Nutzen, wie in "Der alte Weg" unten dargestellt. Es wird allgemein erwartet, dass eine solche Erstimplementierung Jahre dauert, und daher wird natürlich erwartet, dass alle nachfolgenden kritischen Erweiterungen fast genauso lange dauern.

Implementierung einer kompatiblen, von Bürgern entwickelten Lösung - klein anfangen und organisch in Bezug auf Fähigkeiten und Anwendungsfälle wachsen

Im Gegensatz zur langsamen Implementierung einer herkömmlichen monolithischen Lösung kann die Implementierung einer kompatiblen Lösung iterativ erfolgen, was zu einer sehr kurzen Zeitspanne bis zur Wertschöpfung führt und natürlich ein agiles Modell der kontinuierlichen Verbesserung unterstützt.

Während die Implementierung der "Version 2" einer Lösung, die mit einer traditionellen monolithischen Lösung entwickelt wurde, mehrere Monate oder länger dauern kann, kann die Implementierung einer "Version 2" einer Anwendung in einer kompositiven Lösung nur Stunden, Tage oder Wochen dauern. Die schnellen Iterationen, die durch kompositionsfähige Lösungen ermöglicht werden, verbessern die Akzeptanz bei Ihren Betreibern, da sie sicher sein können, dass ihr Feedback nicht auf taube Ohren stößt.