Sous ce titre quelque peu accrocheur se cache en réalité un projet ambitieux de longue haleine et complexe assorti de beaucoup de décisions stratégiques !
Cet article est l'occasion de décrire une situation, qui à mon sens, n'est pas unique ou isolée, ainsi que les solutions possibles et les transformations à prévoir.
Je vais m'efforcer d'être le moins technique possible, d'autres articles suivront pour ceux qui en sont friands 😊.
Au début il y avait le contexte
J'ai été sollicité par une entreprise dont l'activité n'est pas l'informatique, sur mon expérience d'architecte logiciel, pour mettre en place un nouveau socle technique afin de moderniser plusieurs éléments de son écosystème logiciel.
J'ai dû appréhender un passif de plus de 10 ans, beaucoup de petites applications fonctionnant de manière isolée, plusieurs outils web dédiés à la gestion de l'activité métier.
L'entreprise avait la culture du PGI (Progiciel de Gestion Intégré ou ERP en Anglais) de ce fait, tout l'applicatif en place était lié par un tronc commun: une base de données monolithique.
Les différentes applications, des sites web, avaient un autre tronc commun: les langages tournaient tous autour du .net, ce qui m'a immédiatement intéressé puisqu'il s'agit de ma spécialité, surtout le .Net Core.
Puis vinrent les problèmes
Et quels étaient les problèmes ?
Beaucoup !
Mais encore ?
Eh bien puisqu'il faut commencer par quelque chose, je dirais en premier le facteur humain.
Le facteur humain
L'équipe était très (trop !) petite: une 2-pizza team 🍕🍕 … pour l'ensemble de l'écosystème.
Pour rappel, le concept de 2-pizza team est l'émanation de Jeff Bezos, CEO d'Amazon, affirmant que la taille idéale d'une équipe correspond au nombre de personnes que l'on peut nourrir avec 2 pizzas, soit entre 5 et 10 personnes.
Bon, cette donnée est relative et dépend tout de même de l'appétit des protagonistes mais passons …
L'équipe était organisée en silos techniques:
- Les techniciens IT, en charge des infrastructures et du réseau ;
- Les développeurs en charge de … dois-je vraiment préciser ?
Sur le plan opérationnel, l'empirisme était la règle: tout se faisait en réaction plutôt qu'en prévision.
En effet, les demandes provenant des utilisateurs étaient captées par des experts métiers officiant en tant que support, externes aux équipes informatiques, ce qui induisait une forme d'urgence systémique puisque la majorité de la valeur produite ne consistait qu'au règlement des problèmes rencontrés.
Le fait que chaque pôle de compétences travaillait en silo ne facilitait d'ailleurs pas la communication et l'organisation était analogue: fermée, compliquée et incapable d'évoluer.
L'organisation
Le fonctionnement en silo est le fait que chaque équipe (ou département, ou même service) exerce son activité, relative à sa spécialité, sans se soucier de l'activité des autres.
Pour aller à l'essentiel, le principe de silos, s'il permet de bien délimiter les compétences et donc (logiquement ?) les responsabilités de chacun, n'est pas réputé pour ses forces en matière de communication, de synergies entre les équipes et de capacité d'adaptation sur le long terme.
Sur le plan de la méthodologie en place, Il n'y en avait pas forcément: la production était simplement portée par le besoin «le plus pressant» et quelques projets sporadiques visant à ajouter des fonctionnalités nouvelles ou des évolutions nécessaires.
Pour accompagner cette activité et donner du liant, des outils étaient bien évidement en place: ticketing, actitivity-tracker et pour le reste … échanges de mails.
En termes de sociologie d'équipes, le fait d'être isolé rend les gens méfiants, suspicieux de la qualité et du travail des autres, peu impliqués dans un effort collectif et tout cela se ressentait, une forme de tension existait entre chaque service et l'activité peinait à atteindre un optimum.
De même, il était compliqué de déterminer le niveau d'implication et de responsabilité de chacun puisque l'activité était plutôt répétitive et monotone, bref plus contrainte que stimulante.
Le manque de méthodologie clairement définie générait également un manque de traçabilité, tant dans les éléments de travail que dans l'activité de chacun.
La technique
Sur ce point, l'écosystème présent était très … plurale.
Effectivement, beaucoup de langages issus du .Net pour la plupart ont été employés à différents moments de l'histoire de l'entreprise, citons tout de même de manière non exhaustive et non ordonnée: ASP classic, ASP.NET MVC 5, ASP.NET WebForms.
Une multitude d'applications consoles en .Net framework 4.0 à 4.8 revêtant la forme de services Windows, quelques modules PHP, et quelques WinForms venaient compléter ce panel.
Pour ajouter un peu de complexité à cette diversité de langages, les développements ont été, dans le passé, confiés à des équipes qui n'existent plus, il n'y avait bien entendu que le strict minimum en termes de documentation et certains applicatifs n'étaient même pas publiés dans un dépôt de code.
Pour ce qui est des dépôts de code, des partis pris radicaux quant aux bonnes pratiques d'ingénierie logicielle et des principes d'industrialisation ne rendaient pas forcément le code disponible exploitable.
En ce qui concerne le code en lui-même, plusieurs éléments m'ont sautés aux yeux immédiatement:
- Absence totale de tests techniques (unitaires, intégration, …), de même que pas de tests de qualification ni de protocole de non-régression mais cela est hors scope si on se place sur le plan technique (dis donc ! tu ne serais pas en train de reproduire un silo idéologique là ?) ;
- Niveau de maturité du code très hétérogène ;
- Aucune règle de confection de code (organisation des éléments au sein des classes, règles de nommage, nomenclatures) ;
- Aucun patron de conception guidant les développements ;
- Une complexité cyclomatique, c'est-à-dire le nombre de chemins « linéairement indépendants » empruntable au sein d'une fonction, proche de l'incroyable ;
- Une interdépendance élevée entre les différents blocs de code ;
- Des couches organisationnelles peu ou pas du tout déterminées ;
- Non-respect des principes d'ingénierie logicielle (SOLID), redondance, code et fonctions dupliqués ;
- Des solutions trouvées à des problématiques spécifiques plus proches du bricolage (tiens, c'est à la mode ça en ce moment …), voir du POC (Proof of Concept), que de vrais éléments techniques robustes et maintenables;
- Sur le principe de l'ERP: recours à une super base de données, un monolithe persistant sur lequel TOUS les applicatifs venaient se raccorder, ainsi qu'un couplage fort avec celle-ci (c'est mal !) ;
- Une utilisation très limitée des possibilités relationnelles de cette base de donnée SQL, beaucoup d'ambiguïté dans les noms de table / colonne ;
- Last but not least: pas d'Api's !!!!
La somme de ces éléments rendait les applicatifs très difficiles à maintenir, faire évoluer, et tout reposait sur la connaissance de l'homme du métier puisqu'aucune documentation ne venait assortir le code.
Pour parachever cet instantané de la situation technique, le système de mise en production était très artisanal, basé sur des outils dépassés et le recours systématique à une intervention humaine sur les serveurs plutôt qu'une judicieuse et millimétrique automatisation…
Et au milieu … l'analyse
Tout d'abord, je souhaite rappeler et mettre en avant le fait que cette entreprise n'est pas spécialisée dans le domaine informatique, ce dernier ne jouait jusque-là qu'un rôle de support d'activité, comme dans bien des entreprises d'ailleurs.
Le problème avec cette approche est relativement simple: la croissance et le développement de l'entreprise ont rendu ce rôle de support inadéquat. La DSI n'a jamais pris la pleine mesure de l'évolution et n'a jamais adapté son organe à la réalité de la situation qui imposait un nouveau champ d'action: grandir et devenir une vraie entité produisant de la valeur et du business, et non plus un simple support.
First Principle
Mes premières conclusions ont été dans ce sens et en se référant au «First Principles Thinking» - basiquement en me limitant à poser la question Pourquoi ? - j'ai pu réduire le problème à quelques questions, que voici, livrées avec leurs réponses:
- Pourquoi cette faiblesse technique ?
- Manque de connaissance architecturale et lacunes en ingénierie logicielle;
- Manque d'ambition et d'engagement pour changer les choses;
- Manque de confiance en la perspective d'un socle technique moderne, cloisonné à quelques technos mais fortement maîtrisé ;
- Manque de qualité dans le code permettant de déceler et d'anticiper les anomalies ;
- Une technique vieillissante incapable d'accompagner la croissance de l'entreprise et de répondre à de nouveaux défis, ou tout simplement de traiter l'information de manière optimale.
- Pourquoi ce fonctionnement en silos et ce manque de communication ?
- Pas de méthodologie clairement établie ;
- Pas assez d'interactions entre les équipes et donc une méconnaissance de l'«Autre»;
- Des outils peu adaptés et peu claires dans leur fonctionnement;
- Des ambiguïtés sur les rôles de chacun;
- Un manque de confiance de la direction générale envers la technique ainsi qu'une culture du service opérationnel quelque peu dépassée.
- Pourquoi ces difficultés à produire et publier du code ?
- Pas de process de livraison clairement détaillé ;
- Pas ou très peu de processus de validation des livrables, de même qu'un manque de clarté pour ces derniers ;
- Pas d'automatisation (CI / CD) et recours bien trop prononcé à l'humain (donc à ses faiblesses et limites !) ;
- Équipe créant de la valeur totalement sous dimensionnée, dépassée par les événements et travaillant la plupart du temps en mode «pompier».
Une dernière question subsistait, éloignée du pourquoi mais tellement centrale: qu'en est-il de l'utilisateur final ? Tous ces problèmes entachent-ils l'utilisation des différents outils et ces derniers répondent-ils aux attentes des utilisateurs (le personnel de l'entreprise en grande partie)?
Fort de cette analyse, j'ai raisonnablement pu déterminer plusieurs axes d'amélioration, voire de rupture.
Et suivirent les solutions
Organiser le changement technique et technologique
L'évidence était là: il fallait augmenter le niveau de maîtrise des technologies travaillées tout en capitalisant sur les compétences existantes.
En essayant de rationnaliser au maximum, il fallait conserver le savoir-faire existant et donc rester sur les technologies afférentes au .Net.
Il fallait, dans le même temps, s'inscrire dans la modernité et mettre en place un nouveau socle technique, moderne et qui serait également l'opportunité d'une architecture logicielle répondant à certaines caractéristiques, notamment les principes du Reactive Manifesto:
Source https://www.reactivemanifesto.org
Ceci pour plusieurs raisons:
- Le développement de l'entreprise induit d'avoir une solution technique scalable et extensible ;
- Plusieurs applications, avec chacune leur responsabilité et portée spécifique, vont émerger de cette analyse et il faudra les rendre inter-communicantes, quoi de mieux qu'une plateforme échangeant via un agent de messages pour assurer cette fonction !
- Il faut, à termes, être capable, de gérer au mieux les anomalies, idéalement les anticiper, à minima ne pas perdre d'activité et pouvoir débloquer des situations complexes ;
- Les différentes applications doivent être totalement user-centric, c'est-à-dire basé sur l'analyse des comportements des utilisateurs, et favoriser l'expérience de la meilleure manière possible ;
- Apporter des briques rendant possibles l'innovation ;
- Enfin, la solution technique doit permettre des livraisons rapides, sans faille et à un rythme soutenu, sur une plateforme offrant souplesse et adaptabilité, probablement hébergé via un cloud …
J'avais dès le début en tête une approche basée sur la mise en place d'une nouvelle stack technique, simple mais maitrisée: .Net Core + Angular.
.Net Core
Ce langage permet de développer des applications de haute qualité, modernes, rapides et en accord avec la philosophie des micro-services.
Il met rapidement à disposition les dernières fonctionnalités développées, communautaires ou éditoriales, et permet une grande modularité, il est également totalement tourné vers l'open-source et le cloud.
.Net Core permet de mettre en place relativement facilement une Architecture Orientée Services (SOA) d'entreprise: les données seront désormais exposées via des Api's.
Cela constitue donc l'opportunité de conceptualiser une batterie de micro-services, totalement orientés métier, propriétaires et responsables pour chacun de leur système de persistance (ce qui change radicalement du paradigme existant).
Pour le volet inter-communicabilité, il a fallu mettre en place un broker de messagerie (RabbitMq) assorti d'un framework accélérant les développements (Mass-Transit) et facilitant la concurrence car il repose sur TPL (Task Parallel Library).
Angular
Afin d'homogénéiser les pratiques sur le plan du web, l'expérience utilisateur et la captation des données, il fallait simplifier l'existant, apporter une forme d'unicité dans l'offre de l'entreprise.
En l'état, les solutions traditionnelles proposées par la stack - vieillissante - .Net (asp.Net MVC assorti du moteur de vue Razor, WebForms ou encore ASP Classic) ne donnaient pas satisfaction et n'accompagneraient pas une montée en gamme et en technologie.
D'autant plus que les langages employés imposaient un fort couplage avec le back-office. Il fallait donc assurer un cycle de vie pour les applications front indépendant de celui du back, limiter autant que possible ce que j'appelle l'hybridation, à savoir les langages responsables à la fois du back et du front.
J'avais l'idée qu'il fallait idéalement partir sur une solution front mature, modulaire, évolutive et «architecturable», cela dans une double optique: organiser la rupture technologique et unifier le processus de création web.
Angular a pour particularité de reposer sur TypeScript, un langage typé objet compilant du javascript, proche du C#, et d'être très modulaire puisque basé sur une architecture … en modules !
Il dispose d'une très forte communauté et est très bien documenté, tout en proposant un niveau de maturité et de fonctionnalités très élevé et en plus de tout cela, NG (son petit sobriquet) est mis à jour fréquemment, peut-être trop depuis 2 ans … mais je m'emballe.
Le dernier atout d'Angular est qu'il peut être monté en Micro-Front end moyennant recours à quelques frameworks dédiés. Je pense que nous avons là une très bonne solution front modulaire et permettant de faire beaucoup de choses.
Et tu fais quoi de l'existant ?
Une question est effectivement tout de suite apparue: que faire de l'existant ?
Eh bien je me suis tout de suite fixé comme ligne de conduite de ne pas modifier cet existant, ou du moins le minimum possible, ce qui a rapidement induit une gouvernance claire:
- Développement d'un site vitrine et du back office organisé en micro-services ;
- Étranglement applicatif pour une partie de l'existant ;
- Maintenance thérapeutique sur les éléments ne supposant ni reprise ni évolution.
Je vais présenter rapidement les différents principes mis en place sans toutefois apporter trop de détails, cela fera l'objet de futurs articles (un peu de teasing ne fait jamais de mal !).
Site vitrine
Le développement de l'application vitrine, un site web, a été l'occasion de mettre en place une architecture signature qui encadrerait les développements, a permis de développer un maximum de micro-services tout en intégrant des tests techniques ainsi que l'écosystème permettant de gérer le flux produit: des pipelines de CI / CD via Azure DevOps assorti d'une stratégie d'hébergement cloud (Azure).
Ce chantier a été l'opportunité, à travers l'architecture que j'amenais et le mentoring, de faire monter les équipes en compétence sur des techniques que j'avais pris l'habitude d'utiliser:
- TDD (Test Driven Development) ;
- Code First en utilisant Entity Framework Core ;
- Event Sourcing et CQRS, puis MDA (Message Driven Architecture) ;
- In-Memory testing (In-memory Database, proxy http, Web-Application Factory).
Mais également de nouvelles choses pour moi, comme BDD (Behavior Driven Development) via SpecFlow (.Net Core) et Cucumber (Angular) qui reposent tous 2 sur le langage Gherkin 🥒 et permettent d'écrire et développer des tests typés « comportement » assez facilement.
Dans cet esprit, une équipe a été créée afin de mettre en place le nouvel écosystème, nous pouvons qualifier celle-ci de platform team pour faire référence aux Teams Topologies, puisqu'elle a été en charge de toute la mise en place:
- Utilisation de l'architecture que j'avais définie et développée;
- Écosystème micro-services «Cloud-ready» pour lequel il a fallu définir et créer les environnements, les pipelines d'intégration et déploiement continue;
- Création des «Apis d'équipe»: pages Swagger pour les micro-services, documentation via un wiki dédié dans Azure DevOps;
Stratégie d'étranglement applicatif
Si l'application vitrine visait à remplacer son pendant existant par une nouvelle application, un traitement différent a été choisi pour les autres éléments de l'écosystème (des sites web) nécessitant une reprise totale: l'étranglement applicatif.
L'étranglement applicatif est un concept émanant de la démocratisation des micro-services, celui-ci repose sur un passage organisé et cadencé de pans entiers d'applications, systèmes de persistance vers une nouvelle solution technique, il permet de moderniser graduellement l'existant tout en ne dégradant pas l'activité.
Bien évidemment, cette technique suppose de pouvoir échanger les données entre l'ancien et le nouveau paradigme, il a donc fallu conceptualiser et développer … un micro-service raccordé sur la base de données existante capable de détecter automatiquement toute modification de données et de recevoir les modifications provenant des autres services.
Cette fonctionnalité repose sur l'usage massif de l'event-sourcing, en gros de transmettre une information une fois qu'un événement est détecté, et l'échange de messages entre les différents micro-services présents.
Du coup, la mise en place technique résultant des développements du site vitrine rendait possible beaucoup de choses.
A termes, Il n'y a donc plus deux paradigmes distincts (le «legacy» et le «new») mais bel et bien un seul proposant une multitude d'éléments cohérents et inter connectés.
Pour le reste, il fallait rapidement rendre l'existant industrialisable (sur le même plan que l'application vitrine) et une phase de migration vers des dépôts Git et une gestion de flux CI / CD via Azure DevOps a été planifiée et exécutée, ce qui a évidemment induit une refonte de l'équipe de développement.
Très rapidement, pas mal de retour d'expériences sur ces éléments ont permis d'apporter des ajustements sur le site vitrine avant qu'il ne passe en production, ce qui est une forme de capitalisation relativement luxueuse: savoir à l'avance ce qui fonctionne mal et pouvoir l'ajuster.
Organiser le changement organisationnel et méthodologique
Refonte de l'équipe de développement
Si l'on reprend le principe de «charge cognitive d'une équipe» exposé par Matthew Skelton et Manuel Pais dans leur ouvrage Team Topologies, avoir une seule équipe pour gérer et maintenir un pool d'applications parait totalement sous-dimensionné.
Il a donc fallu redéfinir l'équipe en place et en créer une nouvelle, en adéquation avec le nouveau socle technique mis en place, de manière à avoir une charge cognitive beaucoup plus raisonnable.
Donc, comme exposé dans le paragraphe précédent, cette refonte du SI tourne autour de 2 équipes: l'une (historique) gérant les applications existantes (le legacy) et l'autre dont l'activité tournait autour de la mise en place du nouveau socle technique et d'un site vitrine.
Voyons maintenant comment celles-ci fonctionnent.
L'organisation
Il a fallu mettre en place une organisation capable de supporter les nouvelles contraintes techniques.
Un nouveau service en résulte, plus proche à la fois du besoin utilisateur, des développements et de l'opérationnel.
Pour ce faire, l'approche DevOps a été la ligne directrice, terminé donc le cycle de vie et place au flux continu, exit les silos, bienvenu la collaboration !
Les équipes sont désormais constituées de développeurs, de l'AMOA (les fameux experts métiers) ainsi que de business-analysts et de nouvelles compétences propres à l'infrastructure et au réseau, applicables dans un domaine Cloud.
Cela induit évidemment la destruction des silos par compétence et laisse place à un fonctionnement où tout est plus simple, mieux huilé, tout le monde travaille dans un seul but: produire de la valeur et donner satisfaction aux utilisateurs.
En termes d'outils, là aussi, une forme d'harmonisation apparait puisque les outils existants ont été remplacés par un seul outil, central, suffisamment puissant et modulaire pour être la colonne vertébrale de l'activité sans toutefois être chronophage dans sa gestion.
J'ai opté pour Azure DevOps, j'aurai pu utiliser autre chose mais il se trouve que je souhaitais capitaliser sur mes expériences, mon savoir, et c'est un outil que je maîtrisais déjà.
Je savais qu'il nous permettrait de mener notre barque efficacement et qu'il nous accompagnerait dans nos évolutions.
Il a fallu une période de mise en place puis de training et d'acquisition afin que tout le monde s'adapte et devienne autonome, efficace avec cet outil.
Nous avions désormais les équipes (même si des recrutements étaient nécessaires pour acquérir les compétences manquantes), les outils et le fonctionnement drivant notre activité, ne restait plus qu'à définir quelle méthodologie allait rendre tout cela cohérent et efficient.
La méthodologie
Il nous fallait être efficace, en capacité de produire vite … et beaucoup (un socle technique complet développé en moins de 3 mois avec une équipe réduite !), et gérer un rythme assez soutenu.
Cela supposait une méthodologie adaptée.
J'avais le pressentiment que Scrum était le candidat idéal, sentiment partagé par mon Directeur de projet ainsi qu'une grande partie de l'équipe.
Je ne m'attarderai pas sur Scrum, beaucoup d'articles le dépeignent déjà, mais son apport a été immédiat:
- Gain en flexibilité dans les développements ;
- Meilleure gestion des ressources et ajustement des éléments à produire ;
- Retours d'expérience rapide ;
- Engagement de chacun.
Ce dernier point est important car, le niveau d'adhésion avant cette refonte était très bas, il n'y avait aucun projet ambitieux et aucun challenge dans l'activité.
L'engagement de tous a permis de se remobiliser, d'avoir un objectif tangible, complexe et difficile à atteindre mais finalement gratifiant pour tout le monde.
De plus l'activité devenant beaucoup plus rationnelle, avec des objectifs et des temps forts, il était désormais possible de voir des résultats rapides, ce que l'on appelle des quick-wins et de redonner une note positive à l'activité informatique.
Le mot de la fin
Pour finir, je citerais simplement Albert Einstein pour qui «La folie, c'est de faire toujours la même chose et de s'attendre à un résultat différent » ainsi que Bill Campbell (The Trillion Dollar Coach): «Le leadership consiste à reconnaitre qu'il y a de la grandeur en chacun et votre travail consiste à créer un environnement dans lequel cette grandeur peut émerger».
J'ai eu à cœur d'appliquer ces 2 maximes et d'en faire une réalité tangible.
J'espère que ce retour d'expérience, même s'il est très en surface pourra donner des pistes à toute personne se retrouvant dans une situation analogue.
Je finirai en disant que rien n'est possible quand on essaye d'avancer seul et qu'il faut s'efforcer de créer des synergies entre les hommes et les outils disponibles.
Top comments (0)