Der Kunde entwickelt seit vielen Jahren innovative Lösungen für die verarbeitende Industrie und nutzt Technologien, um die Sicherheit sensibler Daten zu gewährleisten. 

Die größte Herausforderung bestand darin, eine neue Systemarchitektur mit einem Migrationspfad zu einem neuen, auf die aktuellen Bedürfnisse zugeschnittenen System zu entwickeln und vorzuschlagen. 

Der Hauptzweck der Migration war u. a.: 

• Erhöhung der von den Produktionsmaschinen benötigten Verarbeitungskapazität - Ein neues Prozesssteuerungssystem für die Produktion war erforderlich, um die Geschwindigkeit der Abläufe zu verbessern. Der Grund dafür war, dass beim Software-Monolith des Kunden das Hinzufügen weiterer Elemente den Prüfprozess verlängert, so dass Hilfe bei der Entwicklung einer besseren Architektur benötigt wurde. 
• Erkennen von Engpässen im System und deren Optimierung - Die Umstellung auf Container würde regelmäßige Aktualisierungen erleichtern und mehr Instanzen zur Bewältigung von Schwierigkeiten im Informationsfluss schaffen. 
• Fähigkeit zur Skalierung des derzeitigen Systems 
• Einfaches Hinzufügen von Lösungen für neue Produkte   
• Verbesserte Stabilität, erhöhte Zuverlässigkeit und Fehlertoleranz - Die Wartung des Monolithen war eine Herausforderung, insbesondere, das Beheben von Fehlern 

STUFE I 

INITIATION - Erörterung eines gemeinsamen Verständnisses der Aufgaben und Ziele des Kunden 

Unsere Hauptaufgabe bestand darin, die Produktionsprozesse, die Architektur und den Tätigkeitsbereich des Kunden zu verstehen. Wir konzentrierten uns auch darauf, eine gemeinsame Sichtweise davon zu entwickeln, was die Systemarchitektur leisten soll, um Missverständnisse bezüglich der Zielanforderungen auszuschließen. Wir hielten fest, was das Team des Kunden erreichen wollte und wie das Endprodukt dieses Projekts aussehen sollte. Das Wichtigste für uns war, Klarheit über die Erwartungen, Bedürfnisse und den Umfang der Aufgaben zu verschaffen.  

Das Team aus Deutschland teilte uns seine Ziele mit, was es uns erleichterte, die Zielanforderungen in zwei Arten zu unterteilen - in technische und geschäftliche.  

• Unternehmensziel - Der Kunde möchte die Skalierbarkeit seines Systems erhöhen und neue Produkte mit geringem Ressourcenverbrauch und in kurzer Zeit auf den Markt bringen. 
• Technisches Ziel - besteht in erster Linie in der Optimierung des Datenflusses und der Erkennung möglicher Störungen (Engpässe) sowie der Reduzierung der Datenverarbeitungszeit auf maximal 15 Minuten. 

Das Kundenteam wünschte sich, dass wir zunächst eine Technologieempfehlung vorlegen,  die erst mal auf einer rein theoretischen Ebene Vorschläge und Beschreibungen für eine neue Architektur umfassen sollte. 

 DESIGN THINKING - Datenerhebung und Einführung in das ursprüngliche Konzept 

In der nächsten Phase sprachen wir über alle Komponenten, die in den aktuellen Systemen des Kunden vorhanden waren, sowie über die Beschaffenheit seines Netzes und seine Infrastruktur. Dann gingen wir nahtlos zur Analyse der gesamten Geräteproduktion über. Bei der Aufbereitung der Daten erfuhren wir mehr über die Maschinen und ihre Funktionsweise; zu diesem Zweck stellten wir viele Fragen, z. B.:  Wie funktioniert das System funktioniert? Welche Prozesse, Abhängigkeiten, Grenzsysteme usw. gibt es? 

Nachdem wir die Dokumentation des Kunden kennengelernt hatten, definierten wir die Ziele, die wir erreichen wollten. Während des Entwicklungsprozesses setzten wir verschiedene Arten von agilen Methoden ein, z. B. Anwendungsfalldiagramme und Aktivitätsdiagramme. Wir skizzierten die Systemarchitektur mit dem Kunden und diskutierten, welche Module und Funktionalitäten ersetzt oder verbessert werden sollten. Der gewählte Technologie-Stack sollte langfristig unterstützt werden (LTS) und auf Containern basieren. 

Diese technische Diskussion erleichterte die Modellierung von Geschäftsprozessen (BPMN/Activity Diagram) und den Vorschlag neuer Lösungen. Nach dem ersten Workshop stellten wir einen Lösungsvorschlag vor. Wir einigten uns dann darauf, dass wir eine Technologieempfehlung ausarbeiten, die Informationen über alle Vorteile und Risiken der gegebenen Lösungen und eine Skizze der Architektur enthält.  Außerdem haben wir wöchentliche Treffen mit dem Kunden festgelegt, bei denen wir gemeinsame Kommentare, Anregungen und Vorschläge mit dem Kunden austauschen. 

STUFE II 

PLANUNG 

Während des zweiten Workshops wurden erneut die Entwurfsziele und -vorgaben besprochen. Anschließend diskutierten wir einen ersten Entwurf der Architektur auf der Grundlage der erhaltenen Technologieempfehlung. In der nächsten Phase stellten wir zwei Konzepte vor, in denen wir den aktuellen und den neuen Ansatz der ereignisgesteuerten Architektur mit einer hybriden Lösung auf der Grundlage von modularen Microservices in Kombination mit dem Monolith verglichen. Unter anderem gingen wir auf den von uns empfohlenen Technologie-Stack und den Architekturvorschlag ein.  

Wir haben uns für die ereignisgesteuerte Architektur entschieden, weil man mit diesem Ansatz alles erreichen kann: 

1. Lose Verknüpfungen zwischen Komponenten – Komponenten können über asynchrone ereignisbasierte Nachrichten kommunizieren, was eine größere Flexibilität und Skalierbarkeit des Systems ermöglicht. 
2. Skalierbarkeit - Bei dieser Architektur kann die Verarbeitung in mehrere Komponenten aufgeteilt werden, die jeweils unabhängig voneinander eingehende Ereignisse verarbeiten können. Dies erleichtert die Skalierung des Systems bei steigender Arbeitslast und gewährleistet eine gleichmäßige Auslastung der Ressourcen. 

In der nächsten Phase haben wir gezeigt, wie wir uns das neue System vorstellen und die wichtigsten Annahmen diskutiert. 

Anschließend haben wir eine Strategie mit zwei Ansätzen für den Übergang vom derzeitigen System zum neuen System vorgestellt. Sie besteht aus zwei Teilen: 

• Evolutionäres Konzept - beinhaltet eine direkte Änderung Kommunikation innerhalb des Systems. 
• Revolutionäres Konzept - beinhaltet eine grundlegende Änderung der Art und Weise, wie Module kommunizieren. Die Schaffung von "Warteschlangen" verbesserte die Leistung der Module, die Kommunikation und die Verarbeitungszeit wurde reduziert. 

Zum Umfang der Technologieplanung gehörte die Auswahl geeigneter Technologien; in diesem Fall war es Java 17 (JDK 17) zusammen mit Spring Boot 3.1 / Spring 6. Der wichtigste Faktor bei der Auswahl eines Technologie-Stacks war die Kenntnis der Systemanforderungen und die Verfügbarkeit von Ressourcen und Entwicklern. 

Was hat der Kunde nach dem Produktworkshop erhalten? 

Nach dem Workshop erhielt der Kunde eine vollständige Dokumentation in deutscher Sprache, in der alle konzeptionellen Ergebnisse zusammengefasst sind. Sie enthält alle zuvor beschriebenen Schritte, wie die Definition der Ziele, die Auswahl des Technologie-Stacks und die Beschreibung des angestrebten evolutionären oder revolutionären Ansatzes. 

Der Kunde war mit dem Produktworkshop sehr zufrieden, da wir praktisch alle seine Erwartungen erfüllt haben. Dank der ausgezeichneten Kommunikation konnten wir einen völlig neuen Architekturvorschlag erstellen. Die Erwartung des Kunden bestand nicht darin, einen Migrationsplan, einen Projektpreis oder eine Aufschlüsselung der Implementierungsphasen zu erstellen. 

Der Kunde profitierte unter anderem durch den Design Thinking Workshop. Dieser führte zu: 

• Kosteneinsparungen - statt intern zu experimentieren und die eigenen Entwickler von den Hauptaufgaben abzuziehen, erhielt das Team eine fertige Lösung 
• Innovativ über den Tellerrand hinaus - dank einer objektiven Herangehensweise haben wir einen sachlichen Blick auf die aktuelle Architektur des Kunden und die Ziele, die er erreichen möchte, geworfen.  
• Moderne technische und architektonische Lösungen. 
• Aktive Zusammenarbeit - das Team des Kunden beteiligte sich aktiv am Prozess des Erfahrungsaustauschs über den technologischen Ansatz und nahm aktiv an Workshops teil, einschließlich der Modellierung. 
• Erhebliche Risikominderung - da das Kundenteam nicht selbst mit neuen Technologielösungen experimentieren muss, spart es Zeit, um Fehler bei der frühen Systemeinführung zu vermeiden. 

Das Endergebnis nach einer internen Präsentation war so beeindruckend, dass wir mit dem Kunden 2 PoC-Projekte (Proof of Concept) entwickelten. Jedes Projekt besteht aus mehreren Phasen, die in Intervallen entwickelt werden. Am Ende einer jeden Phase führen wir eine Demo durch, um den Fortschritt der Arbeit zu präsentieren und zu diskutieren. 

Der Umfang künftiger Projekte, die wir gemeinsam mit dem Kunden festgelegt haben, umfasst Folgendes:  

1. Umsetzung des Konzepts der ereignisgesteuerten Architektur auf der Grundlage von Containern. Die Grundlage ist der Aufbau der Infrastruktur, die Erstellung einer grundlegenden Warteschlangenkonfiguration und eine grundlegende Überwachung mit Dokumentation.  
2. Automatische Skalierung der Lösung auf Grundlage von Warteschlangen- oder Ressourcenauslastung. Darüber hinaus umfasst die Arbeit die Durchführung verschiedener Operationen zur Verfügbarkeit von Anwendungen, Warteschlangen usw. sowie die Dokumentation.