Compte-rendu du Comptoir : Continuous delivery et continuous discovery pour construire l’assurance de demain
Le 16 mai 2023 s’est tenu un nouvel épisode des Comptoirs OCTO, suite à une réalisation d’OCTO Technology chez Wakam : continuous delivery et continuous discovery pour construire l’assurance de demain.
Voici son descriptif : Wakam a comme ambition de réinventer le métier de l’assurance en y introduisant plus de transparence et de sécurisation via la blockchain. Or, ce type d’innovation structurante pose plusieurs questions : qui seront ses utilisateurs cibles ? Quel sera son impact sur les processus métier ? Nous vous présenterons ici une démarche liant expérimentation et déploiement via les outils du DDD permettant de faire pivoter un produit rapidement.
Ce compte-rendu fait écho au replay vidéo de ce comptoir, disponible ici, animé par Thomas Dobrzelewski (Product Owner chez Wakam), ainsi que Mehdi Houacine (consultant @ OCTO) et Sofia Calcagno (consultante @ OCTO, experte DDD), qui sont intervenus chez Wakam.
Lettre de mission initiale d’OCTO chez Wakam, en juin 2022
Wakam est un assureur B2B qui co-construit des produits d'assurance avec ses partenaires afin qu’ils puissent les distribuer en marque blanche partout en Europe. Wakam souhaite proposer des accélérateurs technologiques pour les non-spécialistes de l'assurance, dans plusieurs secteurs : E-retailer, Gig economy, Fintech, Telecom ... Leur vision pour y parvenir est de fournir à ces acteurs des capacités de distribution et de gestion des contrats.
Au cours de l’année passée, OCTO a accompagné Wakam pour une mission sur le métier d’assurance sur blockchain en utilisant la méthodologie DDD (Domain-Driven Design).
Chronologie de l'intervention d'OCTO chez Wakam, de juin 2022 à avril 2023
Initialement, en juin 2022, cet accompagnement portait sur le cadrage du BPO-Middleware : un nouvel asset permettant à Wakam de faire le lien entre leur capacité de distribution (tunnels en marques blanches et APIs) et des sociétés externes de gestion de contrats d’assurance appelées des BPO (pour Business Process Outsourcing) afin d’améliorer le time to market.
A la fin de l’été, le cadrage du BPO-Middleware prend fin, et la phase de delivery commence … mais pas pour développer le BPO-Middleware ! La vision produit a changé au cours de l’été pour s’orienter vers OCPAS, un Policy Admin System sur la blockchain (On-Chain Policy Admin System).
Changement de cap ⛵️
Pendant l’été, en parallèle du cadrage sur le BPO-Middleware, une autre initiative voit le jour chez Wakam sous la forme d’expérimentations autour de l’enregistrement de contrats d’assurance dans la blockchain publique.
L’accompagnement d’OCTO a permis à Wakam de prendre du recul sur ses projets et initiatives en cours concernant le BPO-Middleware et la Blockchain. Ainsi, Wakam a souhaité fusionner les 2 initiatives pour construire une solution avec leur propre Policy Admin System adossé à la Blockchain permettant de faire lien avec sa stratégie d'apporter des solutions techniques à leur partenaires et d’être un acteur de l'écosystème Blockchain.
Avec ce but en tête, le cadrage s’est conclu par la décision repousser le développement du BPO-Middleware pour pivoter vers le développement d’une nouvelle solution nommée OCPAS (On Chain Policy Admin System), un Back Office de gestion de contrats d'assurance où la Blockchain va être utilisée en tant que moteur de validation automatique de règles métier lors des différents moments de la vie d'un contrat : souscription, avenant, rétractation, résiliation, renouvellement,
Ce changement de cap amène de nouveaux enjeux notamment sur la gestion des événements et du modèle de données. La méthodologie DDD a aidé l’équipe à avancer dans ce contexte où l’innovation et les incertitudes sur l’adaptation du métier de l’assurance dans la blockchain sont fortes.
Comment l’outillage DDD nous a aidé lors du cadrage
Source: https://github.com/ddd-crew/ddd-starter-modelling-process
Le Domain-Driven Design (DDD) est une approche dans laquelle s’inscrivent différents outils et méthodes qui permettent de modéliser le problème que l’on cherche à résoudre à l'aide d’un logiciel.
C’est un processus itératif qui va de l'idéation à l’implémentation dans le code et qui permet d’aboutir à une vision avec différents niveaux de zoom et selon plusieurs focus.
Pendant le cadrage, l’équipe a mis le focus sur les parties “Alignement” et “Découverte”, via certains outils que nous allons décrire ci-après.
Event Storming Big Picture
L’accompagnement d’OCTO a démarré par un atelier Event Storming Big Picture.
Ont été invitées dans cet atelier toutes les personnes concernées par ce projet : PO, PM, UX, Développeurs, Métiers, Architectes… afin de construire toute l'histoire du processus métier.
Toutes les personnes invitées à l’atelier se sont réunies dans la même salle, avec un grand mur sur lequel elles ont pu décrire le processus à implémenter à travers d'événements. Ces événements prennent la forme de post-its oranges 🟧, et il est possible de prendre des notes sur les questions et les inconnues qui émergent lors de cet atelier pour les résoudre ultérieurement 🟥.
Le résultat de l'histoire que nous avons décrite devient un support que l’équipe peut faire vivre pendant toute la durée du projet.
Selon Thomas, Product Manager chez Wakam, l’atelier Event Storming a aidé l'équipe à cartographier de la connaissance qui était répartie entre plusieurs personnes chez Wakam et en faire un vrai référentiel pendant tout le cycle de delivery.
Ce référentiel permet également de s’aligner facilement sur la vision produit dans l'équipe. Cela permet aussi d’identifier les zones d’ombre et de facilement chercher des compétences spécifiques en dehors de l’équipe sur ces zones identifiées : par exemple, sur la partie “paiement et cadre réglementaire”.
Comment l’outillage DDD nous a aidé après le cadrage, lors du delivery
Suite à la phase de cadrage, l’équipe de réalisation d’OCPAS (une équipe mixte de développeurs, ops et product owners, OCTO et Wakam) et a aussi intégré la démarche DDD lors du développement des nouvelles fonctionnalités, à la fois pour rédiger les user stories mais aussi pour les coder.
Elle a pour cela fait des ateliers autour du Bounded Context canvas et de l’Example Mapping. Ils se sont d’ailleurs servis des critères d’acceptance issus de ce dernier outil pour écrire les tests fonctionnels automatisés de l’application.
Bounded Context canvas
Source: https://github.com/ddd-crew/ddd-starter-modelling-process
Il s’agit d’un framework permettant de décrire dans quel domaine une solution s’inscrit et d’expliciter les attentes de l’équipe sur celle-ci, en termes de responsabilité, de stratégie, et d’implémentation.
Cet outil permet de faire l’inventaire des requêtes, commandes et événements qu’il reçoit d’autres domaines et qu’il leur renvoie. Il sert également à répertorier les règles métier à appliquer lorsqu’il reçoit une commande, un événement ou lorsqu’il effectue une requête.
Example mapping
L’Exemple Mapping est un atelier qui s’inscrit dans la méthodologie BDD (Behavior-Driven Development), dans lequel se réunissent développeurs et PO pour faire émerger les règles métier sur la base d’exemples construits collaborativement en séance.
Dans le cadre d’OCPAS, ces ateliers se basent sur les évènements et commandes identifiés lors de l’Event Storming pour construire des exemples :
Que se passe-t-il lorsqu’une rétractation est effectuée 15 jours après la souscription du contrat ?
Et 12 jours ?
Et si un sinistre a été déclaré ?
Cet atelier permet à l’équipe de décortiquer des cas métier complexes, expliciter les cas passants et les cas non-passants pour la rédaction des user stories, ou encore prioriser la gestion des cas non-passant selon la probabilité qu’ils surviennent.
Implémentation dans le code
Les événements (post-its oranges) décrivent une situation métier initiale (Given) et la commande (post-it bleu) décrit une action (When) d’un système externe ou d’un utilisateur à l’attention du produit développé.
Les exemples issus de l’atelier précédent (Example mapping) peuvent être directement implémentés dans le code, en servant de base aux tests fonctionnels, créant ainsi un lien solide entre modèle et code.
Comment l’Event Storming a impacté la vision produit ?
Thomas Dobrzelewski, Product Manager chez Wakam, considère que l’Event Storming a eu un impact très positif sur la vision produit. Le changement de cap a laissé une période très courte pour cadrer cette nouvelle vision, mais l_’Event Storming a permis de le faire efficacement, en permettant notamment de définir un langage partagé par toutes les parties prenantes du projet (métier et tech) dans un cadre métier et technique complexe. Pendant la phase de delivery, leDDD et les ateliers d'Event Storming ont permis de passer très peu de temps en grooming/refinement et d’identifier les sujets sur lesquels se concentrer._
Pour sa part, Sofia Calcagno, experte DDD et développeuse, retient que le DDD en général et l’Event Storming en particulier ont permis d’accélérer la compréhension du métier par les développeurs, qui n’avaient pas forcément déjà travaillé dans le monde de l’assurance. Cela a également permis de les intégrer dans la conception du produit et ainsi diminuer le nombre d’aller-retours entre les développeurs et le métier pour clarifier les sujets. Enfin, le DDD a permis de faire la part entre la complexité métier et la complexité technique, qui était particulièrement importante dans le cadre d’OCPAS.
Ce compte-rendu fait écho au replay vidéo de ce comptoir, disponible ici, animé par Mehdi Houacine (consultant @ OCTO), Sofia Calcagno (consultante @ OCTO, experte DDD) et Thomas Dobrzelewski (Product Owner chez Wakam).