Marvel Architecture Universe - Romain Taillade, La Duck Conf 2022

Introduction

Romain Taillade a clôturé cette édition 2022 de la Duck Conf en exposant une méthodologie qui a su transformer les pratiques de conception de Décathlon. Conscient de devoir clore une longue journée, Romain a relevé le défi et a réussi à nous tenir en haleine du début jusqu’à la fin, en commençant par le titre. Pour ça il a voulu rendre l’architecture épique, et quoi de plus épique aujourd’hui qu’un film de super-héros?

Le thème est posé, la conférence peut commencer !

Lorsque nous parlons d’architecture, nous aimons bien nous ramener à des choses très rationnelles en parlant de technologies, de diagrammes... Et pourtant il y a plein d’autres mécanismes qui vont influencer notre architecture.

Nous sommes rapidement projeté au cœur du film: ”Si la tech était notre super-pouvoir alors résoudre techniquement tous nos problèmes reviendrait à dire que celui qui a le meilleur pouvoir gagnerait tout le temps.”, autrement dit, Batman serait le pire des loosers car il n’a pas de super-pouvoir. Or on sait tous que Batman est le meilleur grâce à sa capacité d’analyse et son intelligence.

C’est dans ce contexte à mi-chemin entre fiction et réel que Romain nous propose un voyage assez fondateur dans leur organisation pour voir comment ils ont réussi à déjouer certains pièges au sujet de la résistance au changement.

Scène 1: L’origin story

Un film de super-héros répond à un schéma narratif qui commence par l’origin story. S’il n’y a pas la mort de l’oncle Ben, il n’y a pas de spiderman, l’origin story chez Décathlon est intéressante par la nature de son activité, qui depuis 40 ans se donne comme mission de démocratiser le sport. Décathlon a pour particularité la maîtrise de sa chaîne de valeur , et ce, de la conception de leurs produits à la vente sur leurs canaux de distributions. La forte croissance de Décathlon les amène à un changement de modèle initialement auto-centré vers un modèle orienté plateforme, ce qui implique une rupture dans la façon d’opérer le business et nécessite de repenser l’architecture de sorte à facilement répondre aux opportunités. Initialement l’architecture de gauche (cf: schéma ci-dessous), très verticale tend à devenir une architecture plus horizontale avec en son centre, un ensemble de business capabilities agnostique de l’extérieur et exposé via un composant Core Platform

Mais voilà le problème, la structure de communication interne se suffisait à elle-même. La façon de travailler des équipes reposait principalement sur leur pragmatisme plutôt que sur un formalisme avec des standards et de la documentation. L’objectif de Décathlon est clair, il faut construire un nouveau modèle, sans rompre avec l’ancien, tout en incluant un large panel d’interlocuteurs.

Scène 2: Le Nemesis

C’est dans ce contexte qu’intervient le méchant, le nemesis de l’organisation qui porte le le doux nom d’expert. De par ses caractéristiques, il possède un pouvoir de censure qui peut faire du tort à l’organisation. Car la vitesse de changement de l’entreprise est plus ou moins conditionnée par la vitesse de changement de l’expert, si cette vitesse est nulle alors il n’y a pas de transformation. Mais d’où lui vient ce pouvoir? Et bien, principalement de sa stature issue de ses expériences et de son savoir exclusif mais pas que... Nous sommes tous victimes de nos biais cognitifs. Si l’on se réfère à la théorie de Daniel Kahneman sur le Système 1 / Système 2: Les deux vitesses de la pensée, avec un système 1 rapide, intuitif et un système 2 plus lent, réfléchi et logique, l’expert est amené en entreprise à se fier davantage à son système 1 moins énergivore, de la même manière il peut être amené à s’exprimer sur des sujets qui ne sont pas dans le périmètre de son expertise et ainsi fonder ses propos sur des croyances. Vous l’aurez compris, c’est un personnage compliqué. Même si connaître le passé ne nous garantit pas de savoir le futur, il était nécessaire dans cette démarche de transformation de se confronter aux experts pour initier l’après. Le combat commence, les premières défaites s’ensuivent...

Scène 3: Les Première Défaites

Pour exposer sa vision, Romain a tenté plusieurs approches:

• la pause café avec les experts, échec... Romain n’a pas tenu plus de 15 minutes face à un expert et sa phrase lapidaire: “ça ne fonctionnera pas, c’est plus compliqué que ça !”

• discuter avec les experts hors site, échec (mais avec du mieux)... le premier jour s’est déroulé sans accrocs, de même pour le second, et arriva le troisième, qui lui fut ardu, mais constructif. Le fait d’être à huis clos obligea les experts à verbaliser ce qui n’allait pas dans le modèle en gamifiant l’approche, l’expert devait casser le modèle et le corriger, ce fut la première itération. Un échec certes, mais un échec constructif.

Scène 4: La bataille finale

L’échec étant un processus d’apprentissage, Romain n’en démordait pas, tel Batman, il a fait intervenir son esprit d’analyse et fît le constat suivant:

• Il est impossible de solliciter l’attention d’un interlocuteur plus de 30 minutes

• De nombreux sujets parasites venaient interférer avec le fond de la discussion (technologies, performances...)

• De nombreux cas ne sont pas documentés, l’expert est en capacité de discréditer des arguments en y juxtaposant un cas particulier.

• Un expert a la critique facile en opposant l’idée à la réalité

• L’expert aime bien casser le modèle

Les précédents défaites permettent donc à Romain d’élaborer une méthode pour remporter la bataille finale:

• mettre de côté les égos

• mettre en place des règles qui vont permettre de garder les interlocuteurs actifs et concentrés

• la méthode se doit d’être légère et appropriable car l’architecture doit être un savoir faire de tous et non la propriété de certains.

Cette méthode itérative a pour objectif d’obtenir la connaissance sans emporter le biais. Elle se déroule en deux phases, une de préparation et une de challenge. Pour la phase de préparation, la discussion est initiée autour des business capabilities, orientée design by contract pour identifier tous les entrants et sortants du produit afin d’obtenir une représentation élargie du modèle.

Pour mettre en pratique cette méthode il fallait des outils pertinents:

• Markdown pour la syntaxe

• JSON pour la modélisation des objets

• Github pour le versionning et le stockage

• Mermaidjs pour la réalisation d’un diagram as code afin de modéliser les interactions

Le modèle prend forme avec un document de synthèse qui se compose de concepts, d’activités et de versions.

Concept:

• Key definitions: Une énumération des concepts que l’on manipule dans le projet

• Key changes: Un résumé des grands changements

Activités

• Interactions Schema: Un schéma d’interaction sur lequel figure les acteurs, le contexte, la séquence...

• Contract Modelisation: Une modélisation de contrat en JSON

• Use Cases: la somme des cas d’utilisation

Versions

• Content: Changement apporté pour cette version

Grâce à cette méthode, c’est l’équivalent de 10 ans de connaissances qui a  été documentée en 4 semaines à force de petites itérations. 18 mois après, l’application sur laquelle cette méthode a été appliquée atteint 1 milliard d’appels APIs, c’est devenu un asset stratégique de l’organisation. Cette méthode s’est généralisée et est utilisée pour créer de nouvelles business capabilities, comprendre en profondeur les problématiques, les potentiels impactes d’une solution... C’est la victoire !

Takeaway

• Décathlon n’est pas une petite organisation, c’est la preuve qu’une méthode légère permet de faire de la modélisation rapide

• On peut légitimement se poser la question: Quis custodiet ipsos custodes? Qui me gardera de mes gardiens? Déléguer aux experts nous offre une position confortable, néanmoins cela peut faire du tort à l’organisation et c’est la raison pour laquelle il faut permettre aux experts d’être dans les conditions qui vont rendre possible leur transformation. Car lorsque l’on manage mal la vitesse de changement de l’expert, on accepte que la vitesse de transformation de l’entreprise soit celle dictée par l’expert.