La dure vérité sur la gestion du cycle de vie

L'informatique se trompe souvent dans la gestion du cycle de vie.
Recherchez une définition de la gestion du cycle de vie et vous trouverez quelque chose comme :Une approche stratégique de la gestion du cycle de vie d'une application ou d'une plate-forme, de la conception à la fin de vie — de l'approvisionnement, en passant par les opérations, jusqu'au retrait.
Selon cette définition, la gestion du cycle de vie ne semble rien faire.
Cela n'aide pas à mettre en œuvre une nouvelle plate-forme ou une nouvelle application – c'est à cela que servent vos méthodologies de développement d'applications et de gestion du changement. Cela n'aide pas les opérations quotidiennes – c'est à cela que sert l'ITSM. Cela n'aide pas à retirer une application ou une plate-forme, à part repérer un événement ou une condition qui rend la retraite nécessaire. L'événement peut être externe, comme la faillite d'un fournisseur ou la suppression progressive d'un produit, ou interne, comme si plus personne n'utilisait l'application. Mais retirer l'application ou la plateforme ? C'est à cela que servent l'archivage, le démantèlement et encore une fois la gestion du changement.
La vue d'ici ? La gestion du cycle de vie d'une application ou d'une plate-forme, de sa conception à sa fin de vie, n'est tout simplement pas une tâche sur laquelle les services informatiques doivent investir du temps et de l'énergie.
Gestion de la devise des versions : la gestion du cycle de vie dont l'informatique a besoin
Il existe cependant une pratique de gestion du cycle de vie qui est essentielle — souvent ignorée, mais essentielle. La gestion du cycle de vie dont l'informatique a besoin est un ensemble de méthodes tactiques fiables pour maintenir à jour les plates-formes et les applications commerciales, c'est-à-dire pas plus d'une ou deux versions en retard par rapport à ce que le fournisseur vend actuellement.
Appelez-le « gestion des devises de version ».
Pour contraster avec la gestion du cycle de vie habituelle, imaginez pour les besoins de l'argumentation que certaines de vos applications s'exécutent sur EnGarde Secure Linux.
EnGarde va bien au-delà de la fin de vie. Pour emprunter aux Munchkins, ce n'est pas simplement mort; c'est vraiment très sincèrement mort. Vos serveurs n'ont peut-être pas entendu la nouvelle, mais ce n'est pas parce qu'ils continuent de fonctionner que vous êtes dans une situation satisfaisante.
Le fait qu'EnGarde fonctionne sur un serveur en fin de vie ne signifie pas qu'il s'installera sur le nouveau matériel que vous n'avez pas le choix d'acheter lorsque votre serveur en fin de vie devient un serveur expiré. Cela ne signifie pas non plus qu'il fonctionnera avec une mise à jour de l'une des plates-formes qui s'exécutent dessus, ou avec une mise à jour d'une application qui en dépend.
EnGarde, comme toute autre technologie obsolète et non prise en charge, continuera de fonctionner jusqu'à ce qu'elle ne fonctionne plus. Et quand ce n'est pas le cas, l'informatique fait face à une crise.
Éliminer EnGarde de votre portefeuille de plateformes n'est pas une gestion du cycle de vie, car à aucun moment de la procédure, il n'y a eu de cycle de vie à gérer. Lorsque EnGarde a présenté sa distribution Linux, il n'avait finalement pas fixé de date de retraite dans ses plans commerciaux et de produits. L'informatique non plus lorsqu'elle l'a sélectionnée. Lorsque le service informatique a intégré EnGarde dans son portefeuille de plates-formes, sa disposition aurait été Conserver ou Prolonger.
Non, du point de vue des architectes de l'informatique, l'arrêt d'EnGarde était un événement – un événement malheureux qui a changé la vie d'EnGardeViabilité du fournisseur et du produitButde ce qu'il avait été la dernière fois que les architectes de l'informatique l'avaient visité à -2 (le pire score possible), et sa disposition soit à remplacer, si sa fonctionnalité était toujours nécessaire, soit à se retirer si aucune application ou plate-forme ne fonctionnait plus dessus.
Comparez cela à une entreprise qui s'est appuyée sur BizTalk 2016 comme plate-forme d'intégration d'applications. Bien avant la retraite de BizTalk 2016, Microsoft a annoncé que son successeur, BizTalk 2020, serait publié mi-2019, et que la date de fin de vie de BizTalk 2016 (enfin, le mois) serait novembre 2022.
À la suite de ces annonces, avec une pratique de gestion des devises de version appropriée en place, les architectes informatiques auraient inversé la disposition de BizTalk 2016 à la mise à jour et, avec cela, ajouté un projet de mise à jour de BizTalk au calendrier principal et au budget du projet de l'entreprise, programmé pour éviter les dépenses et les risques. de continuer à utiliser la technologie hors support dans le portefeuille de plates-formes.
La gestion de la devise des versions est la gestion du cycle de vie dont l'informatique a besoin. Il comprend:
- Les portefeuilles d'applications et de technologies qui suivent la version utilisée pour leurs composants, bien que sans gestion efficace de la devise des versions, la « version utilisée » serait des « versions utilisées ».
- Pour chaque composant, la mise à jour de version annoncée par le fournisseur et les calendriers de non prise en charge.
- Calendriers et budgets de projet dérivés de manière algorithmique pour la mise à jour des composants vers les versions actuelles.
- Examen des alternatives, pour s'assurer que Update est la disposition optimale, plutôt que de remplacer le composant par une alternative fonctionnellement équivalente mais globalement supérieure.
- Principes et politiques d'architecture technique pour maintenir les composants à jour, examinés et approuvés au niveau de l'équipe de direction ou du conseil d'administration, de sorte que le service informatique ne doit mener cette bataille budgétaire qu'une seule fois.
Pièges
La gestion des devises de version n'est pas particulièrement compliquée dans son concept. Mais il y a quelques barrages routiers auxquels se préparer.
Avant tout, lorsque vous mettez à jour une plate-forme, vous devez savoir où les effets d'entraînement se produiront. Il est rare qu'une mise à jour soit parfaitement rétrocompatible avec la version précédente.
Cela signifie également s'assurer que votre équipe d'assurance qualité logicielle maintient à jour ses tests de régression automatisés.
Deuxièmement, la mise à jour d'une application vers sa version actuelle peut parfois nécessiter la mise à jour de certaines des plates-formes sur lesquelles elle s'appuie. Ce qui signifie revenir aux pièges de la mise à jour de la plate-forme.
Et troisièmement, en particulier pour la gestion des devises de la version de la couche application, la mise à l'échelle soulève sa tête laide.
Avec des centaines – et, dans certains portefeuilles, des milliers – d'applications en production, il est difficile de maintenir à jour la base de données des calendriers de mise à jour des versions des fournisseurs dans le système de gestion de l'architecture technique. Face à l'ampleur de ce défi, de nombreuses boutiques informatiques abandonnent et s'en vont jusqu'à ce que l'obsolescence d'une version d'un composant se traduise par une crise. C'est une décision épouvantable, car lorsque vous donnez suffisamment de coups de pied sur la route, vous finissez par manquer de route.
Non, la gestion des devises des versions de la couche application est aussi essentielle que laborieuse. Ce qui fonctionne le mieux – peut-être que "le moins pire" est plus précis – est de diviser pour mieux régner, en s'assurant que chaque application du portefeuille a un responsable de produit informatique qui est responsable de la santé, des soins et de l'alimentation des applications qui leur sont assignées. Cela inclut la tenue à jour d'une base de données des plans de version des fournisseurs.
Comprenez, la gestion des devises de version ne couvrira pas ses praticiens de gloire. La plupart du temps, ils seront traités comme tous les porteurs de mauvaises nouvelles.
La bonne nouvelle à propos des mauvaises nouvelles est que porter ces mauvaises nouvelles vaut mieux que les mauvaises nouvelles que vous porteriez si vous ne le faisiez pas.
Source link