Alors où en sommes-nous dans notre étymologie sur la modernisation d’application?
La première partie de ce blogue nous rappelait qu’il faut d’abord qu’il y ait un réel désir de se réinventer. On ne prend pas seulement une applications existante et on en modernise l’infrastructure, sa plate-forme ou son architecture interne. Il faut que se réinventer fasse partie de notre quotidien. Parce que la partie la plus difficile vient souvent d’une certaine réticence à accepter le besoin de changer. Et lorsqu’on en comprend la nécessité, le besoin de revoir les structures traditionnelles devient clair lui aussi.
Et c’est aussi un processus qu’il faut savoir diviser en plusieurs étapes, plus digestes et cycliques. Nous avons vu dans la deuxième partie que bien choisir sa technologie est important, mais aussi de rester objectif, de respecter les étapes, et surtout, de bien communiquer. Nous parlons ici de rigueur et collaboration.
Alors que nous reste-t-il d’autre à parler? De continuité… la suite logique d’une bonne modernisation d’application. Parce qu’il faut savoir quoi faire pour demain, ce futur indéterminé (mais assuré) où repose la destination.
C’est jamais fini.
Si vous êtes comme moi, vous êtes possiblement hanté par le désir de laisser quelque chose derrière pour la prochaine génération. Ce genre de quelque chose qui représente l’effort de votre vie. Pour certains, d’avoir élevé une famille ou vécu avec confort leur suffisent. Et je les admire. Mais on ne me rassasie pas si facilement. Toutefois, j’essaie de rester réaliste.
Ce n’est peut-être pas toujours évident de laisser aller l’oeuvre d’une vie et d’en avoir une appréciation juste. En fait, c’est un peu difficile de s’imaginer ce que le futur réserve à nos successeurs. Mais j’ai envie de rester pratique et de vous faire une proposition assez simple, que je vous invite à essayer.
Il me parait évident que tous les efforts qui en valent la peine sont souvent des efforts investis. On peut dire que le temps et la patience semblent être des valeurs récurrentes qui nous permettent aussi d’assurer que le produit de nos efforts soit PLUS que simplement la somme de ses parties. Ceci pourrait vous sembler un peu contradictoire, mais ce que je vous propose ici, c’est une économie de votre temps et de votre… tempérament. Voyons voir comment l’appliquer à la modernisation d’application.
Moderniser, ce n’est pas jeter la conscience au vent.
D’entrée de jeu, ces propos me semblent un peu éloquent. C’est vrai. Mais où j’aimerais en venir, c’est qu’il faut savoir peser le pour et le contre entre un esprit conservateur, critique et celui plus innovant. Oui, il y a un adage qui se prête bien pour exprimer cette pensée: si ce n’est pas cassé, pourquoi le réparer. Et bien, c’est là que réside toute la subtilité.
N’attendez pas d’être « cassé » — ou dans ce cas-ci, « dépassé ». Cela est tout aussi mortel. Mais évoluer est un acte d’équilibre digne d’un funambule! Le terme est plus approprié que vous pourriez l’imaginer car, si on remarque bien, l’acrobate mesure et prend des pas qui lui sont pratiques. La modernisation d’application, c’est un peut ça. De plus, il est outillé pour pouvoir se stabiliser et se reprendre en cas de vacillements!
Et voilà une bonne allégorie… si vous voulez bien suivre mon conseil.
Considérez de risquer seulement ce que vous pouvez vous permettre. Et quand vous faites cette considération, prenez soin de bien placer chaque action dans le temps, c’est ce qui est la base de toute expérimentation.
Validez vos hypothèses. Toujours et encore. Considérez les tests et les validations comme des filets de sûreté dans votre processus de modernisation d’application. Personnellement, je trouve que les cycles de réalisation sont tout aussi pertinents en mode macro qu’en mode micro. Et qu’on regarde la livraison d’un MVP complet ou celle d’une fonctionnalité spécifique, je ne crois pas qu’il soit moins pertinent de tester et de s’adapter pour l’un plus que pour l’autre. Et c’est comme ça que vous allez survivre à la marche sur la corde raide.
Rares sont ceux qui peuvent se permettre une grande chute!
Vivre = Survivre
Je ne vous propose pas ici de ne vivre que des moments tendus. Il n’y a rien qui dicte ou force, dans les bonnes pratiques, (et particulièrement celles du DevOps), de ne faire que des actions en hauteur et sans filet. Au contraire, donnez-vous l’espace pour faire vos essais dans un endroit sûr, mais conforme à la réalité finale. Et si cela s’avère trop difficile comme exercice, peut-être vous devriez reconsidérer la portée de ce que vous allez livrer. Personne ne vous dit de prendre des risques inutiles. Donc, n’en prenez pas. Mais il est vrai que tout le monde fait des erreurs. Alors plutôt que d’essayer d’établir la perfection dans vos processus, je vous propose d’y incorporer la notion d’erreur.
C’est un principe bien connu en technologies de l’information. Même si on livre quelque chose qui est sensé avoir tout considéré, on investit une partie de son « livrable » dans un journal ou un « log » où on inscrira les erreurs inattendues. J’ai beaucoup de difficulté à écrire cette phrase sans sourire. Parce qu’elle semble rationaliser en un seul coup tout mon propos. Je crois sincèrement que les erreurs existent en deux saveurs: celles qu’on attend et celles qu’on ne voit pas venir. Et c’est bien cet écart qui cause un inconfort profond entre les projets qui avancent et ceux qui meurent. Il y en a une seule variété qui survit systématiquement. Celle qui a tout fait pour non pas prévenir les erreurs, mais les mitiger.
En avant toutes! Mais non.
On ratisse beaucoup plus large quand on tente de mitiger que d’adresser un problème spécifique avec précision. C’est juste un peu plus simple de mettre un filet en-dessous de la corde raide que de prévoir, où exactement on va trébucher, si on poursuit l’analogie. Et quel soulagement que de savoir qu’une chute ne sera pas fatale. On pourrait presque en faire une carrière à ce moment là. Allègrement!
Elles sont rares ces opportunités qui nous permettent de foncer sans égard pour ce qui vit sous la surface. Dans votre projet de modernisation d’application, vous savez sans doute où vous vous rendrez à ce stade. Ce qui risque d’être moins évident, c’est comment vous allez reprendre le prochain cycle et vous assurer d’avoir incorporé un élément d’évolution pour votre prochaine grande livraison. Qu’est-ce qui vous donnera l’accélération requise? Quel sera le véhicule de votre succès.
Nos outils
Je trouve qu’il n’y a rien de plus humain, à part nos fautes, que notre amour pour nos outils. En fait, selon moi, là repose possiblement le meilleur des moyens d’agencer nos façons de faire avec nos moyens. Vous savez, en DevOps, on dit souvent que les éléments du succès sont « les Personnes, les Processus et les Produits » (people, process and tools) et cela restera vrai jusqu’à la fin. Nos processus existent pour nous protéger et nous permettre d’apprendre, mais nos outils sont là pour nous donner la force là où elle nous manque le plus.
Et je vous le confirme, c’est presque universel. Notre faute repose le plus souvent dans nos méthodes de revues, nos évaluations « post-mortem ». Mais encore pire, à mon avis, de peur de s’exposer à encore plus de fautes, on semble privilégier une espèce d’homéostasie où l’entropie d’être collé au sol nous assure la survie pour le prochain cycle. C’est tout à fait faux. Si vous et moi sommes ici, c’est que les poissons sont sortis de l’eau. Et notre première révolution technologique, l’opérationnalisation du feu, aurait été autrement difficile, sinon. Et on l’a fait sans un plan, en plus!
Conclusion
Essayez de ne pas voir votre destination comme une finalité. Pensez que votre livraison applicative ne sera qu’une étape dans une plus grande aventure. Non seulement vous y verrez plus clair, mais vous risquez de mieux découper votre projet en parties digestes et en étapes qui sont résilientes.
Il n’y a rien qui me plait plus que de voir les gens se munir des moyens pour vivre une livraison de projet avec un sourire. Un des moments les plus mémorables de ma vie fut le jour ou j’ai lancé une mise en production à partir de mon téléphone, assis dans un train. J’ai eu droit à toute une panoplie de collaborateurs et de clients exceptionnels pour en arriver là. Mais ce que j’aime offrir en échange, c’est une belle aventure. Celle où la destination repose encore dans un futur indéterminé, mais assuré.
JP
