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.:
STUFE I
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.
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.
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
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:
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:
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.
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:
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:
Design, Entwicklung, DevOps oder Cloud - welches Team brauchen Sie, um die Arbeit an Ihren Projekten zu beschleunigen?
Chatten Sie mit unseren Beratungspartnern, um herauszufinden, ob wir gut zusammenpassen.
Wir würden Sie gerne in Ihrem Büro besuchen. Dies wird es uns ermöglichen, Kooperationsmöglichkeiten persönlich zu besprechen.
Hinterlassen Sie uns einfach eine Nachricht, und wir werden uns mit Ihnen in Verbindung setzen, um einen passenden Termin zu vereinbaren.