Event-Driven Architektur in einer Beratungssoftware
Der Beitrag diskutiert, wie eine event-getriebene Architektur hilft, Prozesse und event-produzierende Systeme voneinander zu entkoppeln, ohne die Vorteile einer Prozesssteuerung aufzugeben. Die vorgestellte Architektur wurde in der Allianz-Gruppe implementiert und ausgerollt.
Anforderungen an eine Beratungssoftware
Die Allianz-Beratungssoftware unterstützt Vertreter bei der Beratung der Kunden zur Risikoeinschätzung und Produktauswahl. Sie erhalten Unterstützung bei der Betreuung der Kunden, der Nachverfolgung von Terminen, der Erstellung von Aufgaben aus Kunden- oder Marketingaktionen heraus oder auch bei der Nachverfolgung nach dem Vertragsabschluss.
Hierzu steht eine zentrale Prozesskomponente bereit, die den Vertretern Übersichten über Verkaufschancen pro Agentur oder Kunden zur Verfügung stellt. Der schnelle Überblick schließt Erinnerungen für die Vertreter ein.
Diese Prozesskomponente muss so gestaltet sein, dass die einzelnen am Prozess beteiligten Systeme nicht eng gekoppelt sind und unabhängige Teams und Releasezyklen gewährleistet werden können.
Beratungsprozess
Der Beratungsprozess gliedert sich in die Prozessschritte
- Leadgenerierung und -bearbeitung,
- Aufbau einer Kundenbeziehung,
- Tarifierung und
- Angebot und nachfolgende Schritte.
Leadgenerierung und -bearbeitung
Abb. 1 zeigt die Prozessschritte zur Leadgenerierung und -bearbeitung. Leads – also Kontaktadressen von potenziellen Interessenten – können aus unterschiedlichen Quellen generiert werden. Z. B. kommen Leads aus der Allianz-Homepage, wo eine Interessentin ihre E-Mail-Adresse angibt oder auch aus Marketing-Kampagnen. Diese Leads werden im System angelegt – Erzeuge Lead. Anschließend werden die Leads validiert – ist es eine gültige Adresse, existiert die E-Mail-Domäne, … Leads können sowohl automatisch als auch manuell validiert werden.
Die Funktionen
- Erzeuge Lead,
- Qualifiziere Lead automatisch und
- Qualifiziere Lead manuell
werden in der Domäne Leadmanagement implementiert.
Aufbau einer Kundenbeziehung
Abb. 2 zeigt den Teilprozess Aufbau einer Kundenbeziehung. Ist der Lead qualifiziert, kann die jeweilige Interessentin kontaktiert werden. Ihre Daten werden überprüft und bei dieser Gelegenheit berichtigt und erweitert. Im Anschluss kann mit ihr ein Beratungstermin vereinbart werden.
Steht der Termin an, stellt die Vertreterin die Agentur vor. Die Vertreterin und die Kundin sprechen über die Lebenssituation der Kundin und leiten daraus die persönlichen Risiken der Kundin ab. Für die Absicherung dieser Risiken wählt die Vertreterin zusammen mit der Kundin die zu berechnenden Produkte aus.
Dieser Prozessschritt wird in den drei Domänen Taskmanagement, Kundenmanagement und Beratung implementiert.
Hierbei werden die Funktionen
- Kontaktiere Interessent und
- Vereinbare Termin
durch die Domäne Taskmanagement implementiert. Die Funktionen
- Überprüfe und erweitere Daten
wird durch die Domäne Kundenmanagement implementiert.
Die Funktionen
- Stelle Agentur vor,
- Lebenssituation,
- Risikoerfassung und
- Produktauswahl
werden durch die Domäne Beratung implementiert.
Tarifierung
Abb. 3 zeigt den Prozessschritt der Tarifierung, der eingeleitet werden kann, wenn die Produkte ausgewählt wurden. Dabei wird die Tarifierung jeweils für die ausgewählten Produkte aufgerufen.
Die Vertreterin gibt die Parameter für das jeweilige Produkt an. Dies kann z. B. die Auswahl sein, ob eine Hausratversicherung die Fahrräder der Familie einschließen soll. Anschließend kann automatisch geprüft werden, ob das zu versichernde Risiko akzeptiert werden kann. Kann das Risiko akzeptiert werden, wird der Tarif automatisch berechnet.
Kann das Risiko nicht automatisch akzeptiert werden, wie z. B. für besonders wertvollen Schmuck, kann die Tarifierung manuell durch einen Versicherungsspezialisten, den Underwriter vorgenommen werden [1]. Sie bewertet das Risiko und berechnet den Tarif manuell.
Ist der Tarif manuell oder automatisch berechnet, wird für das jeweilige Produkt ein Angebot erstellt. Sind alle Angebote erstellt, können im Prozess die nächsten Schritte erfolgen. Die automatische Tarifierung erfolgt in der Domäne Tarifierung und die manuelle Tarifierung in der Domäne des Underwriter-Arbeitsplatzes.
Angebot und Follow-up
Abb. 4 zeigt die abschließenden Schritte des Beratungsprozesses. Die Dokumente für die Kundin werden erstellt und an sie übergeben. Die Vertreterin erhält Feedback und vereinbart weitere Schritte mit der Kundin.
Die Kundin kann die Angebote akzeptieren. Hat sie mindestens ein Angebot akzeptiert, werden entsprechende Anträge automatisch erstellt und das entsprechende Risiko nochmals geprüft. Kann das Risiko akzeptiert werden, kann für die Kundin je akzeptiertem Angebot ein Vertrag erstellt werden.
Die Funktionen
- Erstelle Kundendokumente,
- Übergabe der Dokumente und
- Selektiere und akzeptiere Angebote
werden durch die Domäne Dokumentenmanagement abgedeckt.
Die Domäne Beratung nimmt zusätzlich die Funktion Feedback Session und die Domäne Taskmanagement die Funktion Vereinbare weitere Schritte auf. Die Domäne Policierung übernimmt
- die Antragserstellung,
- die Risikoprüfung und
- die Vertragserstellung.
Klassischer Prozessansatz
In einem klassischen Prozessansatz werden alle Domänen durch einen orchestrierenden Prozess gesteuert. D. h. alle Domänen nehmen in ihre jeweiligen Domänenmodelle eine Prozessreferenz als Fremdschlüssel auf, um beim Weiterschalten durch den Prozess die jeweiligen Geschäftsobjekte – wie z. B. einen bestimmten Task oder ein bestimmtes Angebot – ansprechen zu können. Die Verantwortung liegt klar beim Prozess und der Prozess kann so klar nachverfolgt werden. Die Geschäftslogik liegt im Prozess.
Allerdings muss die Prozessreferenz in allen Domänen gleichbehandelt werden, was zu einer engen Kopplung der Fachdomänen mit dem Prozess führt, auch wenn die einzelnen Dienste asynchron über Events miteinander kommunizieren. Durch diese enge Kopplung sind unabhängige Implementierungen im Prozess und in den Domänen kaum möglich. Die einzelnen Dienste sind technisch eng mit dem Prozess gekoppelt.
Fachliche Abweichungen und Rücksprünge vom "Happy Path" werden modelliert. Jede weitere Ausnahme führt zu einer Degeneration des Prozesses und die Fachlichkeit der Domänen steckt in den Verzweigungen und Rücksprüngen des Prozesses.
Beobachtender Prozess
Stellt man sich nun vor, dass die Domänen nicht eine Prozessreferenz, sondern vielmehr der Prozess eine Referenz zu den Geschäftsobjekten hält, können die Domänen und der Prozess besser entkoppelt werden.
Abb. 5 zeigt ein solches Modell. Die Schwierigkeit liegt in der Zuordnung der Geschäftsobjekte zum Prozess, da diese durch die 1-n-Beziehungen nicht mehr eindeutig ist. Allerdings lassen sich Geschäftsobjekte und Prozess aufeinander abbilden, so dass ein oder mehrere Prozesse, die an einem bestimmten Ereignis beteiligt sind, über das Ereignis informiert werden können.
So kann ein Prozess, der an einer Änderung in einem Lead beteiligt ist, über die ID eines Leads gefunden werden. Oder aber der Prozess, dem eine bestimmte Tarifierung zuzuordnen ist, kann anhand der Kunden-ID, der Beratungs-ID und des ausgewählten Produktes gefunden werden. Solche Zuordnungen müssen in einer separaten Abbildungsschicht implementiert werden.
Der Gesamtprozess wird wesentlich einfacher, weil nur noch die durch die Geschäftsdomänen erzeugten Ereignisse beobachtet werden müssen. Steuernde Ereignisse aus dem Prozess heraus sind nur noch in Ausnahmefällen – wie z. B. bestimmte Erinnerungsfunktionen – notwendig.
Technische Architektur
Abb. 6 zeigt die gewählte technische Architektur. Die Beratungsprozess-Komponente kommuniziert über einen Eventbus mit den Domänenkomponenten, die jeweils die eigene Businesslogik und Persistenzschicht implementieren.
Die Beratungsprozess-Komponente enthält die Prozess-Engine und die Mapping-Schicht, um die eingehenden Geschäftsobjekt-Events dem jeweiligen Prozess zuzuordnen.
Im Eventbus werden die jeweiligen Events zu den Konsumenten auf der Prozess-Ebene zur Verfügung gestellt:
- Lead-Event,
- Task-Event,
- Kunden-Event,
- Beratungs-Event,
- Angebots-Event,
- Dokument-Event und
- Vertrags-Event.
Zusätzlich steht auf der Beratungsprozess-Seite ein Task-Producer zur Verfügung, der Taskkommandos erstellen kann, um in der Taskmanagement-Komponente Tasks als Erinnerungen erstellen zu können.
Take-aways
Take-away 1: Ein steuernder Prozess führt zu einer starken Kopplung. Stark steuernde Prozesse führen zu stark gekoppelten Systemen. Prozessindikatoren müssen in den jeweiligen Systemen bekannt sein. Die Geschäftslogik wird aus den Domänen in die Abfragen und Verzweigungen des Prozesses verlagert. Unabhängige und verteilte Entwicklung ist kaum möglich.
Take-away 2: Prozesse können über Events von den produzierenden Systemen entkoppelt werden. Event-getriebene Systeme schaffen entkoppelte Systeme. Die Geschäftslogik liegt in den entsprechenden Systemen. Event-produzierende Systeme können unabhängig von Even-konsumierenden Systemen entwickelt werden. Dieser Vorteil wird durch die zusätzliche Komplexität in der Infrastruktur erkauft.
Take-away 3: Ein beobachtender Prozess erfüllt seinen Zweck. Prozesse müssen nicht immer vollständig orchestrieren. Oft reicht eine kleine Erinnerung, dass der Prozess weiter gehen kann. Der Prozess ist nur beobachtend und greift nur in wenigen Ausnahmenfällen direkt ein. So kann man Systeme unabhängig voneinander halten, ohne die Vorzüge von Prozessen zu verlieren.
