Dans la première partie de notre article sur la modernisation d’application, on parlait de se réinventer. Parce que parler modernisation d’application, c’est bien plus que prendre les applications existantes et d’en moderniser l’infrastructure, leur plate-forme, leur architecture interne, etc.
La partie la plus difficile vient souvent d’une réticence à accepter le besoin de changer. De comprendre la nécessité de revoir les structures traditionnelles. C’est un processus qu’il faut diviser en plusieurs étapes. C’est d’ailleurs ce dont nous allons parler dans cette 2e partie, en plongeant dans les principes et les processus. Le tout teinté de DevOps. Et oui, encore et encore.
Il est vrai qu’il faut savoir bien choisir sa technologie lorsque l’on décide de faire le saut dans la modernisation d’application. Mais il est aussi important de rester objectif, de respecter les étapes, et surtout, de bien communiquer. Nous parlons ici de rigueur et collaboration.
Les yeux bien ouverts
Alors parlons principes et processus. Parmi les plus sains et les plus efficaces, selon moi, figurent ceux qui sont cycliques. Et qui ont une part équilibrée entre le désir de faire des efforts pour avancer et la réflexion en arrière scène.
D’ailleurs, ceux qui ont lu notre livre blanc sur le SecDevOps : Personnes, processus et produits ou qui ont suivi quelques-uns de mes webinaires, vous savez que je réfère fréquemment à la roue de Deming. C’est aussi ce qu’on appelle le processus industriel du «PDCA». Ce que je trouve de particulièrement utile dans l’application d’un tel procédé? Ce sont ces étapes où on évalue les efforts à l’entrée et les résultats à la sortie. Typiquement, les organisations que j’aide vont assez bien au début du cycle. C’est à la fin, quand il faut s’évaluer et évoluer, que les choses accrochent un peu.
Objectif: objectivité!
Dans tout plan de livraison d’un projet de modernisation d’application, il est utile d’instaurer une charte de projet et d’identifier les jalons ou les «milestones». Ce n’est que par la suite qu’il devient possible de mesurer le passage de ces différentes bornes. Encore une fois, je suis d’avis qu’il est utile de quantifier et de qualifier ces «passages». Ceci de façon à pouvoir établir si un ajustement à notre processus est nécessaire. Ou si l’ajustement que l’on vient d’implémenter nous a donné les résultats escomptés.
L’effet DevOps
S’il y a une chose qui m’irrite (parce que pour moi, il s’agit d’un non sens), c’est quand quelqu’un qui a les mains sur les rennes d’un projet de modernisation d’application et qui a vaguement entendu parler de DevOps dit: «On va mettre un DevOps là-dessus». Comme si la charge d’une pratique DevOps pouvait reposer sur les efforts d’un seul individu. Une espèce de gourou nouvel-âge qui deviendrait la pierre angulaire de notre réussite et possiblement de nos échecs. J’ai beau être le chef d’une telle pratique chez nous, je ne suis rien sans les personnes qui composent les équipes et qui en font la mise en oeuvre. Tout le crédit leur revient, croyez-moi.
Alors sans vouloir trop m’appuyer sur le terme «DevOps», c’est vrai qu’il s’agit après tout de la combinaison de deux «préoccupations» qui ont l’habitude d’être distinctes, DEV et OPS. Si on voulait en faire deux idéaux faciles à visualiser, on pourrait les représenter comme suit: évoluer (DEV) et vivre sainement (OPS). Le fait que nos deux amis (DEV et OPS) semblent avoir des agendas distincts peut en effet affecter négativement notre habileté à livrer nos projets. Alors créditons ici l’ère industrielle pour nous avoir permis de constater que pour livrer avec agilité et aise, il peut être astucieux de se voir comme faisant partie d’une grande chaîne de production.
Chaîner et solidifier les maillons
D’abord, il est important de reconnaître que de la conception à la livraison d’un produit ou d’un projet, il y a une gamme d’étapes toutes aussi importantes les unes que les autres. De plus, le passage dans la chaîne (ou l’avancement) devrait nous apprendre à visualiser l’importance de chacune de ces étapes. Ou, mieux encore, comprendre les gens qui y servent. Et enfin, il nous faut apprendre à mieux effectuer la transition entre la réception du travail de nos collègues «en amont» et le passage de nos propres efforts, en aval. En gros, DevOps, c’est un peu tout ça.
Bref, «compartimentaliser» le travail ne nous servira pas autant qu’on pourrait l’espérer. Cela occasionnera nécessairement des efforts de communications extraordinaires et donc des problèmes potentiels additionnels. On n’en a pas besoin. On défait les «silos».
La dette technique
Objectivement toujours, si nous constatons qu’il y a lieu de moderniser une partie de nos services informatiques, c’est qu’on a pris du retard. De l’admettre de façon générale est habituellement la première étape avant de pouvoir rectifier la situation. Une fois qu’on élimine toute source potentielle de mauvaise foi. Quand on sait que tout un chacun travaille autant que possible, on sait dès lors que le problème doit reposer dans la méthode. Car on le sait très bien, si certains arrivent à rester à jour, alors pourquoi serait-on différent? Je vous propose donc de considérer ceci: il est utile de mesurer jusqu’à quel point nous sommes en retard ou à risque de devenir désuets. Cela afin de correctement évaluer la position où nous désirons être et quand nous souhaiterions y être.
Choisir la bonne technologie
Peut-être s’agit-il d’une surprise pour certains de savoir que les choix technologiques sont souvent un peu «gauchement faits» pour subvenir à NOS besoins. Comment puis-je arriver à cette conclusion? C’est que les informaticiens, pour toute leur panoplie d’outils, arrivent tout de même à se mettre dans des situations compromettantes. Notamment celle de générer de la dette technique, justement. Et alors que nous proposons à notre clientèle d’améliorer leur travail (leur «business») avec des outils, nous avons du mal à en faire autant avec le nôtre. C’est ce qu’on appelle le syndrome du cordonnier mal chaussé. Ce qui nous laisse supposer aussi qu’un grand marchand de chaussures pourrait bien être, en fait, incompétent.
C’est une des erreurs les plus communes. Et cela émane du fait que nous sommes de bien meilleurs experts quand on fournit des services que quand on en consomme. Parce qu’un client, c’est utile!
Encore ici, je propose que cela découle du cycle d’approbation auquel on a droit quand on fournit des services. Chose que l’on fait rarement pour soi. Le fameux «C» dans le PDCA précédemment énoncé: il nous manque régulièrement quand on cherche pour soi. Et donc, nos choix technologiques deviennent un peu impulsifs. Nous imposant ainsi des contraintes et des limites artificielles qui nous empêchent de bien livrer nos projets.
Notre expertise est un obstacle à l’objectivité parfois. Mais elle l’est moins quand on dessert un client!
Ne craignez pas de demander de l’aide
Je tiens à garder ce chapitre court. Cela semblerait assez hypocrite de notre part d’essayer de vous faire croire que nous ne sommes pas là pour vous aider. Parce que notre vraie mission, notre raison d’être, c’est de devenir un agent catalytique pour vos projets. Mais dans le principe, on a tous crainte de s’exposer. Et possiblement de faire une autre erreur qui multipliera la complexité de notre situation.
En DevOps, un de nos principes pour limiter les risques, justement, c’est d’appliquer les changements de façon incrémentales. En «pas de bébé», dit-on souvent. Ainsi quand on va chercher de l’aide, via des collaborateurs externes ou internes, nous investissons graduellement là où le succès se fait sentir. Ou mieux, là où il se mesure. Et c’est comme cela que nous opérons. Alors, mesurez-nous!
La communication, c’est l’ingrédient principal de la collaboration
Un des obstacles nous empêchant souvent de bien réussir un projet, c’est l’existence d’un isolement des parties critiques de la chaîne de livraison. Nous vivons dans une ère sans précédent. Nous devenons intensément conscients de nos manques au niveau de la communication et des effets négatifs du manque de proximité de nos alliés.
Combien de modèles d’affaires vont carrément échouer s’ils n’arrivent pas à évoluer à la vitesse où la société est forcée de le faire? Avez-vous considéré combien d’entre elles on pourrait récupérer si ces commerces étaient naturellement habilités à communiquer et se réorganiser? Sommes-nous tenus de continuer à faire ce que nous avons toujours fait, parce qu’on n’en discute pas?
S’il y a une constante dans mon discours, c’est bien celle-ci: Évoluer nécessite un mouvement collectif bien mesuré et considéré. C’est ce qui nous fait gagner du terrain.
Je propose alors ceci: il est toujours et encore utile de considérer sa «cyclicité» dans ses opérations. Sachant qu’il y aura un terme, une fin rapprochée d’un cycle de livraison, cela nous permet d’acquérir une certaine indépendance sur la structure actuelle d’un processus ou d’une façon de faire. Si se réinventer fait partie de notre quotidien, combien de mal peut-on s’occasionner en tentant de le faire encore une fois? Pas beaucoup.
Est-ce une opportunité inouïe? Absolument.
Simple? Oui. Facile? Non. Mais les choses qui en valent la peine le sont rarement.
Conclusion
Si vous songez à apporter un changement à vos applications d’affaires critiques, essayez de considérer leur évolution en parties plus digestes, cycliques, plutôt qu’en un marathon herculéen. Cela a plusieurs effets bénéfiques qui s’enrichissent en succession. Conséquemment, vous serez en meilleure position pour identifier quels changements seront l’instrument de votre succès. Et ceux à l’origine de la livraison des projets en temps et selon le budget justifié. Minimisez vos risques en vous gardant une chance de vous évaluer et d’évoluer. Sachez reconnaître quand vous «pelletez par en avant» et ne faites qu’accumuler un retard inhérent aux processus intransigeants.
Vous méritez mieux. Après tout, vous devriez pouvoir dire que vous vous servez aussi bien que vos clients. Mais si vous avez la sagesse de reconnaître qu’un appui serait peut-être nécessaire pour regagner du terrain (en modernisation d’application, par exemple), pensez à nous.
JP
