Julien Topcu - Loi de Conway: Lorsque votre conception produit se fache avec votre organisation (FR)

[00:00:05] Merci.
[00:00:09] Vous ne vous en êtes pas rendu compte, mais vous venez de quitter le beffroi de Montrouge. Il va être important pour la suite des opérations que vous gardiez votre calme car vous venez d'être projeté dans une nouvelle dimension qui s'appelle Lighty Zone dans laquelle vous allez traverser trois périodes.
[00:00:28] Vous voici maintenant en 50 après J.-C., c'est-à-dire en 2020 de notre ère, dans un pays de l'Europe de l'Ouest qui s'appelle la Gôlerie. Et vous êtes maintenant chargé de mission dans au ministère de l'éducation. Le gouvernement de la Gôlerie a décidé de réformer son système éducatif. Et par l'intermédiaire de votre supérieur, vous apprenez que vous allez devoir organiser un colloque dont le but est de réfléchir aux grandes tendances des évolutions du secteur de l'enseignement.
[00:00:57] Et comme dans toute organisation qui se respecte, le top down n'est jamais loin, on vous on vous recommande de faire appel à des cabinets externes. Vous avez même pas le temps de protester que votre supérieur vous explique que cette demande émane directement de
[00:01:14] du Dieu Jupiter lui-même. Alors vous l'aurez compris, il s'agit ici d'une dystopie anachronique gallo-romaine et toute ressemblance avec des faits d'actualité récents sera peut-être fait exprès.
[00:01:28] Alors on vous glisse au passage, il va falloir faire appel au cabinet qui s'appelle Makini. Alors Makini, vous avez déjà entendu parler, mais vous savez pas réellement ce qu'ils font. Alors vous décidez bah d'aller sur leur site internet.
[00:01:41] Le voici. quelque chose de très triomphant, il y a l'arc tout ça. Vous aurez à noter que d'ailleurs Makini dans la Zone, ça s'écrit avec un S qui se prononce pas, c'est pour éviter toute poursuite judiciaire à la suite de Stock. Et puis et puis Gory ça s'écrit France. Donc, qu'est-ce que Makini ? Donc c'est à priori une entreprise engagée dans les transformations décisives de ses clients, on ne sait pas trop pour l'instant. Donc le but, c'est de savoir comment ils peuvent vous aider pour organiser un colloque sur le la réforme de l'éducation. Donc en descendant un petit peu, un petit peu plus d'informations. Donc, bon, ils sont là depuis 64, super. accélérateur de l'innovation dans 200 domaines d'expertise. Donc ça c'est quand même un on dirait un très gros cabinet de conseil, 200 domaines d'expertise, c'est pas donné à tous les cabinets. Mais ce qu'on peut remarquer, c'est qu'en gros en plein milieu, on vous dit qu'il y a 5000 profils technologiques pour l'éducation. Vous savez pas trop comment ça peut vous aider, mais c'est écrit en gros du coup, ici on peut se demander bah n'est-ce pas une une entreprise, une SN par exemple.
[00:02:48] Bon, en en scrollant un petit peu, on crée un petit peu d'empathie, on présente l'équipe. Alors pas n'importe qui quand même. parce que vous avez la directrice générale, le membre du Conseil d'administration et une chef du fil du pôle d'assurance. Et oups, quand on clique dessus, a priori, il y a plein de choses à dire sur le haut management de Makini. Bon, revenons en arrière, c'était pas fait exprès. Mais ici, vous avez un call to action, le premier du site. qui vous invite à avoir d'autres profils. Alors on s'entend, d'autres profils, ça reste quand même des directeurs et des senior directors. Et pour chacun d'entre eux, vous découvrez qu'ils sont, comme on va dire, spécialisés sur certains pôles comme la pharmaceutique, le digital, ils font des choses avec leurs doigts et puis le luxe. Donc, vous vous demandez bah peut-être qu'il y a des gens qui sont spécialisés dans l'éducation.
[00:03:40] L'enseignement.
[00:03:43] Bon, a priori pas là. Mais on va on va continuer quand même, on va on va creuser.
[00:03:51] OK, donc nous voici sur la page principale.
[00:03:55] Ah, on a un petit peu maintenant démonstration de savoir-faire. Donc ici des publications sur la croissance en Europe, augmenter l'espérance de vie en bonne santé, vaincre le cancer, le métaverse, donc encore rien sur l'éducation. Mais vous continuez.
[00:04:11] OK. Donc bah non, on a on voulait pas vraiment aller travailler chez eux. Donc là, on peut se demander mais à qui est destiné ce site ? à des clients potentiels ou bien des candidats ? C'est très confus tout ça. Donc si vous continuez, bon, il y a juste la position de leur bureau à Paris et un formulaire de contact qui va être très utile là pour le coup. Puisque il faut qu'on leur envoie l'appel d'offre.
[00:04:32] Mais vous n'avez toujours pas compris comment ils peuvent vous aider sur l'éducation. Cependant, vous vous rappelez que quand vous êtes arrivés, il y avait un menu qui est plus là d'ailleurs, hop, faut remonter.
[00:04:44] Et vous accrochez, là, ça fait bien 5 minutes que vous êtes sur le site, hein.
[00:04:48] On va aller cliquer sur notre métier et il y a des boules qui tournent en 3D.
[00:04:54] Ce qui ce qui va renforcer un petit peu ce côté où mais c'est une entreprise technologique ou pas ? On comprend plus rien. Mais avec la petite flèche qui descend, qu'est-ce qu'on va voir ? Ah, alors là c'est intéressant, enfin. En tout cas, ce qu'on nous montre c'est qu'il y a des pôles de compétences sectorielles et des pôles de compétences fonctionnels, dont l'aérospatiale, la chimie, l'éducation. Alors ça c'est c'est cool parce que c'est exactement l'information qui nous qui nous manquait.
[00:05:19] Et en dessous bah le design, le digital, le marketing et cetera. ce que et là ce que vous avez découvert, qu'est-ce que c'est ? C'est le fait que Makini est organisé d'une manière matricielle, on dirait. Bon, mais ça c'est une information qui vous sert pas à grand-chose. Bon, une fois que vous cliquez sur éducation, là, enfin, il y a la proposition de valeur, leur savoir-faire sur l'éducation. Et puis bon bah des témoignages et cetera, mais bon, on va pas changer une formule qui gagne. Du coup, on a quand même ici tous les partenaires et senior partners du pôle et il faut savoir que ça c'est le haut de la chaîne alimentaire, les business line ne seront pas sur le site. Donc en définitive, vous avez d'abord plus appris sur l'organigramme de Makini. Et sur son organisation avant même de savoir comment il pouvait répondre à vos besoins, alors que vous êtes des clients potentiels.
[00:06:07] Du coup, vous repartez avec une sensation un petit peu amère. Vous vous dites, mais enfin, c'est très bizarre tout ça, je reste un petit peu sur ma faim. Mais sachez que cette sensation elle vient pas de nulle part. Ça vient du fait que vous venez de vous frotter à Lighty Zone. Lighty Zone, c'est un monde où croyances et sciences se mêlent et qui sont et qui régissent par des forces qui poussent les gens à faire des choses des fois un petit peu bizarres. On pourrait on pourrait blâmer les les les designers. de Makini pour avoir fait un site avec une expérience qui est pas terrible pour les pour les clients potentiels. Mais en réalité, ce n'est pas qu'un problème de pratique. Il y a quelque chose qui les a potentiellement poussé à faire cela. Et pour expliquer ce phénomène, il faut revenir en 98. Le 13 juillet, le New York Times publie un article sur le docteur Jacob Nielsen. Alors comme sa photo ne l'indique pas, c'est pas lui qui a inventé la souris. Mais le docteur Jacob Nielsen, qui était ici défini comme le gourou de l'ergonomie de la page web à cette époque-là, c'est un des pionniers de la user experience. Et il s'est lancé un défi à cette époque-là, c'était de rendre le web plus utilisable. Et il avait noté quelque chose dans les années 90, c'est que les entreprises qui créent leur site internet faisaient tout pour optimiser un indicateur pour l'indexation de moteur de recherche qui s'appelle le SEO, non. Il y en avait un autre avant.
[00:07:34] Le CIO. Qui connaît le CIO ?
[00:07:38] Personne. Toi tu connais ?
[00:07:41] Tu es sûr ?
[00:07:43] C'est le C level Igo optimization.
[00:07:47] C level, c'est le haut management. En fait, un an plus tôt, le docteur Nilsen avait créé un article qui s'appelle Top Ten Mistake of web management et dans le numéro dans le numéro 3 des erreurs les plus communes. C'est le fait d'avoir un site qui reflète la structure de son organisation. Et ce qu'il dit, c'est que les utilisateurs ne devraient pas savoir comment votre compagnie est organisée, ils ne devraient même pas être capable de le déduire de la structure de votre site. Il dit aussi, un signe classique de ce problème de de gestion de site, c'est que sur la homepage, il y a un bouton pour chacun des seniors vice-présidents de la compagnie. Plus personne fait ça aujourd'hui.
[00:08:26] 97.
[00:08:28] Bizarrement, c'est exactement ce que vous venez de vivre. Il est rejoint en 98 par Nigel Bevan qui dans une étude qui s'appelle Usability Issues in website design. explique pourquoi les sites sont si frustrants à utiliser, notamment parce que les organisations produisent souvent des sites dont le contenu et la structure reflètent les intérêts de l'organisation plutôt que les besoins utilisateurs. Et là on peut se poser la question si Makini effectivement a pas une volonté d'être plus présent sur la tech. parce que on vous a mis pas mal de choses tech en avant. Mais ça, vous en tant que au ministère de l'éducation, ça vous est pas non plus.
[00:09:09] Donc, on peut se dire, si ces mauvaises pratiques sont documentées depuis les années 90, qu'est-ce qui pousse aujourd'hui les designers à encore faire cela ? Ça, on va le voir dans quelque temps, mais vous voici maintenant reprojeté dans une nouvelle époque. Vous voici à Redmonde dans la région de Seattle aux États-Unis en 2008. Et vous êtes maintenant directeur du marketing chez Microsoft. Et vous êtes en train de définir la stratégie de communication pour booster les ventes de votre nouveau fleuron qui est Windows Vista.
[00:09:42] Et votre patron déboule furieux dans votre bureau parce que votre concurrent vient de publier un spot publicitaire. qui relate des tout petits défauts de votre remplaçant de Windows XP.
[00:09:53] Bonjour, je suis un Mac. Et je suis un PC. ici avec de bonnes nouvelles pour tous ceux qui ont déjà été frustrés par Vista. Vous réglez le problème ? Non, je les rends plus faciles à vivre avec ma nouvelle gamme de thés apaisants. Il y a le thé à la camomille Crashi Time, juste ce qu'il faut pour apaiser les nerfs après un crash lié à Vista. Ou si Vista fait ralentir vos applications, il y a la patience à la grenade. Et pour les matins, il y a le temps de redémarrage à la framboise. C'est plutôt paisible. Aussi les après-midis. Mais nous devrions passer à autre chose. Oui, passons à autre chose, Mac. À ma gamme de sels de bain anti-stress Vista.
[00:10:24] ça c'était un vrai spot publicitaire, ils en ont fait plusieurs comme ça.
[00:10:28] Donc, c'est la catastrophe.
[00:10:31] Parce que en effet, vos clients, l' enfin vos clients, vos utilisateurs, l' des des plantages en série de votre nouvelle OS et des incompatibilités matérielles passe repassent à Windows XP. Et ils vont même certains chez le concurrent à la pomme croquée. Et la pression est telle que vous êtes obligés de laisser les constructeurs de PC et bien revendre des nouvelles machines sur Windows XP. Mais dans ce malheur, il y a deux chercheurs de chez Microsoft et un de l'université du Maryland qui se demandent si rétrospectivement, on n'avait pas des moyens pour prédire la, on va dire, la prédisposition à la panne des modules de Vista. Donc, ils ont lancé une étude sur les 50 millions de lignes de code. Là c'est un bon monolithe quand même. Non, c'est des il y a quand même 3404 binaires. Donc il y a 3404 modules. Et ils ont évalué plus plusieurs indicateurs, on va dire qui sont généralement utilisés pour la qualité issu d'étude scientifique. Le premier, c'est le code churn. Ça c'est la quantité de fois que le même morceau de code est changé, rechangé, rechangé avant d'aller en prod, ce qui peut être un petit smell de complexité par exemple. La code complexity, pour ceux qui connaissent complexité cyclomatique. Il y en a qui savent pas ce que c'est. Bon bref, c'est des ifs et machins, enfin bref, c'est la complexité du code pour simplifier. Dependency, c'est le couplage. C'est fait qu'une partie du code et bien est est fortement couplée au aux autres parties du code, ce qui fait que si vous avez une modification là, ça va casser cette partie dépendante. Le code coverage que vous devez connaître qui est la couverture en test et le nombre de bugs avant la release. Mais ils ont rajouté aussi un autre indicateur qui est la structure de l'organisation. Et dans la structure de l'organisation, ils sont dit on va évaluer aussi certaines choses qui sont pas forcément techniques. Dans ces choses-là, ils se sont dit on va prendre des postulats. On va considérer que plus de gens touche au code, moins bonne est la qualité. Que si vous perdez une grande partie des gens dans l'équipe, parce qu'ils se sont barrés, et bien ça affecte la rétention de connaissance et donc la qualité. Que plus la personne qui a le pouvoir de décider sur le composant est proche des ingénieurs qui le modifient, meilleure est la qualité et plus les contributeurs à composant appartiennent à la même équipe, meilleure est la qualité. Il y en a d'autres. Et ils se sont dit bon ça ça voyons si ensemble, ça peut être un bon indicateur de prédiction de panne sur les modules de Vista. Parce qu'en fait, rétrospectivement, ils savent quel module ont été en panne et ceux qui n'ont pas été. Donc, ils vont regarder le coverage de ces modules, ils vont regarder voilà, chacun des indicateurs.
[00:13:13] Alors j'ai pas vous expliquer la différence entre le recall et la pression bien que je puisse la faire, mais le but là, c'est d'avoir 100 % dans chacune des colonnes. c'est-à-dire qu'ils ont été le plus précis possible. Et l'étude a montré que organizational structure était beaucoup plus précis que les autres indicateurs traditionnels. Donc dans le cadre de Windows Vista, ils ont démontré que la structure de l'organisation avait plus d'impact et était était un meilleur indicateur aux prédispositions de panne des composants qu'un truc comme le code coverage. Cette étude qui s'appelle The Influence of Organizational Structure on Software Quality and Empirical Case Study de 2008. a permis de démontrer que l'organisation, organization eats code quality tools at breakfast. Pour paraphraser Peter Drucker. En réalité, l'intention des chercheurs à ce moment-là. était de vérifier un postulat qui avait été fait plusieurs décennies avant ça, en 1975 par le docteur Frédéric Brooks dans le bouquin qui s'appelle le Mythe du mois homme. Dans ce dans ce livre, il explique que la qualité du produit est grandement affectée par la structure de l'organisation. Ce livre au passage est fortement décommandé aux adeptes du diagramme de Gantt, le risque de malaise vagal résultant est trop important. Je vois qu'il y en a qui ont lu le bouquin.
[00:14:38] Alors, est-ce que vous sentez ces petits ces petits picotements derrière la nuque ? Ça c'est parce que vous venez encore de faire un bon dans une autre époque.
[00:14:49] Ça c'est le son du R qui vous amène à la défense. Vous allez à Courbevoie en 2016 et vous vous rendez au siège de la multinationale de qui qui multinationale de voyage en ligne pour laquelle vous travaillez en tant qu'architecte. Cette société, je la nommerai pas, mais elle existe vraiment. Et dans cette société, vous avez défini une architecture pour le système de réservation de billets de train. Comme celle-ci. Vous avez déterminé avec les équipes de développement que c'était la meilleure manière de répondre aux besoins. Il faut savoir que cette entreprise vend des billets de train dans le monde entier. Et chaque train est différent. La manière de gérer du train, quel que soit le pays, est complètement différente. Et comme l'entreprise ne veut pas faire du code custom pour chacun des pays, sont décidé d'avoir une expérience agnostique et uniformisée pour les utilisateurs. Donc la manière dont on va gérer le train en France va être la même chose qu'en Italie. Ce qui fait qu'on a une architecture ici agnostique. Non spécifique à chacun des trains nationaux. En bas Rail supply c'est pour l'interconnexion avec les compagnies ferroviaires de chaque pays, comme vous pouvez l'imaginer, elles ont chacune des API différentes. Le but c'est de la fédérer en une seule API qui est Rail supply. Au-dessus Rail shopping c'est la c'est la logique métier en gros. C'est ce qui vous permet de sélectionner un train, son tarif et puis et puis le siège et cetera et au-dessus la UI.
[00:16:13] Et donc cette architecture était choisie il y a 3 ans.
[00:16:16] Et vous décidez maintenant de sortir de votre tour d'ivoire pour aller voir ce qu'on fait les équipes de développement. Vous avez notamment eu vent que ces logiciels là, enfin ces services, ces microservices même si on veut utiliser le le M word.
[00:16:30] deviennent de plus en plus difficile à maintenir. Et en jetant un œil au code, stupéur, il a été produit exactement ce qu'on ne voulait pas. C'est-à-dire que chacune des des briques était découpable par pays. True story, hein.
[00:16:45] Alors, vous vous êtes dit mais euh comment c'est possible ? Est-ce que il y a un problème de compétence chez les développeurs ? En réalité, alors ce que je vous ai oublié de dire, c'est qu'en plus ce qui aurait dû être mutualisé en terme de fonctionnalité s'est retrouvé dupliqué bien sûr dans chacun de ces If mon pays.
[00:17:02] Donc, après quelques investigations, vous avez vu que ça venait d'une fausse croyance. En tout cas, d'une incompréhension de ce qu'était les feature team de la part du management. Pour le management, les feature team, c'est génial. Parce que avec les feature team, les gens sont autonomes, ils peuvent taper partout. Normalement, ils sont censés développer des features, mais une feature égale un projet, n'est-ce pas ? Donc, le pire, c'est que ces trois équipes qu'ils avaient à leur disposition étaient sur des time zone différentes. Et ils se sont dit bah ce sera plus simple de les organiser par train. Parce qu'en plus, on veut d'abord livrer le train anglais, ensuite le train allemand et puis le train français. Donc, on a des équipes qui ont des managers différents, des deadlines différentes, des objectifs différents, sur des time zones différentes, rajouter de la pression et voilà ce qui se passe. C'est-à-dire que bah on doit assurer sa propre deadline. Donc ce qui va ce qui va se passer, c'est qu'on va se protéger. On va faire if mon cas. parce que les copains qui sont à côté, bah je vais pas trop leur parler et puis ils sont même pas réveillés pendant que je suis en train de coder. Donc euh je veux pas les casser et je veux pas qu'ils me cassent. Voici le résultat. Donc en définitive, on a construit un système qui s'est écarté du design voulu.
[00:18:17] Et le pire dans tout ça, c'est que comme le ownership de chaque composant n'est pas clair, personne ne veut payer l'assainissement. Personne.
[00:18:30] Donc, maintenant, on pourrait peut-être repenser aux indicateurs de structure organisationnelle de Vista. Je pense qu'il y a beaucoup de choses à dire là-dessus. Mais en vrai là, il semblerait que Lighty Zone essaie de vous envoyer un message. Il semblerait que votre expérience utilisateur, votre conception produit, la qualité du produit et du code et votre architecture soit grandement impactée par votre organisation et même peut-être impactée d'une manière très négative. On pourrait même se demander si la structure de l'organisation est peut-être pas meilleure que certaines bonnes pratiques opérationnelles.
[00:19:08] Donc ici on a fait qu'exposer des faits, mais à aucun moment, on a expliqué le phénomène. Pour expliquer le phénomène, il faut revenir en 1968, c'est un peu vieux quand même. Non mais en 1968. le docteur Melvin Conway publie un article qui s'appelle How do Communities Invent dans la revue Data Motion. Il explique comment les organisations design des systèmes. Et on va faire un petit exercice, vous allez voir, vous pouvez le reproduire dans toutes vos organisations.
[00:19:36] Ça va être très facile. On va prendre un système. Un système, qu'est-ce que c'est ? C'est tout ce que vous voulez, ça peut être une page web, un service, un produit, un téléphone, une voiture en physique, tout ça sont des systèmes. que certaines bonnes pratiques opérationnelles. Donc ici on a fait qu'exposer des faits. Mais à aucun moment on a expliqué le phénomène. Pour expliquer le phénomène, il faut revenir en 1968. C'est un peu vieux quand même. Mais en 1968, le docteur Melvin Conway publie un article qui s'appelle How Do Communities Invent dans la revue Data Motion. Il explique comment les organisations design des systèmes. Et on va faire un petit exercice, vous allez voir, vous pouvez le reproduire dans toutes vos organisations.
[00:19:35] Ça va être très facile. On va prendre un système. Un système, qu'est-ce que c'est ? C'est tout ce que vous voulez. Ça peut être une page web, un service, un produit, un téléphone, une voiture en physique. Tout ça sont des systèmes.
[00:19:50] Et chaque système peut être découplé en sous-système, n'est-ce pas ?
[00:19:56] Euh pardon, excusez-moi. Donc chaque système, ici, j'ai pris un système e-commerce. qui a quatre sous-systèmes, donc un qui est dédié à la gestion d'utilisateur, un pour les fonctionnalités de shopping, un autre pour le paiement et puis un autre pour la facturation qu'on appelle billing. Et Melvin Conway se demande s'il y aurait pas une relation prévisible entre la structure de ce système et la structure de l'organisation qui l'a produit. Il remarque que, de manière très simple, on pouvait trouver pour chacun de ces sous-systèmes une équipe en charge. OK. Bon, ça je pense que vous pouvez tous faire le même constat. Et bien sûr, pour que ce système fonctionne, certains de ces sous-systèmes doivent s'interfacer. Donc ici, par exemple, shopping va devoir s'interfacer avec user pour récupérer potentiellement des informations d'utilisateur. Une interface en informatique, ça peut être une appel d'API avec un transfert de données. dans un système électrique, ça peut être une prise avec une fiche qui rentre à l'intérieur, et dans la mécanique, notamment l'automobile, ça peut être des pièces mécaniques qui s'emboîtent, comme par exemple, un volant moteur et un embrayage. Et Melvin Conway remarque que si deux si deux sous-systèmes doivent s'interfacer, alors les équipes qui sont en charge doivent communiquer ensemble pour définir et négocier un contrat.
[00:21:12] Un contrat qui spécifie cette interface. Il note aussi que généralement, ça ça dépend des entreprises, mais euh c'est ce besoin de communication va être souvent animé par un coordinateur, une coordinatrice. Dans le monde actuel, parce que là on était en 68, on peut considérer que c'est les Scrum Master ou les product owner. Et il remarque aussi, bah qu'en deux sous-systèmes doivent pas s'interfacer, comme par exemple shopping et billing, il y a pas besoin de négocier de contrat, donc il y a pas forcément besoin que ces équipes, et bien, communiquent ensemble.
[00:21:46] Donc, ce qu'il remarque, c'est qu'il y a une relation étroite quand même entre la structure du système et la structure de l'organisation qu'il a produit. Alors, souvent, on peut avoir une équipe en charge de plusieurs sous-systèmes, par exemple, une équipe payment billing. Dans ce cas-là, c'est une version compactée de la structure du système. Et là, ce qu'on est en train de dire, c'est que ce mimétisme là de entre la structure du système et la structure de l'organisation qui l'a produit, c'est ce qu'on appelle un homomorphisme. Et là, peut-être que vous dites qu'il a vous vous dites qu'il a pas inventé l'eau chaude, mais là, c'est le drame. Parce que un homomorphisme, ça a des propriétés qui peuvent être très embêtantes des fois. Notamment, prenons une organisation, comme celle-ci. Mais on part de zéro. à part le fait qu'on a déjà défini cette organisation. Donc on part d'un besoin, on n'a pas de structure de système. Le but d'une organisation qui doit construire un système, c'est d'évaluer, enfin c'est de penser à aux solutions possibles, et d'évaluer la meilleure solution pour répondre aux besoins. OK ?
[00:22:51] Maintenant, on va s'imaginer comme étant omniscient. Et qu'on est capable nous de lister toutes les solutions possibles de l'univers pour répondre à leur besoins. On va les limiter à deux parce que sinon c'est trop compliqué. J'ai pas de place sur les slides. Et on va considérer aussi que la solution du bas, c'est la meilleure, arbitrairement, hein.
[00:23:09] Alors, ce qui est important, c'est que de savoir c'est que nous on est omniscient, donc on le sait. Eux, ils le savent pas encore. Ils ont même pas conscientisé encore ces solutions, n'est-ce pas ? Ils ils sont pas là. Ce qu'on peut remarquer de différence entre la première et la deuxième solution, c'est que dans la deuxième, il y a une interface entre user et billing et ici, il y a un système check-out, qui existe pas au-dessus. Donc on va dire que dans le cas du dessus, les responsabilités qui sont là sont réparties entre shopping et paiement. Ce que vous pouvez voir aussi, c'est que la structure de l'organisation qui est à droite là, ben ressemble pas du tout à la structure de la meilleure solution. Mais plutôt de la première. Donc est-ce que cette organisation là, qui a déjà été choisie par le management, va être en mesure bah de produire ce design là ? Si on si on croit la règle de l'homomorphisme, bah non, elle va plutôt produire le premier design.
[00:24:03] Parce que pourquoi ? Bah, déjà, on a conditionné les gens d'une certaine manière, hiérarchiquement et managérilement, pour communiquer d'une certaine manière. Ce qui fait qu'ici, comme il y a pas de communication conscientisée entre user et billing, ils peuvent ne jamais se rendre compte qu'en discutant ensemble, ils vont découvrir un besoin d'interfaçage ici des systèmes, qui va trouver une meilleure solution au problème.
[00:24:29] Et puis, comme le management existe déjà, et qu'ils ont prédéfini des scopes sur chacune des équipes, comment voulez-vous que deux équipes déjà constituées avec des managers différents, comme par exemple shopping et paiement, conscientisent le fait que il y a des responsabilités là et là, qui pourraient être regroupées dans une autre dans un système ? On les a conditionné pour penser d'une certaine manière.
[00:24:51] En fait, il faut comprendre que dès que une une organisation est choisie, vous avez fait déjà d'une certaine manière des choix de design, volontairement ou non. Et ces choix d'organisation va exclure de manière complètement involontaire des solutions possibles.
[00:25:13] Et même si ces solutions sont les meilleures. parce que vous avez biaisé en fait quelque part le procédé de recherche. Conway explique que dans les années 60, il existait une structure de huit personnes qui devaient développer un compilateur COBOL et un compilateur Algol. Si vous savez pas ce que c'est qu'un compilateur, c'est un logiciel. Pour des soucis de budget et de timing, ils ont décidé de les répartir euh 5 sur le compilateur COBOL et 3 sur le compilateur Algol. En résultat, ils ont eu un compilateur COBOL en cinq phases et un compilateur Algol en trois phases. Alors que c'est à peu près la même chose. Alors, il s'avère que quelqu'un n'est pas d'accord avec ça. Tom Cheatham en 96 disait que si vous prenez cinq personnes, vous leur demandez de faire un compilateur COBOL, le compilateur s'exécutera en quatre phases. Parce qu'il faut bien quelqu'un fasse le manager.
[00:26:05] Alors Conway décrit bien plus clair en plus.
[00:26:10] Il dit que si vous prenez, bah par exemple, au tout début de d'un système, il y a un besoin, vous allez mettre un petit groupe de personnes qui vont essayer de de comprendre le besoin. Mais souvent ce qui se passe, c'est qu'il il y a de la pression en terme de de budget et de timing. Et un manager sait que si par hasard, il rate sa deadline, et qu'il a pas pris toutes les ressources qu'il avait à sa disposition, on va lui faire leur proche. Et ça, ça va mettre une pression sur les designers initiaux du système, qui eux préféraient peut-être continuer à travailler ensemble pour euh tacler la complexité, la réduire jusqu'à trouver une solution, au lieu de fragmenter le savoir euh dans des sous-groupes différents.
[00:26:55] Malheureusement, l'histoire montre que bah le management ne veut pas prendre le risque, et ces personnes sont renforcées et renforcées pour maximiser les chances de réussir la deadline.
[00:27:07] Ça, ça vient d'une croyance, dit Conway, que le travail est linéaire. Certaines personnes pensent que le travail de deux personnes sur 4 mois, c'est équivalent au travail de 8 personnes sur un mois. D'ailleurs, Frédéric Brooks, pour se moquer de ça, a écrit dans son livre qu'une grossesse humaine ça prend 9 mois, quel que soit le nombre de femmes qui vous a assigné à la tâche.
[00:27:29] Donc, revenons à cette structure.
[00:27:35] Le truc c'est que dans une entreprise, généralement, il y a des règles managériales. On vous explique comment doivent être constitué les équipes, les rôles que vous devez avoir par défaut, et cetera et cetera. Ce qui fait que une organisation va naître parce que la règle c'est pas plus de deux personnes dans une équipe, un manager par équipe. OK, super. Ce qui veut dire que vous avez une organisation par défaut avant même d'avoir analysé le besoin. Et une fois que l'organisation existe, elle sera utilisée. Mais le besoin là, bah bien falloir c'est trop gros là, maintenant, il va falloir que chacune des équipes ait un morceau du besoin. Bah, on va le splitter et le resplitter d'une manière plus ou moins arbitraire. Ce qui fait que les intersections comme celle-ci, là en gris, bah, les équipes vont pas forcément les détecter. Parce qu'on a polarisé la manière dont les gens allaient réfléchir. On a créé des silos. En plus c'est même pas les mêmes les mêmes management là. Il y a des gens qui rigolent et qui se regardent, à mon avis, ça sent le vécu.
[00:28:32] En fait, ce qui s'est passé, c'est que voilà, en délégant, bah, on perd aussi de la connaissance.
[00:28:39] Ce que dit Conway, c'est que il n'existe pas de groupe de design qui est à la fois organisé et non biaisé.
[00:28:47] Et ça il faut bien le comprendre. Votre organisation va biaiser une certaine manière ce que vous allez construire.
[00:28:54] Alors, ce que dit Conway, parce qu'il va encore plus loin, c'est que la la communication s'est complètement désintégrée au moment même où il y a eu une délégation. Parce que les deux euh designers initiaux, ils ont dû prendre de la hauteur pour pouvoir synchroniser et déléguer les choses. Donc ils se sont éloignés du besoin. En faisant ça, ils ont fragmenté le savoir en des sous-groupes. Ce qui fait que notamment euh là, si vous avez en plus euh deux personnes hiérarchiquement assez loin en terme d'équipe, qui doivent se mettre d'accord. Elles arrivent pas à se mettre d'accord. Qu'est-ce qui se passe ?
[00:29:32] Ça va escalader. Et là, on va demander à des gens qui sont maintenant plus loin de l'analyse, de faire un choix. Bon, admettons qu'ils y arrivent pas. On va encore escalader avec quelqu'un qui est encore plus loin du besoin et qui va devoir faire un choix. Donc ce que dit Conway, c'est que dans les structures comme celle dans dans ces structures là, généralement, la structure de communication va tendre à sa structure administrative, hiérarchique. Et avec la loi de l'homomorphisme, cette structure administrative va se retrouver dans ce que dans le système produit. C'est pour c'est pour cela que pour Conway, les militaires ont tendance à créer des systèmes qui ressemblent à leur organigramme.
[00:30:13] Donc tout ça, il le résume en cette phrase, il explique que la structure des grands systèmes tend à se désintégrer pendant le développement de manière qualitativement plus que les petits systèmes. à cause de cette désintégration de la communication et de ce système bureaucratique qui naît.
[00:30:31] Brooks schématise un peu plus la désintégration de la communication. Quand vous aviez euh trois personnes dans l'équipe, vous aviez trois canaux de communication. Mais quand on est passé à 11, on n'avait pas passé en 11 canaux, mais 55 canaux de communication. Ce qui veut dire que l'effort de communication, il n'est pas linéaire. Quand vous rajoutez des gens, l'effort n'est pas linéaire. Ça devient de plus en plus compliqué.
[00:30:57] Et ce que dit aussi euh et du coup, le comme l'effort de communication n'est pas linéaire, l'effort de travail ne l'est pas non plus. On a vu aussi que une équipe de trois personnes ne va pas produire la même chose qu'une équipe de 11. On l'a vu là avec le compilateur Algol et et COBOL.
[00:31:13] Et ce que dit Conway, c'est que si vous prenez trois personnes bien choisies, ils vont produire un meilleur système que 11 personnes, parce que toutes les hypothèses qu'on fait qui sont vraies de parallélisme qui sont vraies quand on est plus des pommes de terre, bah ce n'est pas vrai quand on design des systèmes.
[00:31:31] Et le fait même de rajouter des gens, en fait, va plutôt faire tendre parce qu'on veut s'assurer de la date, va plutôt faire tendre la structure vers sa structure bureaucratique qui va rajouter des des surcoûts de synchronisation et de communication pour les équipes.
[00:31:48] D'ailleurs, plus tard, en 75, du coup toujours, Brooks explique que si vous rajoutez des gens sur un projet en retard, ça accroît le retard.
[00:32:00] Donc ce qu'explique Conway, c'est qu'il devient nécessaire de restreindre la communication pour faire en sorte que les gens puissent s'assurer que le travail soit fait. D'ailleurs, qui s'est jamais plein d'avoir trop de cérémonie ? C'est jamais arrivé à qui que ce soit, ça ? Non ?
[00:32:15] Trop de réunions.
[00:32:19] Bon Kenny l'a déjà fait, mais
[00:32:22] Du coup qu'est-ce qu'on peut dire de méga structure à scale sur étagère, agnostique de système, qui vous explique qu'il faut que vous ayez un grave complet de communication ? Qu'est-ce que ça va produire ça comme système ? Pour ceux qui savent pas c'est safe 5.1. Moi j'ai la dernière version, Kenny il avait la 5.0.
[00:32:42] Alors je vous ai pas encore énoncé réellement la loi de Conway. La loi de Conway dit que les organisations qui design des systèmes sont contraintes à produire des designs qui sont des copies de leur de la structure de leur communication.
[00:32:58] Et c'est pour cela notamment que sur le site de Makini, la première chose que vous avez découvert, bah, c'était leur hiérarchie. Et le pire c'est que plus vous avanciez dans le site, plus vous descendiez dans l'organigramme. Et ça on peut pas le nier, on l'a vraiment vécu. La deuxième chose que vous avez pris, c'est leur structure matricielle d'organisation, avant même de savoir comment il pouvait vous aider à répondre aux besoins. Et là, c'est un exemple.
[00:33:23] d'endroit où la structure de communication a tendu vers leur structure administrative et qui s'est retrouvé dans le soft, voilà, dans le site internet.
[00:33:37] Dans le cas de l'agence de voyage en ligne, comme bien qu'on avait défini une architecture agnostique, comme on a organisé les équipes par pays, bah, ça a donné des softs qui étaient découpaables par pays.
[00:33:52] Et dans le cas de Vista, et bien, on a vu que la qualité de l'organisation était un meilleur euh, enfin un meilleur indicateur de prédiction à la panne que les indicateurs classiques. Et ça, c'est un des effets de l'homomorphisme de Conway aussi.
[00:34:11] Alors ce qui est assez marrant, c'est que si on regarde dans le détail ce qu'ils avaient mis dans leur organisationnel structure, qu'une grande perte des membres de l'équipe affecte la rétention de connaissance, blablabla, que plus les contributeurs à un composant appartiennent à la même équipe, meilleur est la qualité. Et plus la personne qui a le pouvoir de décision est proche des ingénieurs, meilleur est la qualité. en fait, on est juste à l'inverse de la désintégration de la communication que citait Conway.
[00:34:38] Une étude de 2012 qui s'appelle Exploring the Duality Between Product and Organizational Architecture a test of the Mirroring Hypothesis a comparé, enfin vient corroborer un peu plus la loi de Conway. En fait, ils ont comparé des logiciels open source avec des logiciels équivalents payant, commerciaux. Par exemple, un logiciel calculatrice Open source versus un logiciel calculatrice commerciale.
[00:35:02] Et ils se sont rendus compte que les logiciels open source qu'ils ont comparé étaient généralement plus modulaires et et moins sujets à comment dire étaient plus facile à modifier. Et ils ils ont enfin ce qu'ils disent c'est que cela est sûrement dû au fait que les structures commerciales enfin les entreprises sont en fait des structures qui sont très fortement couplées.
[00:35:30] par rapport à l'Open source. parce que dans l'Open source, vous avez des gens qui sont volontaires, ils ont pas de boss, euh c'est au bon vouloir, ils ont même pas d'objectifs formels entre eux. Donc c'est vraiment l'extrême en terme de couplage faible. Et c'est comme ça qu'ils expliquent la différence.
[00:35:51] Alors, sommes-nous euh du coup euh con enfin, condamnés à vivre ces effets-là de la loi de Conway ? Et va-t-on rester bloqué dans l'IT zone ?
[00:36:02] Alors, vous allez pas pouvoir éviter cette loi, mais vous allez pouvoir potentiellement gérer un petit peu ses effets. En fait, ce que Conway dit, c'est qu'il faut il faut s'organiser selon le besoin, l'effort de communication. Donc d'abord, analyser le système, le simplifier, enfin, en ce qui est gérable, c'est-à-dire en sous-système. Puis regarder les besoins d'interfaçage entre ces sous-systèmes et qui va définir les besoins de communication. Donc ce qui va nous permettre en fait, de restreindre au strict minimum les canaux de communication entre les équipes pour s'assurer que le travail soit fait.
[00:36:39] Mais là, on a un problème.
[00:36:42] C'est que bah, on sait très bien que le premier design qu'on choisit, c'est jamais le meilleur parce que déjà, on s'améliore, parce que les besoins peuvent évoluer, donc les besoins en terme de design vont aussi évoluer. Ce qui veut dire que pour que les choses soient efficaces, il faut que la l'organisation soit flexible dans sa manière de communiquer et de s'organiser. Donc là, d'une certaine manière, Conway a décrit une nouvelle classe d'organisation de gestion euh de design et d'organisation qu'on a nommé plus tard en inverse Conway Manover ou Reverse Conway Manover. En fait, ce nom a été donné en 2015 par James Lewis, Technical Director chez ThotWorks pendant le grand essor des microservices dans l'IT zone. En fait, James Lewis, avec ses équipes, eu l'idée folle de se dire qu'il fallait peut-être commencer à organiser les équipes plutôt de la manière dont on voulait avoir euh enfin de la même enfin que la structure de l'organisation devait plutôt refléter la structure du de l'architecture qu'on voulait avoir plutôt que de partir des équipes déjà faites et leur dire suivez ce qu'il y a marqué comme architecture sur le papier. Et il y a d'autres personnes qui sont qui s'inscrivent pas euh dans dans la lignée des Inverse Conway Maneuver, qu'ont à peu près la même idée. En 2017, vous avez Yann Bosch, qui est professeur au Chalmers University of Technology et ancien VP euh Nokia du du Nokia Research Center, qui a écrit en 2017 euh un article qui s'appelle Structure It Strategy. Et il explique le modèle Bapo. Modèle Bapo, c'est de dire, le point de départ de tout, c'est la manière dont on veut créer de la valeur à nos utilisateurs et la manière dont on veut générer du revenu. À partir de ça, on fait des choix architecturaux et technologiques pour répondre aux besoins, qui est le A. Ensuite, une fois qu'on a défini l'architecture, on va définir les outils, les manières de travailler, ce qu'on va appeler le P. Et une fois qu'on a le B, le A et le P, et bien on crée l'organisation. Et il remarque que généralement, les entreprises ne sont pas BAPO mais sont OPAB. Donc tout à fait l'inverse. Qui part d'une d'une organisation déjà préétablie. Puis va déterminer des process par pure convenance parce que bon, on avait déjà une organisation. Donc ça nous arrange. Et que malheureusement ces process vont créer une architecture accidentelle. qui va être restrictive et qui va limiter les équipes dans leur manière de faire de l'innovation et de créer potentiellement une nouvelle offre commerciale. fois qu'on a défini l'architecture, on va définir les outils, les manières de travailler, ce qu'on va appeler le P. Et une fois qu'on a le B, le A et le P, et bien, on crée l'organisation. Et il remarque que généralement, les entreprises ne sont pas bapô mais sont opab. Donc, tout à fait l'inverse. qui part d'une d'une organisation déjà pré-établie. Puis il va déterminer des process par pure convenance parce que bon, on avait déjà une organisation. Donc ça nous arrange. et que malheureusement ces process vont créer une architecture accidentelle. qui va être restrictive et qui va limiter les équipes dans leur manière de faire de l'innovation et de créer potentiellement une nouvelle offre commerciale.
[00:39:24] Ce qui est assez marrant de noter, c'est qu'en 98, Nigel Bevan donnait déjà des des bonnes pratiques pour mieux pour avoir une meilleure user experience. Donc il en donnait plusieurs. Enfin, il donnait un truc ordonné. en disant d'abord euh définir les les objectifs business, la la structure du site et son contenu, le design des pages, les méthodes d'évaluation, c'est les métriques.
[00:39:47] Comment on valide les mocap vis-à-vis de nos panel d'utilisateur, et cetera? Et puis euh on s'organise. Et ce qui est très drôle, enfin d'ailleurs dans management, il va même un peu plus loin, il dit pour chacune des pages, il faut voir quelles sont les compétences et les niveaux de compétence qu'on a besoin, par exemple cette page-là, c'est du statique, celle-là, c'est du dynamique, là il y a du CSS, là il y a de l'HTML, bref. Et une fois qu'on a ça, on s'organise. Et ce qui est très drôle, bah, c'est que si vous prenez le modèle bapô, ça match.
[00:40:17] Alors, là, on a un petit peu un process en méta, mais que peut-on faire, on va dire à chacune des étapes? Parce que ça peut être très physique. Enfin qu'est-ce qu'on peut faire pour pour s'assurer de bien identifier le business, l'architecture, le process et l'organisation. Bah, il y a des gemmes se met un petit peu partout dans la zone et je vais vous en présenter quelques-uns.
[00:40:40] Le premier, c'est le Domain Driven Design.
[00:40:44] Les gens qui connaissent le domain Design dans la salle, super. Donc c'est un bouquin qui a été écrit en 2003 par Eric Evans, qui partait d'un constat. Il s'est dit en fait euh les gens se trompent de combat. Ils ont pas compris où était la complexité du logiciel, enfin, pas toute la complexité du logiciel. Et il passe à côté de la complexité essentielle, qui est le business. Donc maintenant, on va créer une philosophie qui remet au centre le business du développement. Et on part du business seulement pour ensuite arriver à une architecture. Alors, comment on procède?
[00:41:17] Alors déjà, le Domain Driven Design sépare deux espaces. Si vous étiez là à la conférence de Kenny, il en parlait un petit peu. Il dit que l'espace, enfin l'espace du problème, on va le séparer de l'espace des solutions. Le problème c'est que généralement, les gens font la confusion des deux. On a l'impression d'analyser le problème alors qu'ils sont en train de construire une solution et ça, c'est très problématique parce que ça biaise.
[00:41:37] Donc on va séparer les deux, et donc l'espace du problème ça correspond au business, l'espace solution à l'architecture. Et le Domain Driven Design, dans sa toolbox qui s'appelle les les pattern stratégique, va nous offrir des moyens bah de d'analyser les deux. La première chose à faire, donc le business, c'est de cartographier le besoin, le problème. Et on va le faire avec des experts métiers. Et l'avantage c'est qu'on n'a pas besoin d'une grosse organisation pour ça. On prend les experts métiers, on les met dans une salle, on prend des profils pluridisciplinaires qui vont être en charge de commencer à analyser la solution. Et on met tout ce monde dans ce tout ce beau monde ensemble. Et le but, bah bien sûr, c'est de comprendre quel est le besoin. Généralement, ça se fait au moyen d'un atelier qui s'appelle l'event Storming. L'event Storming ça a été inventé par Alberto Brandolini. Et un event Storming, ça consiste à lister les domain event, donc les événements qui sont importants pour le métier et les ordonner. En faisant ça, bah on écrit ici le flux de création de valeur pour nos utilisateurs. Ensuite ce qu'on va faire,
[00:42:46] enfin, mécaniquement plutôt, ces événements-là ordonnés vont faire émerger des concepts métiers. On va les lister. Ici, par exemple, vous avez catalogue, item, carte, price, order, paiement.
[00:42:57] Et pour chacun de ces concepts métiers, on va analyser leur ligne de vie. On va voir jusqu'où, en fait, ils sont présents et jusqu'où ils vivent. Ça va créer des frontières. Et ces frontières, on va les appeler des bounded contextes, c'est ou ce contexte métier. Là par exemple, vous avez un contexte shopping et un contexte paiement. Et là, vous êtes déjà en train de taper sur l'architecture. En fait, ici, ce que vous avez, c'est déjà une première version de vos sous-systèmes.
[00:43:27] Après, on peut aller encore plus loin. C'est-à-dire qu'avec euh le contexte map, on est capable de expliciter les relations entre ces sous-systèmes, entre ces bounded contexte. Alors par exemple, ici, mon OHS, c'est Open Service et pour simplifier, c'est une API. Et et on va dire par exemple là, que shopping a besoin de user. Enfin, des informations de user. Mais ce qu'on veut faire très attention, c'est que le modèle métier de user, on veut pas qu'il pollue shopping, du coup, on va mettre un truc qui s'appelle l'anti-corruption layer. Moi, je vais pas rentrer dans le détail, mais ça permet déjà d'avoir des considérations, on va dire d'architecture fonctionnelle. Mais ça va même plus loin parce qu'on va mettre les rapports de force entre chacun
[00:44:08] de ces de ces sous-systèmes. On peut dire, par exemple, il y a une relation upstream-downstream. Ça veut dire quoi? Ça veut dire que user ici, il peut vivre sa vie et être successful indépendamment de shopping. Mais si user plante, il emmène shopping avec lui. Mais l'inverse c'est pas vrai, c'est-à-dire que shopping a forcément besoin de user pour euh pour ne pas être en échec. Si user est en échec, lui il échoue aussi. Mais l'inverse, pardon, ce que je voulais vous dire, c'est plutôt que si lui échoue, user s'en tape. Enfin, il s'en fiche. On peut aller encore plus loin. On peut dire, et là si on a déjà une topologie d'équipe. En fait, la relation entre ces deux contextes, c'est que pour que shopping s'assure de pouvoir utiliser euh enfin d'avoir les informations dont il a besoin de user avec une là la relation elle est de type customer supplier, donc il va falloir faire prioriser dans la backlog de user et bien les besoins de shopping. Parce que sinon, ils vont jamais réussir à aller en prod.
[00:45:05] Et ça va en même encore plus loin parce qu'on a partnership, on a conformist, je vais pas tous vous les faire. Mais là, on est en train déjà de gratter un petit peu le P de bapô.
[00:45:14] Donc avec le Domain Driven Design stratégique, on va être capable de cartographier le business avec un foostorming, de faire émerger des bandi de contexte, donc une architecture fonctionnelle, et de mettre en lumière les rapports de force entre les contextes et les processus les process de communication éventuels. Cependant, le Domain Driven Design stratégique ne vous donne pas beaucoup de bille sur comment vous organiser. Est-ce qu'il faut une équipe par sous-système ou plusieurs sous-systèmes pour la même équipe? Et d'ailleurs, le Domain Design passe complètement à côté bah des fonctions qui sont un petit peu plus support vis-à-vis du métier. Par exemple, les équipes qui sont en charge bah de déployer l'infrastructure de l'entreprise en terme de réseau. Tout ça, on en parle pas dans le Domain Design, ni euh comment faire en sorte d'être ultra flexible en terme d'organisation. Mais heureusement pour nous, en 2019 sort Team Topologies. Alors il y a d'autres méthodes mais là je vous parlais de Team Topologies qui traite du P et du O. Et en fait, Team Topologies prend les choses d'une manière un petit peu nouvelle et un petit peu différente en disant qu'il faut limiter la taille des soft à la charge cognitive que peut gérer une équipe. Et ça, c'est assez nouveau. Ce qui veut dire que le but là, c'est de faire en sorte que l'équipe peut sereinement en fait, gérer tous les besoins du logiciel, le déployer, le maintenir et le construire. S'ils font trop de choses, ils vont se noyer. Donc il faut restreindre les logiciels, enfin en tout cas leurs tâches, à la charge cognitive qui peuvent gérer. Et ils sont allés analyser les types d'équipes qu'on trouve généralement dans les entreprises, ils en ont analysé quatre.
[00:46:53] Les stream-aligned team, on va plutôt assigner à des bandis de contexte qui sont là pour créer de la valeur métier. C'est des équipes pluridisciplinaires qui sont autonomes dans la manière de créer le software, de le développer, euh de le maintenir et de le déployer. Il y a d'autres équipes, c'est les enabling team, ça peut être par exemple des équipes de coach qui sont là pour faire monter en compétence les autres. Et le but des enabling team, c'est de réduire la charge cognitive des stream line team. Autant que les platform team. Les platform team, c'est par exemple, si vous demandiez à une équipe métier qui fait vraiment du métier qui dans dans un cas où c'est pas de l' IT for IT, hein. D'aller apprendre Kubernetes, pour ceux qui connaissent. Ils vont jamais s'en sortir. C'est trop compliqué et en plus de le faire bien, c'est très très compliqué. Donc vaut mieux avoir des spécialistes qui vont s'occuper de ça, qui s'appelle en plus, si vous connaissez le Domain Driven Design plutôt la la complexité obligatoire, le gérer et le fournir comme un service au reste de l'entreprise, notamment pour les stream line team.
[00:47:53] Et puis il y a les complicated sub system que je ne parle dont je ne parlerai pas là parce que c'est compliqué d'en parler.
[00:48:00] Waouh, merci. Mais en fait, les complicated sub system, pour en dire deux mots, c'est plutôt c'est des c'est des composants qui ont besoin d'une très haute euh
[00:48:10] expertise assez spécifique, notamment, vous avez besoin de data scientist et c'est le seul endroit où il y a besoin de data scientist parce qu'ils vont faire la détection de fraude et c'est des rôles que vous avez pas forcément envie ou besoin de répartir dans toutes vos équipes.
[00:48:24] Et donc ils ont une charge cognitive assez spéciale parce qu'elle est très haute en terme de technicité, quoi.
[00:48:30] Et Team Topologies, comment on va nous aider là? Bah admettons qu'on reprend de nos système notre système avec nos équipes shopping et paiement. Et qu'elle sentent que ça commence à gratter là sur cette histoire de est-ce que il y aurait pas des responsabilités un petit peu à cheval entre nous et et vous là, on a l'impression d'ailleurs que vous faites un petit peu des choses qu'on a écrit. Elles peuvent passer dans un mode qu'on appelle dans Team Topologies, la collaboration. Le mode de collaboration, ça veut dire que ces équipes là vont travailler de manière étroite pendant un certain temps et cette et de telle manière à commencer à tacler une complexité, une nouvelle forme de complexité qui ont pas l'habitude de de tacler. Ce qui fait que la charge cognitive, elle va augmenter pendant un certain temps. Et là, potentiellement, ils vont peut-être déterminer que la meilleure solution, c'est de passer à ça. En admettant qu'on a euh un management compréhensif et qu'on leur explique, bah voilà, il y a un nouveau système, il y a tout ça comme taf et tout. S'ils décident, bah, OK, de créer une nouvelle équipe.
[00:49:31] Là, on va passer dans un notre mode parce que on a défini les responsabilités, on a défini les besoins d'interfaçage, par exemple, shopping.
[00:49:39] Pardon, checkout a besoin de shopping, paiement a besoin de checkout en information. Là, on passe sur une relation qui s'appelle X as a Service. Ce qui veut dire que shopping fournit un service à checkout et checkout fournit un service à paiement. Et ces règles-là, en fait, permettent de dire bon, on va limiter la charge de communication parce que ici il y a un service documenté et cetera. Et et un contraint d'interface qui a été négocié avec checkout. Il y a d'autres choses dont on va pas rentrer dans le détail comme par exemple, bon la facilitation. Ou là, vous pouvez avoir une équipe d'architecture qui fait monter en compétence l'équipe checkout parce que, par exemple, elle connaît pas les microservices ou elle connaît pas le DDD. Mais voilà, donc là, en fait, euh je vous donne, pardon, je vous parle de Team Topologies assez rapidement mais c'est juste pour vous expliquer que c'est un pattern dynamique euh d'organisation qui fait attention aux différentes charges cognitives qui existent dans l'organisation, les réparti et vous donne des interactions possibles. Il y en a trois, c'est celle-ci.
[00:50:40] Un exemple de Team Topologies chez Docker. Donc on n'a pas l'habitude, c'est un peu difficile à lire, je vous l'avoue.
[00:50:48] Et maintenant, ce que vous avez vu, pardon, j'ai raté ma, mais c'est pas grave.
[00:50:54] Donc, ce que vous avez vu aujourd'hui, c'est la loi de Conway, qui dit que les organisations qui design des systèmes sont contraint de produire des designs qui sont des copies de leur structure de communication. Vous avez vu que l'expérience utilisateur, le conception produit, la qualité du produit et du code et l'architecture peut être grandement impactée par les effets de la loi de Conway si on n'y fait pas attention. Mais maintenant comme vous avez l'inverse manœuvre avec le bapô appuyé par euh Domain Driven Design stratégique et Team Topologies, vous allez pouvoir gérer au mieux la loi de Conway. Enfin pardon, les effets de la loi de Conway. Alors ce que j'ai oublié de dire, c'est que Team Topologies, bien sûr, veut que les équipes soient organisées selon le flux de création de valeur. C'est pour ça que ça se marie assez bien avec le Domain Driven Design. Si si vous êtes un peu réticent, sachez que Accelerate, donc qui est une étude scientifique qui est sortie en 2018 va corroborer un petit peu plus euh bah là pour le coup, c'est plutôt les manœuvres de Conway inverse. Si vous avez jamais lu ce bouquin, je vous invite vraiment à aller à aller le regarder, jeter un œil. Alors juste pour terminer,
[00:52:07] il faut faire attention parce que la la Reverse Conway Manoeuvres, c'est pas une Silver Bullets, c'est pas une c'est pas une comment dire, c'est pas une baguette magique. En fait, c'est pas parce que vous allez vous réorganiser que magiquement le système, il va changer en fait. Parce que si votre design est rigide, changer l'organisation va avoir un impact très limité. Mais c'est ce que dit Matthias Varrasse, Veras, pardon, dans son article qui s'appelle Conway's Law doesn't apply to design. où il explique bah, en fait, ce qu'il faut faire attention, c'est que si vous êtes sur un monolite très vieux et qu'on peut rien modifier dedans, l'organisation, ça va vous coûter cher pour des effets très limités. Donc il faut d'abord investir sur l'effort de design et l'assainissement du système.
[00:52:54] avant d'espérer pouvoir se organiser. C'est pas magique, c'est ça qu'il faut comprendre. Donc la loi de Conway, il faut que ce soit vu comme une contrainte. Si vous ne pouvez pas changer l'organisation, en fait, c'est plutôt votre architecture qu'il va falloir adapter. Parce que l'organisation, c'est c'est pas toujours bah à votre main, vous n'êtes pas forcément décisionnaire sur l'architecture.
[00:53:15] Et la Reverse Conway manoeuvre, c'est juste un outil qui n'est pas une Silver Bullet.
[00:53:24] Donc je m'appelle Julien Topçu, je suis tech coach chez Xodo, qui est une ESN et un studio qui se spécialise dans le software craftmanship et le Domain Driven Design. Et dans ma grande bonté, je vous ai ramené au Béfroid de Montrouge. Et faites attention à vos croyances parce que sinon, vous risquez d'être bloqué dans l' IT zone. Merci.

Transcription