Flexible Kundenbenachrichtigungen in unserer MaaS Plattform
Unsere smartmove Plattform muss an Kundinnen und Kunden verschiedenste Arten von Benachrichtigungen senden. Dabei treffen eine Vielzahl an Arten von Benachrichtigungen auf eine große Bandbreite an Kommunikationskanälen. So gibt es beispielsweise Benachrichtigungen über App Updates, anstehende Buchungen, Accounteröffnungen, etc. die via Mail, SMS, Push Notification oder In-App-Banner zugestellt werden könnten. Um all diesen Anforderungen im E-Mobilitätsbereich gerecht zu werden, haben wir uns für eine spezielle, dynamische Implementierung entschieden und möchten diese in diesem Blogeintrag mit euch teilen: Das Customer Messaging Service.
Die Grundidee hinter diesem Service ist es, nicht nur die große Spanne an Nachrichtenarten abdecken zu können, sondern diese sogar während des laufenden Betriebs erweitern zu können. Gleichzeitig soll das Service in der Lage sein, beliebige Nachrichten als Events dynamisch über mehrere Kanäle (In-App-Banner, Push Notification, E-Mail, SMS) an die betroffenen Kundinnen und Kunden senden zu können.
In traditionellen Implementierungen für Kundenbenachrichtigungen können die Nachrichtenquellen und Arten der Benachrichtigungen nicht im laufenden Betrieb hinzugefügt und angepasst werden. Weiters kann das Koppeln der Quellen mit den entsprechenden Benachrichtigungstypen sehr zeit- und ressourcenintensiv sein. Unser Customer Messaging System setzt also einen neuen, innovativen Maßstab für flexible Kundenkommunikation.
Vorteile einer dynamischen Event-Implementierung
Die Architektur unseres Customer Messaging Services erlaubt es uns, dynamisch neue Nachrichtenquellen hinzuzufügen. Hierbei kann mittels einfacher und bearbeitbarer Konfiguration dem Service beigebracht werden, wie mit neuen Benachrichtigungsarten umzugehen ist (z.B. wenn die smartmove Plattform um Benachrichtigungen für ausstehende App-Updates erweitert wird). Betrachte den Vorgang in der Abbildung oben. Andere Microservices geben beim Customer Messaging Service den Versand einer neuen Nachricht in Auftrag. Aufgrund der Konfiguration erkennt das Customer Messaging Service, um welche Art von Nachricht es sich handelt (z.B. “Ausstehendes App Update”-Nachricht, “Baldiger Buchungsbeginn”-Nachricht) und kann die Daten entsprechend interpretieren und aufbereiten. Die Nachrichten der Microservices, die dann vom Customer Messaging Service interpretiert und verschickt werden, sind im JSON-Format aber haben inhaltlich sonst keine Vorgaben. Zusätzlich kann auch die Zustellart (In-App-Bannern, Push Notifications, E-Mail, SMS) für jede Art von Kundenbenachrichtigung dynamisch konfiguriert werden. Dieses Design ermöglicht also einen langfristigen Einsatz des Customer Messaging Services, ohne dass neue Implementierungsaufwände notwendig werden!
Wie einleitend erwähnt, sind all diese Konfigurationsanpassungen laufend möglich. Das Customer Messaging Service muss nicht neu deployed werden, wodurch es keine Verzögerungen beim Nachrichtenversand durch Downtimes gibt. Hier sind wir mit unserer Service-Architektur sogar soweit gegangen, dass Konfigurationen mittels REST-Schnittstellen adaptiert werden können. Das heißt, es wäre zukünftig sogar möglich, Prozesse in Administrationssoftware wie unserem Web Portal abzubilden, die neue Arten von Benachrichtigungen zur Folge haben. Die notwendigen Anpassungen im Customer Messaging Service können komplett automatisiert vollzogen werden, ohne dass dabei der laufende Betrieb unterbrochen wird.
Wir haben also ein sehr flexibles und resilientes System geschaffen. Durch Generalisierungen während der Designphase des Services, stehen wir zukünftigen Weiterentwicklungen in der smartmove Plattform gewappnet gegenüber. Weitere Anpassungen am dynamischen Customer Messaging Service sind kaum notwendig.
Herausforderungen einer dynamischen Event-Implementierung
Natürlich sind wir bei der Umsetzung eines so vielseitigen Systems auch auf einige Herausforderungen gestoßen, die wir gerne mit euch teilen möchten.
Wie oben besprochen, kann im Customer Messaging Service eine Konfiguration hinterlegt werden, die erklärt, wie jede Nachricht einer Benachrichtigungsart interpretiert werden muss. So gibt es für jede Art von Benachrichtigungen, eine Interpretationsanleitung. Erhält das Customer Messaging Service eine neue Nachricht, die ausgeschickt werden soll, muss es daher zunächst erkennen, um welche Art von Benachrichtigung es sich handelt (ein Passwort-Reset, eine Buchungsbestätigung, etc). Erst danach können die Daten entsprechend Interpretationsanleitung gelesen und weiterverarbeitet werden. Dieses Matching kann jedoch bei wachsender Anzahl an Benachrichtigungsarten kompliziert werden. Fehler könnten sich beim Schreiben der Konfigurationsdatei einschleichen. Eine statische Implementierung hat diesen Aufwand zwar nicht, büßt dafür aber auch sämtliche Flexibilität ein.
Eine weitere Herausforderung ist die Konfiguration der Datenimports. Benachrichtigungen enthalten typischerweise personalisierte Daten, wie z.B. die Anrede einer Kundin bzw. eines Kunden per Namen. Aufgrund unserer Micro-Service-Architektur hat jener Service, der eine Benachrichtigung beim Customer Messaging Service in Auftrag gibt, üblicherweise nicht sämtliche Daten. Beispielsweise ist nur eine Kunden-ID vorhanden, aber nicht das komplette Profil. Daher muss das Customer Messaging Service in der Lage sein, diese Informationen zu finden und einzusetzen. Letzten Endes soll ja nicht “Liebe 12345678” sondern “Liebe Martina” in der E-Mail stehen. Die Anleitung, woher und wie die notwendigen Daten erhalten werden können, muss in der schon oft angesprochenen Konfiguration festgehalten werden. Demnach mussten wir das Customer Messaging Service so programmieren, dass es in der Lage ist, basierend auf einer Konfiguration REST-Schnittstellen anderer Microservices dynamisch aufzurufen. Im Vergleich einer statischen Lösung, die vorprogrammiert die gewünschten Daten abruft, stellt dies einen größeren Implementierungsaufwand dar. Dieser erfolgte jedoch im Dienste großer Flexibilität.
Dynamisch > Statisch
Unser dynamisches Customer Messaging Service war ein großes Softwareentwicklungsprojekt. Von der Konzeption bis hin zu Implementierung mussten wir immer wieder weit voraus denken, unsere Use Cases generalisieren und komplexen Code umsetzen. Allerdings haben wir nun ein fertig entwickeltes Service, das kaum mehr abgeändert werden muss, um zukünftigen Ansprüchen in der Kommunikation gerecht zu werden. Seine Einsatzzwecke können erweitert werden, ohne dass neue Softwareentwicklung stattfinden muss. Lediglich die Anbindung eines neuen Kommunikationskanals bedarf Anpassungen. Dies steht im groben Unterschied zur statischen Implementierung, in der jeder Anwendungsfall fest einprogrammiert ist. Letztlich haben wir ein System erhalten, das getestet und erprobt ist und nicht mehr laufend angepasst werden muss. Dadurch lassen sich eine Vielzahl an Fehler durch Regression vermeiden und Entwicklungskosten stark reduzieren. Und gleichzeitig ermöglichen wir eine hilfreiche User Experience für unsere Kundinnen und Kunden, indem wir flexible Kommunikationskanäle geschaffen haben.
Wir sehen uns im nächsten Blogpost!