Sandro Mancuso

[00:00:15] D'accord, alors
[00:00:18] Écoutez, nous, nous en tant qu'entreprise, nous sommes une société de conseil, nous nous spécialisons dans le logiciel artisanal, donc la majeure partie du travail qui est pertinent pour cette discussion, euh, j'ai été impliqué dans Agile depuis les débuts et puis, euh, je me suis fortement impliqué dans le mouvement du logiciel artisanal. Euh, et à travers le mouvement du logiciel artisanal, j'ai fini par, euh, être très, euh, comment dire, euh, concentré sur la qualité, sur les tests, euh, et j'ai fini par écrire un livre et ensuite parler beaucoup de l'artisanat logiciel. Euh, Mais ce qui s'est passé, c'est que beaucoup d'entreprises qui ont adopté Agile par le passé, elles, elles ont senti qu'il manquait quelque chose, principalement du côté de l'ingénierie. Et, et à cause de cela, ils ont commencé à s'intéresser à l'artisanat logiciel et ils ont voulu améliorer leurs systèmes, améliorer leur technologie, la façon dont ils construisent les logiciels.
[00:01:18] Et, et continue aujourd'hui, c'est presque une centaine, euh, de personnes, euh, une entreprise. Alors, ce qui nous est arrivé était, euh, un peu inattendu d'une certaine manière, parce que comme les entreprises voulaient adopter de meilleures pratiques techniques, les entreprises qui étaient axées sur, euh, l'amélioration de leurs pratiques techniques, l'amélioration de leurs systèmes, euh, la modernisation de leur technologie, elles avaient tendance à être des entreprises un peu plus grandes avec un très grand écosystème rempli de très vieux systèmes avec de vieilles technologies, euh, et nous avons dû appliquer le logiciel artisanal, euh, et des techniques de programmation extrême et bien d'autres choses dans des environnements difficiles, ce n'était pas juste comme commencer à partir de zéro. Euh, parce que quand on part de zéro, on ne ressent pas la douleur d'un mauvais logiciel, n'est-ce pas ? On le ressent quand on a déjà ces systèmes stratégiques. Et et presque par accident, nous avons fini par nous spécialiser dans ce que nous appelons aujourd'hui des projets de modernisation de logiciels, parce que nous sommes, nous n'essayions pas seulement de changer les pratiques, mais aussi de moderniser ces systèmes. Donc,
[00:02:32] cette discussion, l'idée de cette discussion est venue parce que je crois que la plupart des gens, euh, qui regardent cette discussion, peut-être ceux qui ont une formation plus technique, nous voyons assez souvent beaucoup de problèmes. Nous voyons beaucoup de choses qui ne fonctionnent pas bien, le système n'est pas bien conçu, ou il n'y a pas de test, et, et donc nous voyons beaucoup de problèmes techniques. Et les personnes qui ont une formation plus orientée business, elles sont aussi souvent frustrées que tout prenne beaucoup de temps à faire, donc chaque fonctionnalité qu'elles veulent, euh, il semble, euh, pour elles que ça prenne une éternité, n'est-ce pas ? Alors,
[00:03:11] Alors, nous avons tous ces différents types de personnes, toutes constatant différents types d'inefficacités, euh, dans les processus, dans le logiciel, mais très souvent, nous ne parvenons pas à justifier la correction de ces choses. Alors, combien d'entre nous, euh, ont pensé maintes fois, pourquoi les autres ne voient pas ces inefficacités ? Pourquoi je ne peux pas les convaincre de nous donner du temps pour refactoriser ça ou de nous donner du temps pour changer ça ou d'aller dans le cloud ou tout ce que vous voulez faire. Alors, c'était ça l'inspiration de cette présentation, c'est que, euh, pour quiconque veut mener le changement technique, comment s'y prendre ? Parce que nous avons dû nous y prendre nous-mêmes, n'est-ce pas ? Donc, depuis de très nombreuses années maintenant, c'est ce que nous faisons. Nous, nous avons besoin de ces entreprises qui ont des problèmes, les gens qui nous parlent normalement, ils veulent mener ces changements, mais ils ne parviennent pas à justifier, ils ne parviennent pas à associer une valeur commerciale à cela. Et c'est pourquoi nous appelons cela une approche stratégique de la modernisation logicielle, n'est-ce pas ? Alors,
[00:04:16] Tout d'abord, il faut définir, euh, un peu ce qu'est la modernisation logicielle. Je veux faire une distinction ici. c'est que, euh, la modernisation logicielle dans le contexte dont je parle ne concerne pas ces petites refactorisations, ou, euh, l'ajout de tests a posteriori, peut-être que le système n'a pas de tests, donc vous voulez ajouter des tests ou ou des refactorisations. Pour moi, cela fait partie de votre processus normal, n'est-ce pas ? Lorsque vous travaillez avec le logiciel, vous avez la règle du boyscout, vous nettoyez les petits morceaux. Vous ajoutez quelques tests ici et là. Euh, c'est pour moi juste une partie normale. Mais pour moi, quand on parle de modernisation logicielle, on parle de quelque chose de plus stratégique. C'est quelque chose de beaucoup plus long terme, de beaucoup plus difficile à changer, cela aura un impact. Euh, donc, donc normalement, euh, et aussi ça ne peut pas être fait partout, ça doit être très ciblé. Alors, c'est ainsi que j'aime le définir, c'est un processus continu d'amélioration des systèmes stratégiques afin d'accroître l'agilité commerciale, n'est-ce pas ? Alors, pour moi, ces mots-là, ils ont un sens. Tout d'abord, ce n'est pas quelque chose que l'on commence et que l'on termine, si une entreprise dépend de la technologie, dépend de certains systèmes, elle devrait de toute façon avoir un programme d'amélioration continue. Et, et cela est axé sur les systèmes stratégiques. Cela peut également varier avec le temps, à mesure que l'entreprise évolue, à mesure que, euh, l'activité change, différents types de systèmes ou différents types de fonctionnalités deviendront plus ou moins stratégiques. N'est-ce pas ? Et le but de changer ces choses n'est pas seulement parce que nous le voulons, n'est-ce pas ? Nous devons avoir un objectif en tête et normalement, la technologie devrait alimenter l'entreprise, et c'est pourquoi l'accent est mis sur l'agilité commerciale. Alors,
[00:06:00] J'essaie de souligner ceci parce que pour la plupart d'entre nous, beaucoup de techniciens avec un bagage technique, nous voulons conduire le changement technique, mais nous ne pouvons pas conduire le changement technique si nous ne lions pas ce que nous voulons faire à la valeur commerciale. Et c'est ce que j'essaierai de couvrir ici. Alors, pourquoi ne parvenons-nous pas à défendre ces changements ? S'il y a tant d'inefficacités, tant de, tant de frustration de la part de tant de gens, pourquoi ne parvenons-nous pas à justifier ?
[00:06:35] Assez souvent, euh, encore une fois, je ne dis pas que tout le monde est pareil, je rapporte juste ici ce que je vois le plus souvent, n'est-ce pas ? Alors, mais très souvent, lorsque nous essayons de, de, de piloter le changement, euh, nous avons tendance à proposer une solution, n'est-ce pas ? Les techniciens sont très doués pour aller voir les entreprises et proposer une solution. Vous devez adopter, vous devez architecturer le système, vous devez passer au cloud, vous devez adopter des microservices, et l'entreprise n'a absolument aucune idée de tout cela, n'est-ce pas ? Même entre nous, c'est ainsi que nous ne sommes pas d'accord, même entre nous, parce que quelqu'un dira, vous devez adopter Docker, ou vous devez faire, je ne sais pas, une technologie X. Nous y allons avec des solutions. Même pour moi, Scrum, Agile en général, la programmation extrême, tout cela pour moi sont des moyens d'arriver à une fin, n'est-ce pas ? Alors, mais si vous voulez euh, aider les gens à adopter certaines pratiques, nous devons comprendre quelle est la valeur. Donc, je pense que c'est l'une des raisons pour lesquelles nous, euh, luttons. Et pour les personnes comme, par exemple, certains chefs de département ou ou, euh, propriétaires de produits, qui sont, euh, parfois, ils ont besoin de justifier pour obtenir l'approbation du budget. Ils peuvent même voir la valeur commerciale, mais pas avec suffisamment de profondeur pour justifier l'approbation du budget.
[00:08:01] Donc encore une fois, ce qui manque, c'est que nous devons trouver un moyen d'aligner cette entreprise et la technologie. Alors, je vais vous donner quelques exemples, mais avant même d'aborder l'approche stratégique, nous devons d'abord construire une base commune, dis-je. Euh, donc l'une des premières choses que nous devons comprendre est de savoir quels sont les principaux moteurs, n'est-ce pas ? Alors, euh, que nous avons, euh, pour la modernisation logicielle, n'est-ce pas ? Parce que ces choses, euh, un projet de modernisation logicielle, il créera, espérons-le, ce que j'appelle un impact durable. Ils devraient être des choses de pensée stratégique, euh, n'est-ce pas ? Alors, si vous voulez mener ce changement, comment le positionnez-vous ? Et il y a de nombreuses façons de positionner cela. Alors, comme vous travaillez là-dessus depuis des années maintenant, dans de nombreux projets et entreprises différents, les motivations ou les moteurs, ils rentrent en quelque sorte dans certaines de ces six catégories, il pourrait y avoir d'autres catégories, mais j'essaie de simplifier un peu. Euh, donc, ce sont les catégories courantes que nous avons comme moteurs. Je vais entrer un peu plus dans les détails, euh, dans l'un d'eux. Comme le changement durable, par exemple. Euh, un problème courant que nous voyons partout est beaucoup de gaspillage dans le processus, comme pour les gens comme, euh, c'est un appel de flux, donc je crois que beaucoup de gens sont dans le lean et le Kanban et des choses comme ça, donc la cartographie de la chaîne de valeur. Alors, il y a beaucoup de gaspillage dans le processus. Donc, l'un des moteurs de la modernisation logicielle est de supprimer, de créer ce changement durable. Afin de créer un changement durable, vous devez optimiser votre processus, euh, et ensuite vous devez réduire la dette technique, vous devez réduire le coût du changement, n'est-ce pas ? Donc, il faut réduire le délai de livraison. Et pour cela, il faut automatiser les processus répétables, il faut appliquer, euh, avoir une architecture plus modulaire. Donc, il est important de comprendre, lorsque vous essayez de mener un changement, quel est le moteur ? Quelle est la sorte de valeur commerciale ? Alors, le changement durable est un très, très commun.
[00:10:09] Euh, donc, l'innovation. Alors, beaucoup d'entreprises, elles ont perdu la capacité d'innover. Alors, ils se plaignent, par exemple, nous ne pouvons pas, euh, construire une fonctionnalité assez rapidement. Et il y a aussi, je, euh, nous réalisons qu'il existe différents types d'innovation. Alors, par exemple, les entreprises qui sont plus dans l'approche lean startup, disons, elles ont un produit ou une fonctionnalité très innovante, n'est-ce pas ? Alors, mais c'est un nouveau marché, ce n'est pas que c'est, ce n'est pas un domaine où il est très facile de faire de la recherche utilisateur. Il suffit de le lancer le plus vite possible, de recueillir les commentaires, puis d'inspecter et d'adapter, n'est-ce pas ? Alors, vous construisez quelque chose rapidement, vous le lancez, vous obtenez des données, vous comprenez les données, vous adaptez. Alors, pour ce faire, vous devez concevoir vos systèmes pour permettre cela. Vos systèmes doivent être conçus de manière à ce que les expériences soient faciles. Et vous n'expérimentez normalement pas sur l'ensemble de votre système, principalement dans les grandes organisations, vous pourriez isoler une zone où vous êtes, vous expérimentez, ce qui signifie que cette zone doit être conçue ou réarchitecturée ou même modernisée d'une manière pour permettre cette vitesse. C'est la même chose pour une approche plus, euh, expérimentations dans des produits plus stables, par exemple, nous travaillons avec beaucoup de grandes organisations où ils ont un ensemble de clients très bien défini, donc avant de publier une fonctionnalité, ils font des recherches auprès des utilisateurs. Ils parlent à leurs clients, ils déterminent quelles sont les fonctionnalités principales que leurs clients attendent. Et puis ils continuent à publier les unes après les autres. Mais pour avoir cette cadence et et continuer à innover leur produit, mais avec plus de certitude, vous devez aussi concevoir votre système ou moderniser votre système d'une manière qui soit possible, parce que contrairement à l'autre, euh, comme vous, cette approche de design thinking plus, euh, disons, et d'autres choses, votre système doit être flexible, car il doit continuer à changer, mais il doit être robuste, car chaque fois que vous lancez une fonctionnalité, il doit être stable, car il va directement aux clients, ce n'est pas, ce n'est pas juste une expérience. Alors,
[00:12:19] encore une fois, quand vous menez un changement, l'innovation est-elle l'un des moteurs ? Parce que vous devez, euh, euh, faire correspondre ce, euh, votre changement à ce moteur. Tirer parti de la technologie.
[00:12:33] Euh, par exemple, beaucoup d'entreprises ont de grands centres de données, elles ont, euh, ou elles ont beaucoup de départements qui travaillent, euh, d'une manière très, euh, pas très, comment dire, euh, durable ou efficace. Il existe donc de nombreuses technologies : passer au cloud, automatiser vos pipelines, orchestrer vos conteneurs, ou être capable de lancer de nouveaux environnements. Euh, donc, vous pouvez tirer parti des technologies. C'est donc aussi un type de modernisation où vous pouvez moderniser votre technologie afin de permettre certains, euh, euh, euh, facteurs commerciaux. Donc, l'alignement commercial.
[00:13:12] C'est également essentiel car les différents domaines de l'entreprise évoluent à des rythmes différents. Ainsi, votre système doit être modernisé de manière à ce que son architecture corresponde aux différents types de domaines ou de zones fonctionnelles que vous avez dans votre entreprise. En conception axée sur le domaine, nous allons parler de contextes bornés, donc ces contextes bornés doivent correspondre aux domaines fonctionnels de l'organisation. À mesure que l'organisation évolue, parfois l'architecture de votre système sera désalignée, perdra cette connexion. Donc une modernisation peut aussi vous permettre de créer cet alignement et ensuite de découpler ces initiatives au sein des domaines. Euh, les gens et la culture. Alors, c'est une chose dont peu de gens parlent, mais beaucoup d'entreprises ont du mal à recruter. Ils ont donc du mal à embaucher et du mal à maintenir, à retenir les talents.
[00:14:05] Pour une entreprise technologique, il est essentiel que vous embauchiez de bonnes personnes et que vous les reteniez. Mais vous ne pouvez pas faire cela en utilisant des technologies très anciennes, euh, propriétaires et des choses comme ça. Il faut donc que ce soit attrayant pour que les bonnes personnes viennent dans votre organisation et y restent. Il y a donc un investissement que vous devez continuer à maintenir, donc faire évoluer votre stock technologique et moderniser votre stock technologique et l'architecture des offres et tout le reste, a également un impact significatif sur les personnes que vous recrutez et fidélisez. Euh, et il y a aussi, comme des choses comme la gestion des risques.
[00:14:40] Donc, nous travaillons avec beaucoup d'entreprises réglementées, euh, dans des environnements réglementés, dans les produits pharmaceutiques, dans, euh, la banque d'investissement, et l'assurance, et des choses comme ça. Donc, il y a beaucoup de conformité, de sécurité, d'accidents opérationnels, donc l'observabilité des systèmes en production. Alors, euh, pas toujours, à mesure que les réglementations changent, vous devez moderniser vos systèmes afin de faciliter la conformité avec les réglementations ou les certifications et ainsi de suite. Alors, ce que je, alors cela fait partie de la fondation. Vous devez comprendre, avant d'engager un changement, quel impact le changement que vous voulez mener aura sur l'entreprise, où il s'inscrit ? Alors,
[00:15:26] mais ensuite il y a aussi les obstacles. L'autre aspect est : qu'est-ce qui bloquerait, même si vous avancez cet argument ou que nous allons améliorer certains domaines de l'entreprise, mais quels seraient les obstacles ? Manque de temps, manque d'argent, les deux plus courants, n'est-ce pas ? Ces choses sont relatives. N'est-ce pas ? Alors, le temps et l'argent sont, sont relatifs. Vous n'avez pas le temps comparé à quoi ? Parce que par exemple, ils pourraient dire qu'ils n'ont pas le temps, mais s'ils ont beaucoup d'inefficacités dans leur processus, vous pouvez argumenter en disant, regardez, nous disons que nous n'avons pas le temps, mais nous passons, genre, trois mois juste avec le cycle d'assurance qualité avec du QA manuel chaque fois que nous voulons sortir une version de notre système.
[00:16:12] Ou, ou nous avons tellement de bugs qui reviennent de l'assurance qualité, donc il y a beaucoup de retravail, ou il y a des tonnes de cycles d'approbation, ou nous devons changer cinq systèmes différents pour obtenir quelque chose. Donc, il y a beaucoup de temps qui est gaspillé, si nous pouvions réduire cela, nous aurions plus de temps pour faire quelque chose de plus important. L'argent, c'est exactement la même chose. Mais vous avez d'autres choses, vous avez un manque de compétences, vous avez, euh, la peur d'augmenter les risques. Vous avez par exemple certaines entreprises qui ont essayé de moderniser certaines choses et elles ont échoué, alors maintenant elles sont découragées, elles ne veulent plus le faire. Alors, vous devez comprendre, je ne vais pas tous les aborder, mais vous devez comprendre, euh, vos parties prenantes et quelles sont leurs principales préoccupations, donc lorsque vous présentez votre argument, vous devez aborder ces points, n'est-ce pas ?
[00:16:58] Et aussi,
[00:17:01] tout ce qui devient comme un nom, comme Agile et le craftmanship et Lean, les gens commencent à avoir des interprétations différentes. Donc, la modernisation, c'est la même chose. Euh, vous devez être capable d'expliquer, euh, ce que vous entendez par là aussi. Alors, par exemple, il y a pour moi des principes qui guideront, euh, tout effort de modernisation. Pour moi, vous devez avoir une grande vision, donc pour convaincre quelqu'un de faire quelque chose de significatif, c'est stratégique, pas seulement une petite amélioration ici et là, qui dans l'ensemble des choses, ne sera pas significative. Alors, vous devez vendre une vision, vous devez avoir une bonne vision pour dire, regardez, nous pouvons être bien meilleurs dans un, deux, trois ans, n'est-ce pas ? Donc, il faut avoir une vision, mais il faut travailler par petits incréments et chaque incrément doit avoir de la valeur, n'est-ce pas ? Une autre chose très importante. Une modernisation perturbera normalement les opérations courantes. N'est-ce pas ? Donc, vous allez réarchitecturer les systèmes, vous allez réorganiser les choses et changer la façon dont les données sont manipulées ou dont les systèmes sont déployés, et, et donc il y a une perturbation. Donc, dans votre plan, vous devez essayer de maximiser autant que possible, dire que vous pouvez complètement, euh, éviter de perturber les opérations normales, je ne peux pas dire ça, il y a toujours une certaine perturbation. Mais cela doit être minimal. Euh, si ce n'est pas cassé, ne touchez pas aux choses qui fonctionnent. Si ça fonctionne et que ce n'est pas sur le chemin critique, ça ne sera pas stratégique pour l'avenir, peu importe si vous aimez le code ou non, si vous aimez la technologie ou non, si ça ne change pas, pas stratégique, pas essentiel pour l'avenir, laissez-le, laissez-le tranquille. L'excellence dans les solutions pragmatiques est également très importante. Assez souvent, principalement les personnes techniques, comme moi et probablement certains d'entre vous, nous voulons, si nous avons l'opportunité, que tout soit excellent et parfait. Mais cela, euh, finit par, nous perdons le pragmatisme. Nous voulons juste que tout soit parfait parce que nous nous concentrons sur la technologie, nous nous concentrons sur la solution que nous voulons, mais nous perdons de vue ce qui est important pour l'entreprise. Alors, ce que je dis toujours, c'est que l'excellence devrait être bornée. Vous ne pouvez pas simplement avoir une excellence illimitée parce que, euh, vous perdez le pragmatisme, vous n'avez jamais de retour sur investissement. Il vous faut donc une solution pragmatique où l'excellence existe en son sein, n'est-ce pas ? Alors, et puis il y a la loi du rendement décroissant, vous devez apprendre à ce stade, à ce, euh, niveau, le niveau stratégique, nous ne pouvons pas aller trop loin. Il ne sert à rien de continuer à ajouter des tests, à ajouter des tests, à ajouter des tests et à essayer d'ajouter des tests unitaires pour des millions et des millions et des millions de lignes de code. À un certain point, vous dites, vous savez quoi, cette zone est plus importante que l'autre zone, concentrons-nous ici et faisons ce qui est suffisant, car c'est toute la loi de Pareto. Peut-être qu'avec un investissement de 20%, nous pouvons obtenir un rendement de 80%, mais pour obtenir les 20% restants, vous devez investir les 80% restants. Donc il faut faire attention à un moment donné, vous dites, c'est suffisant. Euh, donc, donc c'est pour moi la fondation, n'est-ce pas ? Alors, avant d'essayer de mener un quelconque changement,
[00:20:25] vous devez comprendre toutes ces choses.
[00:20:28] Et puis, avec cette fondation, nous pouvons maintenant dire : comment pouvons-nous commencer ? ne pas aller trop en profondeur. Cela ne sert à rien de continuer à ajouter des tests, à ajouter des tests, à ajouter des tests et à essayer d'ajouter des tests unitaires pour des millions et des millions et des millions de lignes de code. À un moment donné, vous dites, vous savez quoi, cette zone est plus importante que l'autre. Concentrons-nous ici et faisons ce qui est suffisant parce que c'est toute la loi de Pareto. Peut-être qu'avec un investissement de 20%, nous pouvons obtenir un rendement de 80%, mais pour obtenir les 20% de rendement restants, vous devez investir les 80% restants. Donc, nous devons être prudents et dire à un moment donné, c'est suffisant. Euh, donc, donc, c'est pour moi la fondation. N'est-ce pas? Donc, avant d'essayer d'apporter un changement, vous devez comprendre toutes ces choses. Et puis, avec cette fondation, nous pouvons maintenant dire, d'accord, comment pouvons-nous commencer? Il y a, je simplifie une une cinq approches. Normalement, cela peut être fait si vous êtes capable d'obtenir les bonnes personnes, et qui sont les bonnes personnes? Euh, vos sponsors, les représentants de l'entreprise, le représentant de la technologie, l'entreprise et la technologie peuvent également avoir des rôles différents. La technologie peut avoir des gens des opérations, de l'assurance qualité, des architectes, des chefs d'équipe, qui que ce soit. Pour l'entreprise, c'est la même chose, vous pouvez avoir des gens des ventes, du marketing, des responsables de comptes ou n'importe qui d'autre, n'est-ce pas? Donc, vous devez réunir ces personnes. Nous sommes normalement capables de faire les choses que je vais mentionner jusqu'à la fin de la présentation en quelques jours. N'est-ce pas? En une semaine, en deux semaines, parfois en trois jours, selon le temps dont nous disposons. Donc, ce n'est pas une chose énorme. Il y a beaucoup de choses que je vais couvrir, mais ce n'est pas aussi long en termes de temps tant que vous savez ce que vous faites. Alors, la première chose que vous essayez, que vous devez faire, c'est d'aligner l'entreprise. N'est-ce pas? Vous alignez l'entreprise, alignez la technologie, créez une vision, créez une stratégie pour commencer à aller vers cette vision, et puis vous dites, d'accord, mais comment allez-vous faire chacune de ces étapes? C'est l'implémentation. Voilà en bref. Comment faisons-nous l'entreprise, euh, euh, l'aligner. Donc, tout d'abord, nous devons comprendre ce que nous essayons d'atteindre. Comme je l'ai dit, il y avait les moteurs avant, et vous pouvez être un peu plus spécifique sur ce qu'il y a là, quelle est la valeur stratégique, si nous abordons les inefficacités? Faisons-nous de l'expérimentation? Donc, nous devons convenir en groupe des critères que nous aurons, des critères commerciaux, des objectifs commerciaux pour la modernisation. Une autre chose que nous devons faire. Nous devons nous concentrer. N'est-ce pas? Donc, ces organisations qui veulent investir dans la modernisation, elles sont elles ont un, elles n'ont pas un seul système, elles ont des tonnes de systèmes, elles ont des tonnes de départements. Et donc, vous ne pouvez pas simplement dire que nous allons tout moderniser parce que cela ne fonctionnera pas. Vous devez vous concentrer. Alors, quels sont les domaines clés sur lesquels nous devrions nous concentrer, qui sont au cœur de notre entreprise? C'est un exercice de très haut niveau que nous avons réalisé avec une entreprise de 5 000 personnes et leur haute direction. Nous avons pu, en quelques jours, cartographier 16 domaines fonctionnels de leur entreprise. Et parmi ces 16, nous en avons choisi trois qui étaient plus importantes, et chacune d'elles a été décomposée en beaucoup plus de domaines. Nous avions environ trois niveaux de décomposition des domaines. Et puis, au sein de ces domaines, nous finissons par nous concentrer sur certaines zones clés. Ainsi, vous pouvez vraiment concentrer votre approche de modernisation là où cela compte. Donc, cela suppose l'alignement. Maintenant que vous avez la concentration, maintenant que vous avez les domaines d'activité sur lesquels vous voulez vous concentrer. Et tout le reste? Si un jour vous y arrivez, tant mieux, mais vous vous concentrez sur ce qui est important. Il y a des zones que vous ne toucherez jamais, n'est-ce pas? Alors,
[00:23:28] quelles sont les principales fonctionnalités? Quels sont les points douloureux? Les améliorations souhaitées? Donc, c'est fascinant d'animer ces ateliers avec ces différentes personnes, avec la technologie, l'entreprise, les sponsors et tout ça. Et vous dites, d'accord, donc dans ce domaine, dans ce produit, quelles sont les choses clés que cette chose fait? N'est-ce pas? Oh, cette chose fait. Chacun d'eux aura une vision différente en termes de ce que sont les principales fonctionnalités, les principales euh oui, euh activités que ce domaine réalise. Et les points douloureux, c'est pareil. Chacun d'eux, parce qu'ils regardent les systèmes et le modèle d'affaires sous différentes perspectives, a également une vision différente des points douloureux. Et parce qu'ils voient différentes fonctionnalités comme principales fonctionnalités et différents points douloureux, ils ont également différentes améliorations souhaitées. Ainsi, en les réunissant et en animant ces ateliers, nous les alignons sur ce qui est vraiment important, ce qui est vraiment un point douloureux, et ce sur quoi nous devrions vraiment agir. Parce que certains points douloureux, c'est une douleur, vous devez apprendre à vivre avec ça. N'est-ce pas? Donc, parce que vous avez des douleurs beaucoup plus importantes sur lesquelles vous concentrer. N'est-ce pas? Donc, cela fait partie de l'alignement. Et l'un des exercices les plus importants pour moi est ce que nous appelons une carte de flux de valeur. N'est-ce pas? Euh, encore une fois,
[00:24:50] pas tout le monde, et nous avons fait beaucoup de ces ateliers, comme, une carte de flux de valeur, pour ceux qui ne le savent pas, est simplement la cartographie d'une idée, de l'idée à la production logicielle. Quelles sont toutes les étapes? Que se passe-t-il? De quelqu'un qui a une idée jusqu'à ce qu'elle soit déployée en production.
[00:25:09] C'est un résultat d'un atelier que nous avons mené, il y avait sept personnes je crois du client, de différents domaines, comme euh, mais toutes regardant les mêmes systèmes.
[00:25:18] Nous avons travaillé pendant une heure et demie, deux heures, et à la fin de cela, parce que chacun d'eux, nous avons des analystes d'affaires ou des chefs de produit, ils avaient leur propre processus de priorisation des idées et des backlogs et d'assignation aux équipes et tout ça, ils avaient leur propre processus. approbations budgétaires. Je ne m'attends pas d'ailleurs à ce que vous lisiez tous ces post-its, n'est-ce pas? Alors, euh, et puis il y avait beaucoup de choses dès qu'il s'agit de développement, il y a différentes personnes, il y a différents départements et il y a une QA séparée et et. Alors, quand nous avons terminé, chaque personne contribuait à différentes parties, quand nous avons terminé, toutes ont regardé et c'était comme, est-ce comme ça que nous travaillons? Oui. Mais personne n'avait la visibilité complète. Ainsi, cet exercice permet de réunir tout le monde et d'être très précis sur l'endroit où se trouvent les inefficacités.
[00:26:14] Parce que alors vous pouvez dire, d'accord, nous devons automatiser ce morceau. Nous devons ré-architecturer le système ou, vous savez quoi, vous avez juste besoin de corriger votre processus. Vous n'avez pas besoin de changer quoi que ce soit dans la technologie, vous avez juste besoin de trouver une meilleure façon de communiquer et de supprimer une partie de la bureaucratie dont Dieu seul sait pourquoi elle est là. Euh, une autre, il y a aussi quelques choses manquantes parce que euh, nous devons aussi regarder vers l'avenir. Donc, parfois, vous aurez une gestion de portefeuille, donc ils savent ce qu'ils veulent atteindre chaque trimestre, toutes les différentes initiatives ou initiatives stratégiques que vous aurez dans votre portefeuille. Et si vous regardez quelque chose d'un peu plus euh ciblé, euh, vous pourriez ils pourraient avoir des jalons euh et/ou des arriérés et des choses comme ça. Donc, nous devons savoir ce qui vient ensuite. Parce que comme je l'ai dit, euh, nous ne devrions pas moderniser des choses qui ne seront pas utiles à l'avenir. Il ne sert à rien de toucher une zone. S'il n'y a pas de nouvelle fonctionnalité à venir. Alors, laissez-le tranquille. Donc, toute la modernisation devrait soutenir la stratégie de l'entreprise. Ainsi, tout ce que nous faisons maintenant devrait permettre la mise en œuvre de la vision stratégique de l'entreprise. Et puis il y a aussi des contraintes.
[00:27:36] Nous n'avons pas regardé cela, mais nous devons le regarder, euh, par exemple, euh, les SLAs, les régulations, les certifications, les délais externes et internes. Donc, toutes ces choses, elles impactent la modernisation. Donc, nous devons comprendre quelles sont les contraintes sur lesquelles nous ne pouvons rien faire, s'il y a une certification, une réglementation, une échéance externe. Peu importe à quel point nous les détestons. Nous devons l'accepter. N'est-ce pas? C'est comme ça. Quoi que nous fassions, créons une stratégie qui en tiendra compte. Et nous ferons de notre mieux dans ces contraintes. D'autres contraintes que nous pourrions décider de supprimer. Et puis nous devons avoir une conversation. Mais nous devons garder cela à l'esprit. Les OKRs, les KPIs, les métriques sont également liés au portefeuille. Alors, qu'est-ce que l'entreprise veut accomplir et tout le reste, car vous devez aligner vos stratégies là-dessus. N'est-ce pas? Alors, et et en gros, quelques métriques sont toujours importantes, euh, encore une fois, différents styles de modernisation auront différentes métriques. Mais il y a quatre métriques clés pour ceux d'entre vous qui ont lu ou n'ont pas lu ce livre "Accelerate", je le recommande vivement, c'est un livre phénoménal et il explique la recherche qui le sous-tend, tout est basé sur des données et d'autres choses. Mais ils parlent de quatre métriques clés. C'est la fréquence à laquelle vous déployez des logiciels. Euh, le délai, c'est-à-dire le temps qu'il faut à un logiciel pour passer en production. Euh, si quelque chose ne va pas, à quelle vitesse pouvez-vous le restaurer et la quantité de déchets ou, dans ce cas, de défaillances que vous avez dans le processus. N'est-ce pas? Pendant que le travail passe par le pipeline, combien de défaillances avons-nous? Nous devrions réduire cela. Donc, ce sont des indicateurs clés que nous pouvons utiliser pour surveiller votre approche de modernisation également. Donc, avec ça, à la fin de ceux-là, et encore une fois, vous pouvez parcourir ces choses, si les gens sont disponibles, vous pouvez le faire en une journée, d'ailleurs. Je ne parle pas de mois, ce n'est pas, en un jour, vous pouvez probablement obtenir un certain alignement.
[00:29:38] Une fois que nous avons cela, nous devons maintenant passer à l'aspect technique.
[00:29:43] Le côté technique. Nous commençons à regarder, d'accord, dans les domaines sur lesquels nous nous concentrons, quelle est l'architecture actuelle? Qu'avons-nous? Donc, et ensuite, en regardant l'architecture globale, nous devons décider où nous allons approfondir un peu plus. Ensuite, vous devez examiner certains des composants, certains des services, quel est le design global? Et aussi ce que nous appelons une une cartographie fonctionnelle. Alors, par exemple, si nous avons quelques fonctionnalités, et par fonctionnalités, je ne parle pas seulement des utilisateurs cliquant sur l'écran. Beaucoup d'organisations n'ont même pas d'écrans, ce qu'elles ont, ce sont des messages provenant de différents systèmes, provenant de l'extérieur de l'entreprise. Donc, des messages entrants et naviguant à travers un tas de systèmes, ou ils ont différents mécanismes de livraison et interfaces utilisateur et tout ça. Alors, mais nous devons prendre ces fonctionnalités, quelles qu'elles soient.
[00:30:32] et cartographier dès que nos systèmes sont déclenchés, ce qui se passe, quels autres systèmes sont touchés, quelles zones des systèmes sont touchées pour chacun de ces systèmes, afin que vous puissiez faire cette cartographie également. Donc, cela nous permet de créer une compréhension. Et cet exercice n'est pas seulement fait avec des techniciens, cet exercice est fait avec les gens d'affaires dans la même pièce aussi parce qu'ils ne comprennent pas eux-mêmes comment nos systèmes sont architecturés. Et et parce que ces ateliers sont à un niveau élevé, c'est facile pour eux de euh de comprendre. Nous n'allons pas ouvrir des classes Java ou des closures ou un framework JavaScript fou. Ce n'est pas le but. C'est un niveau de conception, de conception architecturale. C'est là que la stratégie se situe à ce niveau, pas sur les problèmes de codage de bas niveau. Donc, cela permet aux gens d'affaires de comprendre le type de complexité que nous avons, et comment le système est cartographié. Donc, ensuite, nous faisons une chose très similaire, quels sont les points douloureux, quelles sont vos améliorations souhaitées, les contraintes techniques? Et nous parlons aussi des risques de modernisation. Parce que dans certains environnements, peut-être dans des environnements réglementés, des environnements qui ont trop d'utilisateurs concurrents achetant des choses ou se faisant prescrire des médicaments et des choses comme ça. Vous ne pouvez pas simplement commencer à pirater le code ou pirater l'architecture et changer les choses, changer les API et changer les bases de données. Vous devez comprendre quels sont les risques. Donc, il y a aussi toute une session sur les risques. Donc, ensuite, vous regardez les contraintes, par exemple.
[00:32:11] Nous travaillons avec un client, euh, un fournisseur de soins de santé, leurs systèmes ont, ils ont 11 000, plus de 11 000 installations en production, 4 000 d'entre elles sont sur site, dans des environnements auxquels nous n'avons même pas accès. N'est-ce pas? C'est contrôlé par d'autres personnes, par leurs clients.
[00:32:35] Donc, parce qu'ils ont, ils doivent être multi-locataires, qu'est-ce que cela signifie? Euh, eh bien, plusieurs clients peuvent accéder à la même instance de production, ils doivent avoir une instance par client. Parce que si un système tombe en panne, un hôpital pourrait tomber en panne, mais pas tout le système de santé américain ne tombe en panne. Donc, parce qu'ils ont, ils doivent être multi-instances et non multi-locataires. Cela a créé une très grande contrainte technique dans l'architecture que nous avions. Nous ne pouvons pas faire de microservices, par exemple. Parce que sinon, imaginez 11 000 installations de production, et nous mettons, je ne sais pas, 50 microservices dans chacune de ces installations, la complexité serait gigantesque.
[00:33:18] En plus des 4 000 sur site. Alors, nous avons dû opter pour euh ce que nous appelons un monolithe modulaire. Mais ce n'est qu'un exemple de contraintes techniques. Mais vous avez des SLA, vous avez des réglementations, vous avez un volume de données, vous avez beaucoup d'autres choses. N'est-ce pas? Donc, encore une fois, nous devons tous comprendre, pas seulement les techniciens, mais aussi les gens d'affaires doivent comprendre.
[00:33:46] Une fois que nous avons cet alignement entre l'entreprise et la technologie, c'est seulement alors que nous commençons à créer une vision.
[00:33:52] Vous dites, d'accord, donc étant donné ce que nous savons maintenant de là où nous en sommes dans l'entreprise et la technologie, quels sont les points douloureux, qu'est-ce que vous voulez améliorer et ainsi de suite? Quelle est notre vision? Et ici, j'appelle la baguette magique. N'est-ce pas? Donc, si vous avez une baguette magique et que vous dites, et que vous voyez ce bel avenir devant vous avec tous les systèmes utilisant la technologie que vous voulez. diviser la manière que vous voulez, et le processus étant ce que vous voulez, toute l'automatisation. Alors, peignons ce tableau. Essayons de comprendre ce que nous aimerions avoir. Bien sûr, nous n'aurons jamais cela. La plupart du temps, nous allons peindre une vision que vous n'atteindrez jamais. Mais cela doit servir de guide. Donc, je dis toujours que la vision technique est une direction.
[00:34:39] Ce n'est pas un plan que vous suivez, euh, cela doit donner des orientations. C'est bon, c'est ce que nous aimerions avoir. Mais nous ne pouvons pas arrêter le monde entier ou dépenser de l'argent indéfiniment et du temps indéfiniment. euh, la poursuite d'une vision. Encore une fois, nous avons besoin de solutions pragmatiques avec excellence, n'est-ce pas? Alors, donc vous créez la vision pour servir de direction et ensuite vous commencez à avancer vers cela. N'est-ce pas? Donc ce ne sera pas un chemin droit. Donc, à chaque incrément, vous allez aller un peu sur le côté, peut-être un peu sur le côté. Et nous continuons à recalibrer, nous continuons à recréer la vision, à mesure que nous travaillons vers la vision, nous est-ce toujours la même vision ou a-t-elle changé, se déplace-t-elle sur le côté, et ensuite vous continuez à ajuster. N'est-ce pas?
[00:35:28] Donc, et nous parlerons de la stratégie de test. La technologie, le déploiement, l'environnement de production, la modernisation, l'appropriation par l'équipe. L'appropriation par l'équipe est très, très, très importante. Je parlerai probablement un peu plus tard si je ne le fais pas, euh, envoyez-moi une question. Nous pouvons aussi parler davantage de l'appropriation par l'équipe. Mais vous pouvez créer, vous devez créer cette vision. Et et en cela, vous devez prendre en compte toutes les contraintes, commerciales et techniques, les priorités, les OKR, euh, et ainsi de suite. Alors, Cela semble évident. Mais je dois encore voir si les gens qui essaient de mener un changement technique ont cet alignement et ce plan. C'est pourquoi nous ne sommes normalement pas capables de le faire. Donc, une fois que nous avons la vision, le côté vision, c'est là que les gens s'enthousiasment. N'est-ce pas? Alors, donc vous, en tant qu'agent de changement, vous, en tant que personne qui veut mener le changement, vous devez enthousiasmer les gens. Vous les emmenez avec vous. Lorsque vous les amenez avec vous, ils sont maintenant au même endroit, ils verbalisent tous leurs douleurs, leurs désirs et tout ça, et maintenant les choses se mettent en place et vous créez ensemble cette vision. Et puis à ce moment-là, c'est votre travail de vous assurer que tout le monde est excité et maintenant vous dites, vous savez quoi, cela pourrait être réellement possible. Mais comme, eh bien, jusqu'à présent, nous n'avons parlé que de. Des désirs et des points de douleur, nous créons cette belle vision. Mais je suis toujours sceptique, genre, pouvons-nous même y arriver? Je ne vois pas cela être réellement mis en œuvre.
[00:37:04] Et c'est là que
[00:37:07] les personnes très techniques peuvent vraiment briller. Parce que maintenant c'est notre moment de dire, d'accord, nous avons créé cet enthousiasme, maintenant voyons comment nous pouvons le faire d'une manière durable. Et je ne vais pas prescrire car il m'est impossible de prescrire quelle stratégie adopter sans connaître le contexte, donc je vais vous donner des idées.
[00:37:27] Cette diapositive montre l'approche la plus simpliste de la modernisation des logiciels. Cela vient de Gartner. Ce que je pense personnellement qu'il y a de grandes choses là-dedans et certaines choses que Gartner aime montrer dans ces rapports, elles sont de nature très simpliste. Donc, Gartner dit, oh, il existe différents types de modernisation, il y a la réécriture, la replatformisation, la réarchitecture, le refactoring, euh, donc, c'est de ça qu'ils parlent. Il y en a une ou deux qui étaient un peu trop bizarres pour moi, mais bon. C'est très simpliste pour moi. Parce que la plupart des projets de modernisation dans lesquels nous avons été impliqués étaient un hybride de tout cela. Il y a un peu de tout là-dedans. Alors, oublions cela car c'est bien trop simpliste pour parler de la modernisation des logiciels.
[00:38:13] Nous le divisons de manières légèrement différentes. Parce que comme je l'ai dit, vous ne pouvez pas tout changer. Alors, une stratégie, ce sont des stratégies de modernisation qui ont un certain impact commercial. Une façon de le faire est de dire, quel domaine fonctionnel de votre entreprise est plus critique? Soit cela vous cause beaucoup de douleur et vous devez arrêter l'hémorragie, vous devez vraiment réparer cela afin de pouvoir vous concentrer sur d'autres choses plus importantes. Ou est très critique pour l'avenir et n'est pas prêt à permettre ce que vous voulez faire, donc c'est un focus sur un domaine fonctionnel. N'est-ce pas?
[00:38:53] Une autre façon de le faire, vous savez où vous voulez toucher. Mais vous ne pouvez pas arrêter les affaires comme d'habitude.
[00:39:00] Et vous n'avez pas assez de personnel, de temps, de ressources ou quoi que ce soit pour le faire. Alors, que pouvez-vous faire? C'est une approche que nous avons utilisée plusieurs fois, vous pouvez prendre, je vais donner un exemple concret, celui des nouvelles fonctionnalités. Nous travaillions avec ce client et ils avaient un gros monolithe dans leur boutique en ligne où le paiement faisait partie du monolithe. Ainsi, le monolithe contenait des commandes, des produits, un catalogue, tous les domaines courants que vous pouvez imaginer, y compris le paiement. Alors, le côté paiement était compliqué car ils stockaient des cartes de crédit. Ce qui signifie que l'ensemble du système devait être conforme à la norme PCI. Donc chaque changement que nous voulions faire, même si vous changiez le catalogue, ils devaient maintenir la conformité PCI, ce qui n'était même pas un changement, mais cela devait passer par un audit. par exemple, les nouvelles fonctionnalités. Nous travaillions avec ce client et ils avaient un grand monolithe dans leur boutique en ligne. où le paiement faisait partie du monolithe. Donc le monolithe avait des commandes, des produits, un catalogue, tous les domaines communs que vous pouvez imaginer, y compris les paiements. Donc le côté paiement était compliqué car il stockait les cartes de crédit. Ce qui signifie que l'ensemble du système devait être conforme à la norme PCI. Donc, chaque changement que nous voulions faire, même si vous changiez le catalogue, ils devaient potentiellement maintenir la conformité PCI, ce qui n'était même pas un changement, mais devait passer par un audit. Et donc ce que nous voulions faire, nous voulions découpler le cycle de déploiement. Si nous pouvions retirer les paiements du reste du monolithe, nous pourrions permettre au reste de la base de code d'être déployé beaucoup plus rapidement et avec moins de bureaucratie. Et garder la plus grande bureaucratie ou le plus grand audit et autres là où c'est vraiment important, c'est-à-dire les paiements. Mais ils ne pouvaient pas tout arrêter pour faire ça, alors ce que nous avons fait, nous avons utilisé de nouvelles fonctionnalités. Ils voulaient ajouter de nouvelles méthodes de paiement. Ils avaient déjà quelques cartes de crédit, mais ils voulaient ajouter PayPal, Apple Pay et des choses comme ça. Donc ce que nous avons fait, nous avons pris les nouveaux paiements, en fait, dans ce cas, ils intégraient une passerelle de paiement tierce. Alors j'ai dit, d'accord, prenons l'intégration de la passerelle de paiement. Nous avons donc créé la vision et nous avons utilisé la nouvelle fonctionnalité du système, mais nous avons conçu cette nouvelle fonctionnalité avec une nouvelle architecture, avec une nouvelle vision. Et cela nous a permis de continuer à progresser vers l'entreprise et de commencer à introduire la nouvelle vision pour ce domaine. Et puis, progressivement, nous commençons à déplacer les méthodes de paiement existantes vers le nouveau système. C'est donc une façon très intéressante de gérer les flux d'affaires. Les flux d'affaires, par exemple, d'une autre entreprise. Ils avaient 300 employés qui, pour effectuer leurs opérations, étaient très inefficaces car ils devaient utiliser trois systèmes différents. Pour effectuer leurs flux d'affaires normaux, et très souvent, ils devaient copier des données d'un système à l'autre pour continuer le flux parce qu'ils acquiéraient différentes entreprises et ainsi de suite. Alors, ce que nous avons fait, c'est que nous avons pris les flux d'affaires et nous avons basé notre approche de modernisation sur le flux dont les utilisateurs avaient besoin. Et puis nous avons choisi ce que nous devions découpler, ce que nous devions réécrire, ce que nous devions créer un autre service et ainsi de suite, mais cela était adapté à ce flux d'affaires. Je ne vais pas les aborder tous, mais je vous donne juste des idées.
[00:41:57] Lorsque vous modernisez, la manière dont vous créez votre stratégie peut varier considérablement, mais vous l'adaptez toujours à l'entreprise. Et puis il y a une approche plus technique. Ensuite, il y a les architectures réelles que vous allez utiliser ou des choses comme ça. Ainsi, par exemple, j'ai mentionné le monolithe modulaire un peu plus tôt. Donc, étant donné les contraintes que nous avons et les besoins de l'entreprise, du point de vue architectural, notre plus grande approche de modernisation aujourd'hui, le système est un monolithe modulaire et il restera un monolithe modulaire, n'est-ce pas ? Donc, parce que ça a du sens. Mais vous pouvez passer des microservices ou utiliser une figure strangulatrice ou vous pouvez avoir une modernisation basée sur la séparation front-end et back-end. Ou par exemple, vous avez un tas de microservices, mais vous avez différents mécanismes de livraison, vous pourriez avoir du mobile, vous pourriez avoir le web, vous pourriez avoir une intégration avec d'autres systèmes qui utilisent vos systèmes, donc des consommateurs de vos APIs. Euh, donc, qui gère le flux, le flux d'affaires, le parcours utilisateur ?
[00:42:58] Alors vous pouvez aussi organiser vos systèmes d'une certaine manière et pousser le flux vers les mécanismes de livraison, parce qu'alors le flux mobile peut être différent du flux web qui peut être différent d'un autre système interfacé avec les API. Donc, mais c'est une décision architecturale, donc la ségrégation des données, la propriété des données.
[00:43:18] Qui possède donc les données, quelles zones du système posséderont les données, quelles données le système possède et qu'entends-je par posséder ?
[00:43:26] Des données qu'ils ne peuvent pas modifier, ils peuvent insérer, ils peuvent supprimer, ils peuvent mettre à jour. Alors qui possède les produits, qui possède les commandes, qui possède je ne sais pas le catalogue, et qui a besoin de ces données, qui consomme ces données ? Donc cette organisation est extrêmement importante dans la façon dont vous architecturez votre système. Il existe donc des techniques et des architectures pour cela également. Et puis il y a la modularisation, tous les types d'efforts de modernisation logicielle que nous avons eus avaient un certain degré de modularisation. Et par modularisation, je ne dis pas que les modules sont un terme conceptuel, n'est-ce pas ? Mais finalement, vous devrez modulariser des zones séparées. Et c'est une chose très difficile à faire dans les systèmes plus grands. Il y a beaucoup de variables différentes et selon la façon dont vous regardez votre système ou la perspective que vous adoptez, vous pourriez arriver à un type de module différent ou aux limites entre les modules. Il existe donc de nombreuses techniques différentes que vous pouvez utiliser. Les données, la cartographie fonctionnelle, les zones, les zones fonctionnelles de l'entreprise. Il existe de nombreuses perspectives différentes que nous devons analyser afin de décider où se trouve le contexte lié si vous voulez être plus orienté vers la conception pilotée par le domaine, terme technique ou les zones fonctionnelles afin d'obtenir cette division. Euh, mais il y a beaucoup d'avantages et euh donc la modularisation.
[00:44:57] Je sais que ça semble évident, mais pour les techniciens, bien sûr, il faut modulariser. Bien sûr, vous devez avoir des choses faiblement couplées, très cohésives et bien sûr, nous le faisons, mais pourquoi ? N'est-ce pas ? Alors comment en parler à quelqu'un d'autre qui n'est pas développeur, n'est-ce pas ? Ou pas architecte. Il y a donc une réduction de la charge cognitive. Chaque fois que vous allez dans un endroit, une zone du système, vous pouvez penser à cette zone sans avoir à avoir tout le système en tête. Et ce n'est pas seulement du côté technique, mais aussi du côté commercial. Si vous pouvez faire correspondre les zones fonctionnelles au contexte lié, vous avez cette réduction de la charge cognitive lorsque vous parlez de ces zones. Et bien sûr, si vous avez cela, vous pouvez également avoir des changements localisés et plus sûrs. C'est un autre moteur, donc quand vous allez voir quelqu'un, vous voulez impulser ce changement. Vous n'allez pas dire : « Je dois modulariser mon système. Pourquoi ? Parce que ça a du sens pour moi en tant que développeur. Non ? Parce que c'est plus facile. Non, parce que vous pouvez localiser et rendre le changement plus sûr. D'accord ? Donc nous pouvons permettre la parallélisation du travail.
[00:46:11] Donc, si le système est modulaire, je peux avoir plusieurs changements en même temps sans qu'ils ne s'affectent mutuellement. Tant que la façon dont ces modules interagissent entre eux reste la même. Ou leurs interfaces. N'est-ce pas ? Il est donc plus facile d'atteindre la livraison continue. Parce que c'est une autre idée fausse, la livraison continue ne signifie pas que vous devez livrer l'intégralité de votre système chaque jour ou tout le temps. Vous pouvez livrer différentes parties de vos systèmes en continu. Donc un jour vous lancez une fonctionnalité pour les paiements, un autre jour vous lancez du côté client, un autre. Donc vous libérez constamment des choses et elles proviennent de différentes zones. C'est ce qui peut vous donner une livraison continue. Donc, comme je le dis, il existe de nombreuses façons d'exprimer les choses que vous savez être fausses dans le système, mais maintenant plus du point de vue commercial, disons, ou.
[00:47:03] Et il existe différents types de modules. N'est-ce pas ? Les modules peuvent être de très bas niveau, des paquets et des espaces de noms aux composants, aux bibliothèques, aux services ou groupes de services. Donc notre domaine des paiements, comme je le disais précédemment, est un module du système au niveau architectural. Et ce module du système est composé de quelques services. Chacun de ces services a ses propres modules à l'intérieur. Et ainsi de suite. Donc cette modularisation existe à plusieurs niveaux. Similaire à l'architecture et à la conception logicielle. Votre architecture est très, du tout début jusqu'au sommet, dans différentes zones, et ensuite vous allez de plus en plus loin jusqu'à ce que vous arriviez aux classes et aux méthodes ou aux fonctions si vous préférez. N'est-ce pas ? Tout cela doit donc faire au moins partie de votre stratégie technique. Et puis finalement vous avez. D'accord, donc maintenant nous comprenons la vision, les points faibles, tout l'alignement et tout le reste. Et nous savons que nous avons une stratégie, nous avons une vision et nous avons un peu plus de concret sur ce qui doit se passer. Alors comment faire ? Où allons-nous, comment utilisons-nous nos gens, n'est-ce pas ? Alors comment s'y prend-on ? Il y a beaucoup de façons différentes.
[00:48:23] Ils ont tous des avantages et des inconvénients, comme tout ce que nous faisons, n'est-ce pas ? Il y a toujours des avantages et des inconvénients et ensuite vous devez comprendre votre contexte et ce qui fonctionnerait le mieux. Alors, par exemple, une façon de faire, c'est d'avoir une équipe dédiée juste pour faire cette tâche de modernisation.
[00:48:41] Ou du moins une partie, vous pourriez avoir plus d'une équipe pour faire différentes parties de l'exercice de modernisation, de la stratégie de modernisation.
[00:48:52] Quel est l'avantage d'avoir une équipe dédiée juste pour ça ? Vous pouvez le faire plus rapidement. Parce que vous pouvez assembler une équipe qui a les compétences dont vous avez besoin. Parce que certaines modernisations pourraient être un passage au cloud, une mise à niveau des technologies, ou encore le fait de décomposer un ancien monolithe, donc vous avez besoin de personnes ayant des connaissances à ce sujet. De manière modulaire et ne connaissant pas nécessairement la dernière technologie, mais plutôt une connaissance du domaine, une connaissance du système. Donc, vous pouvez assembler l'équipe en fonction de ce que vous essayez de faire et cette équipe ira de l'avant. Vous pourriez donc y parvenir plus rapidement.
[00:49:30] Euh, il y a donc un avantage à cela. L'inconvénient est que cette connaissance est un peu concentrée. Donc, après que l'équipe ait pris de l'avance, vous devez trouver un moyen de diffuser cette connaissance auprès des autres équipes également. Et cette équipe devra également interagir avec de nombreuses équipes potentielles. Il y a des équipes spécialisées, vous pouvez juste amener quelques personnes et dire, ok, ce sont des spécialistes du cloud, ce sont des spécialistes AWS, ou je ne sais pas, ils comprennent tout de ce domaine, ils ont construit cette chose il y a 15 ans. N'est-ce pas ? Ils ont donc construit une équipe très spécialisée, ce n'est pas une équipe interfonctionnelle et ils prendront un domaine très spécialisé.
[00:50:09] D'autres combinent, nous priorisons les backlogs, ils ont un backlog qui contient les affaires courantes, les vraies fonctionnalités et les améliorations techniques. Avantages, oui. Vous pouvez faire les deux, vous n'arrêtez pas toute l'entreprise, vous partagez la connaissance. La même équipe qui développe les nouvelles fonctionnalités est également celle qui corrige les problèmes. Mais ce sera beaucoup plus lent. Et le plus souvent, les nouvelles fonctionnalités auront toujours la priorité. N'est-ce pas ? Alors,
[00:50:36] vous pouvez intégrer vos spécialistes, vous pouvez avoir des améliorations de 20%. Il existe donc de nombreuses configurations différentes, je ne vais pas détailler chacune d'elles. Si vous voulez en savoir plus, posez la question et j'entrerai plus dans les détails. Mais comme je l'ai dit, il existe de nombreuses façons d'organiser vos équipes. Et il y a aussi un excellent livre, je crois que l'un des auteurs a donné une conférence ici il y a quelques jours. C'est le gars qui a écrit la topologie d'équipe. Euh, donc ce livre est vraiment, vraiment bon. Je crois qu'un des auteurs a parlé ici. Euh, jetez un œil à ce livre car il donne de très bonnes informations sur la manière d'aligner ces équipes.
[00:51:13] Chaque modernisation doit être gérée comme un projet agile. Il doit avoir une approche incrémentale. Il doit avoir une feuille de route et des jalons. Euh, donc faites des démos régulièrement et montrez les progrès. Vous devez trouver un moyen de montrer des progrès. Et nous faisons ça depuis très longtemps maintenant. Au début, c'était très difficile de savoir comment je vais parler d'une pièce de refactoring que je fais ou d'une API que je change ou je ne sais pas, d'un cache que je mets quelque part. Comment j'explique ça à l'entreprise ? Eh bien, il y a beaucoup de façons différentes, vous devez juste trouver un moyen. Je peux vous donner des exemples, mais vous pouvez parler de performance, si vous améliorez, vous faites des démos. Voyez, ceci est sans le cache, c'est le temps que ça prend, maintenant nous avons le cache, ça va beaucoup plus vite. Donc vous pouvez montrer des métriques, Sonar, dans la scène de code et des choses comme ça. Il existe donc de nombreuses façons différentes, mais vous devez montrer la valeur commerciale.
[00:52:14] Voilà donc un résumé. Donc ce sont les quelques domaines. Donc, comme je l'ai dit, si vous voulez mener le changement technique, vous ne pouvez pas simplement y aller et dire :
[00:52:26] nous devons faire des microservices. Et j'ai besoin d'un an pour faire ça avec une équipe de 10 et ça va coûter un million de livres. Oubliez ça, vous ne convaincrez personne. Et vous ne pouvez pas juste être contrarié, oh, je ne sais pas pourquoi ils ne m'écoutent pas. Ils ne comprennent pas, ce sont tous des gens stupides.
[00:52:45] Ils ne peuvent pas voir ce que je dis. Parce que c'est la solution que vous n'alignez pas, que vous ne mettez pas en correspondance avec la valeur. Et il y a différentes façons de faire cela. Je ne vais pas couvrir cela en détail. Mais les grandes organisations pourraient vouloir déclencher de multiples initiatives, et nous gérons certaines de ces choses chez certains clients. Euh, vous pouvez faire évoluer ça. Mais il faut aussi faire attention. Donc d'une certaine manière, nous créons, nous parlons de ce programme d'amélioration continue, donc en gros vous pouvez avoir plusieurs sources d'initiatives. Donc ce sont différentes zones fonctionnelles de l'entreprise ou ça pourrait être différents groupes comme les opérations QA ou un groupe de travail spécifique. Comme une analyse des causes profondes et un CAPA, c'est-à-dire une action corrective, une action préventive, certaines entreprises créent ces domaines pour agir sur certains problèmes immédiats.
[00:53:40] euh des problèmes qu'ils rencontrent. Euh donc ce sont tous des types différents de sources différentes d'initiatives, d'initiatives d'amélioration. Et ils peuvent présenter un cas à ce que nous appelons un comité de pilotage. Ce comité de pilotage comprendra la valeur commerciale de la résolution de ces problèmes, il créera un backlog de très haut niveau qui ressemblera davantage à un portefeuille d'initiatives, et ensuite il pourra décider quel type d'équipes travaillera sur ces choses.
[00:54:07] Et quelle est la quantité de travail en cours, n'est-ce pas ? Combien d'initiatives d'amélioration y aura-t-il à un moment donné ? N'oubliez pas que ces initiatives ont tendance à être longues. Elles ont tendance à être mesurées en mois, euh sinon en un an, euh donc elles sont plus chères, elles sont plus stratégiques.
[00:54:28] Vous ne voulez donc pas trop d'entre elles, car vous risquez de déstabiliser tout le système. Il faut donc être très prudent. C'est pourquoi le comité de pilotage est important, car il n'est pas uniquement composé de sponsors qui peuvent le financer, mais aussi de tous les architectes techniques si vous en avez, ou de toute personne technique. Le CTO, le responsable de l'ingénierie, n'importe qui. Parce qu'ils doivent comprendre les risques techniques liés à l'exécution de certaines choses en parallèle. Et puis les équipes, elles peuvent décider, elles peuvent assembler une toute nouvelle équipe juste pour une seule initiative, et une fois cette initiative terminée, l'équipe retourne à ce qu'elle faisait ensuite. Ou ils peuvent avoir quelques équipes dédiées au PIC, n'est-ce pas, le programme d'amélioration continue, qui prennent une initiative après l'autre, en supposant qu'ils aient les compétences pour le faire. Ou ils peuvent faire venir une équipe de notre département, le département se joint, réalise cette initiative et repart. N'est-ce pas ? Vous pouvez donc avoir de multiples combinaisons. Donc je ne vais pas entrer dans les détails, il existe différents types d'initiatives, tactiques, stratégiques et Mais c'est une façon d'essayer d'étendre les programmes de modernisation.
[00:55:36] Et finalement, ce que vous voulez atteindre, c'est cet alignement.
[00:55:42] Vous voulez aligner le produit et la conception logicielle, par produit, on entend tout système stratégique. Ce n'est pas nécessairement un produit qui va à un client externe, je traiterai un système interne stratégique comme un produit dans ce cas. Mais ce que vous voulez, c'est aligner. Parce que ces systèmes stratégiques, du point de vue commercial, ont normalement une feuille de route, ils ont des jalons, ce qui signifie que l'entreprise planifie pour eux, du point de vue commercial, il y a un plan pour eux. Et à mesure que les équipes itèrent, l'entreprise ajuste ce plan, ajuste ces jalons, ajuste les priorités dans le backlog. Mais ce que nous ne faisons pas, c'est cette stratégie sur l'idéation et la planification stratégique qui se déroule normalement au niveau du produit, nous le faisons au niveau du produit, mais nous ne le faisons pas au niveau de la technologie. Donc, au fur et à mesure qu'ils créent et définissent le produit, qu'ils discutent des feuilles de route et des changements de feuilles de route, qu'ils discutent des jalons. Nous devrions travailler ensemble pour dire, d'accord, si je comprends ce que vous essayez de faire, je peux dire si c'est faisable. Quelle est sa faisabilité technique ? Avons-nous besoin d'acheter un système ? Avons-nous besoin d'intégrer ? Combien de systèmes vont être changés ? Avons-nous besoin d'une technologie différente ? Alors, combien ça va coûter, au moins une estimation grossière ? En termes non seulement d'achat de licences ou de matériel, mais aussi d'effort de développement. Bien sûr, nous ne ferons pas d'estimations à ce niveau. Mais nous pouvons avoir une estimation approximative, nous parlons de six mois, peut-être que c'est une année complète. Peut-être un programme de deux ans, donc vous pouvez donner cette estimation. Juste pour commencer. Une fois que nous avons plus de clarté sur la feuille de route.
[00:57:20] Alors c'est bon, si c'est notre feuille de route pour les 6-12 prochains mois, du point de vue commercial. Notre architecture le supporte-t-elle ? Avons-nous une architecture capable de le supporter ou devons-nous ajuster notre architecture ou en créer une nouvelle pour supporter cette feuille de route ? Et à mesure que nous itérons, nous devons également nous assurer de prendre des décisions stratégiques au niveau technique.
[00:57:43] Et au fur et à mesure que nous atteignons les jalons et les incréments, ou si vous n'aimez pas les incréments, les user stories ou quoi que ce soit d'autre, nous devons également commencer à affiner la conception de bas niveau.
[00:57:54] Le problème est que ces cases vertes sur l'idéation, la stratégie et la planification, elles n'arrivent normalement pas. Normalement, c'est fait au sommet pour l'entreprise, mais la technologie est impliquée une fois que le backlog est déjà créé et les équipes travaillent normalement sur les éléments prioritaires du backlog. C'est ainsi que je vois généralement beaucoup d'implémentations agiles.
[00:58:17] Il y a beaucoup de réflexion sur le produit. Mais les équipes, leur interaction avec l'entreprise est la suivante : quels sont les niveaux supérieurs du backlog ? D'accord, comment le divisons-nous en une itération ? Et ensuite ils travaillent au niveau de l'itération, parce qu'ils travaillent sur ce moule. Ils ne peuvent pas faire de changement architectural significatif ou créer une architecture ou une stratégie technique, quand ils itèrent simplement l'un après l'autre, et ils n'ont pas la visibilité complète parce que ces décisions doivent être prises. Tandis que l'entreprise ajuste le portefeuille et les feuilles de route, c'est ce que nous voulons réaliser.
[00:58:52] Et pour cela, si vous partez de zéro, c'est facile. Mais si vous avez un tas de code hérité, vous devrez commencer à moderniser vos systèmes pour assurer cet alignement. Alors,
[00:59:04] Voilà ce que je voulais partager avec vous, alors euh j'espère que cela vous a été utile.
[00:59:10] Mais oui, donc voici comment nous pensons aux choses que vous devriez considérer si vous envisagez de mener le changement.

Transcription (Traduit)