Motivation
Unser Kunde bietet seine Nutzfahrzeuge international in zahlreichen Märkten in zahlreichen Konfigurationen an. Die Händler dürfen dabei verschiedene Rabatte gewähren. Diese werden einerseits durch Konzernvorgaben geleitet, andererseits aber auch durch regionale Besonderheiten und regulatorische Vorgaben in den lokalen Märkten.
Ziel ist es, einen einheitlichen Prozess zu etablieren, der sämtliche vor- und nachgelagerten Systeme einbezieht, damit die Händler innerhalb von 24 Stunden dem Kunden ein Angebot vorlegen können.
Rabattierungsprozess bei der Nutzfahrzeugbestellung.Quelle: eigene Darstellung
Beitrag der Novatec
Projektteam und Vorgehensweise
Das Team besteht mit Ausnahme des Product Owners (PO) ausschließlich aus Mitarbeitern der Novatec. Damit fließen alle Anforderungen aus dem Fachbereich über diesen PO ins Backlog, während die technische Umsetzung und Realisierung durch die Novatec erfolgt. Während der Entwicklung erfolgte eine kontinuierliche Evolution des Teams, der Plattform, des Prozesses als auch des Produktes.
Ein schönes Beispiel für diese Evolution ist der Entwicklungsprozess: Anfangs verwendeten wir einen Scrum-Ansatz mit den regulären Meetings wie Daily-StandUp, Sprint-Review und Sprint-Retro. Außerdem regelmäßige Refinement-Meetings zur Spezifikation der User-Stories und Klärung der Anforderungen.
Auf Wunsch des Kunden wurde dies während des Projekts abgewandelt und ein Verfahren eingesetzt, in dem die Anforderungen über ein in Jira realisiertes Kanban-Board verwaltet wurden. Es wurden keine Sprints mehr geplant, sondern die Versions- und Releaseplanung wurde mit feststehenden Terminen vereinbart.
Ergebnis dieser Veränderung
- Mehr Variabilität und Flexibilität hinsichtlich der Auswahl der umzusetzenden User-Stories bei der Planung über das Kanban-Board.
- Die schnellere Bearbeitung von kurzfristig eingegangenen Incidents über eine spezielle Hotfix-Verarbeitungspipeline.
Hintergrund dieser Veränderung
Das Projekt kam in ruhigeres Fahrwasser und die weiteren Releases der Software waren besser planbar. Die zu Beginn notwendige Flexibilität, der mit dem Einsatz von Scrum begegnet wurde, war nicht mehr erforderlich.
Grundsätzlich sind wir der Meinung, dass regelmäßige Refinement-Meetings in Scrum-Projekten sehr wertvoll sind und notwendige Nachbesserungen deutlich reduzieren. Daher gilt es, den Projektkontext und die gegebenen Umstände im Auge zu behalten, um die jeweils optimale Vorgehensweise auszuwählen und einzusetzen. Ein Wechsel derselben kann durchaus auch während der Laufzeit eines Softwareentwicklungsprojektes Sinn ergeben. Wie im hier beschriebenen Fall haben wir dies stets im Blick.
Designkonzepte und Architektur
Um den Benutzern einen möglichst einfachen Einstieg zu ermöglichen, entwickeln wir in einem agilen Design-Prozess (UX Design) Interaktionskonzepte und dazu passende Benutzeroberflächen für eine möglichst intuitive Bedienung. Die Webanwendung wird in Angular mit TypeScript entwickelt. Zur Verbesserung der Performance setzen wir reaktive Programmierung ein.
Das Backend besteht aus Microservices die mit Spring Boot in Java realisiert sind. Als BPM-Engine kommt Camunda zum Einsatz. Die Anwendung läuft verteilt in Docker-Containern auf einem Kubernetes Cluster in einer hybrid Cloud. Wir verwenden den Domain-Driven-Design Ansatz zur Entwicklung des Backends. Das Frontend wird nach dem HATEOAS-Prinzip (Hypertext As The Engine Of Application State) bedient.
Für einen speziellen Backend-Service nutzen wir Node.js – Ein damit implementierter Microservice generiert für den Endanwender ein PDF der Rabattierungsentscheidung für Druck und Archivierung. Wir verwenden dazu Puppeteer, damit das PDF eins zu eins der HTML-Ansicht entspricht.
Wir gewährleisten mit CI/CD-Pipelines die vollautomatisierte Erzeugung und Auslieferung der Anwendung. Hierbei nutzen wir Infrastructure-as-Code Ansätze. Das Monitoring der Anwendung basiert auf einem Stack bestehend aus Kibana, AppDynamics und Prometheus mit Granfana. Dies unterstützt uns beim Betrieb der Anwendung, für den unser Team im 8×5 Modus verantwortlich ist.
Die Performance der Anwendung haben wir durch Einführung des CQRS-Patterns weiter gesteigert und eine Trennung der lesenden und schreibenden Vorgängen implementiert. Hintergrund war, dass die lesenden Vorgänge mit der Zeit immer langsamer wurden, da die Komplexität des Entitäts-Geflechts zunahm, immer mehr Daten ins System geflossen sind und manche Endanwender tausende Rabattanfragen durchführten. Unsere Lösung basiert auf der Bereitstellung einer Materialized View, die nur periodisch aktualisiert wird. Um die Datenmengen klein zu halten, wurde zusätzlich Back-end Paging implementiert. Durch diese Änderungen sanken die Antwortzeiten für die Anzeige von ursprünglich bis zu 30 Sekunden auf Millisekunden.
Ergebnis
Die von uns etablierte Lösung verwendet einen Business-Prozess auf Basis von Camunda, der die verschiedenen lokalen Prozesse vereinheitlicht und dem Anwender folgende Funktionen bereitstellt:
- Fallbasierte Rabattanträge zu erstellen, zu pflegen und diese zur Genehmigung an die jeweils befugte Stelle zu leiten.
- Zusätzliche Informationen innerhalb von Textfeldern während der Erstellung der Anfrage hinzuzufügen.
- Den Status ihrer Rabattanträge zu verfolgen und sehen, ob sie genehmigt wurden.
- Die Gesamtsituation der Anträge auf Ebene des lokalen Zielmarktes, Händlerbezogen und/oder Benutzerbezogen zu verfolgen.
- Daten für Excel-Berichte herunterzuladen.
- Verkaufsaktionen, Rahmenverträge und Kampagnen zu erstellen und diese zur Genehmigung an die zuständige Vertriebsleitung im Zielmarkt weiterzuleiten.
Parallel zum Projekt erfolgte ein Agile Empowerment – Dieses Projekt war das erste erfolgreich zur Produktionsreife gebrachte agile Projekt im Bereich des Kunden!
Ihr Ansprechpartner
