Aventures dans la rationalisation des applications Partie 4 – Rationalisation et approches

Préface

La rationalisation des applications est un aspect crucial du cycle de vie des affaires et des TI, et un sujet que nous avons déjà abordé.

Ferroque Systems s’est associé à Stephen O’Grady; un collègue de confiance pour notre équipe, expert en rationalisation d’applications et vétéran de la gestion informatique du Royaume-Uni pour une série d’articles invités. Ces articles traitent de la rationalisation des applications et de son importance pour l’organisation moderne. 

Articles de la série :

• Partie 1 – Fragmentation
• Partie 2 – Résistance au changement
• Partie 3 – Réorganisations, fusions et acquisitions et migrations

Dans le billet précédent (Partie 3) de cette série, nous avons examiné les pièges courants de la fragmentation qui peuvent être causés par les réorganisations et les fusions et acquisitions, et présenté quelques éléments de base qui pourraient aider à atténuer ces écueils. Dans cet article, nous allons examiner quelques approches pour gérer la fragmentation, ainsi que les avantages et les inconvénients sérieux de la conteneurisation des applications.

Comment devrions-nous livrer nos résultats dans ce nouveau monde courageux?

Probablement, les trois principales façons d’offrir des fonctionnalités au bureau de l’utilisateur dans le monde moderne sont l’installation de bureau, les environnements virtualisés et les applications livrées directement via une interface Web.

Il existe bien sûr des versions nuancées des interfaces Web, et on pourrait débattre de la place du logiciel en tant que service, de la plateforme en tant que service ou de l’infrastructure en tant que service dans ces définitions, et en quoi ils sont similaires ou différents en termes de fourniture de fonctionnalités aux utilisateurs, mais la façon dont un utilisateur accéde à cette fonctionnalité me semble se résumer aux trois façons décrites ci-dessus.

À ce stade, je vais de nouveau soulever l’idée que les environnements virtualisés et les applications livrées sur le web peuvent être considérés comme remarquablement similaires à l’époque des mainframes, où les applications étaient construites et installées de façon centralisée et où les utilisateurs se connectaient à distance. Bien que l’expérience utilisateur (UX) puisse être très différente, car on a souvent l’impression qu’ils utilisent une application locale ou simplement un site web, les mécanismes de contrôle ressemblent beaucoup plus à l’approche « à l’ancienne ».

En termes de rationalisation de l’application, l’une des trois approches ci-dessus est une possibilité, chacune avec des avantages et des inconvénients différents. Cependant, le point clé demeure la validité de l’application.

Quelle que soit l’approche adoptée, pour maintenir l’utilisabilité, la conformité et la supportabilité, une version actuelle ou presque actuelle de chaque application devrait être utilisée. Cela maximise la supportabilité, offre une plus grande probabilité d’une bonne interopérabilité (permettant les premiers gremlins, qui devraient être identifiés et résolus lors des tests avant de livrer aux utilisateurs réels), et c’est crucial pour donner le contrôle technique aux professionnels informatiques qui pourront s’assurer que les résultats sont prévus.

L’élément clé ici n’est pas la plateforme ou le modèle utilisé pour la livraison; c’est plutôt la cohérence, la monnaie et le niveau d’intégration requis. Ce n’est qu’en assurant une bonne intégration que la qualité de livraison nécessaire au niveau de l’entreprise sera réellement assurée. Pour qu’une entreprise fonctionne de façon optimale, en termes TI, il s’ensuit que l’intégration optimale entre les applications connexes est permise.

Cela ne présuppose pas une technologie particulière, une dépendance à un seul fournisseur, ni même une dépendance à une seule solution pour une exigence donnée (sous réserve des contraintes de coût, comme je l’ai déjà expliqué ailleurs).

Ce que cela signifie, c’est que lorsque les applications sont sélectionnées, elles doivent être supportables et s’intégrer ou interagir correctement avec d’autres applications de l’entreprise. Il est acquis que la chose la plus importante est que les applications répondent aux besoins des utilisateurs, mais si les applications ne font que cela, ne peuvent pas être supportées sur toute leur durée de vie et ne s’intègrent pas comme nécessaire avec d’autres systèmes, elles ne fonctionneront jamais bien au sens de l’entreprise.

Sur ce point, il est aussi important que le résultat soit une solution globale de meilleure qualité, qui fonctionne ensemble de façon intégrée, plutôt qu’un ensemble d’applications de pointe qui fonctionnent parfaitement isolément mais qui n’offrent pas un ensemble bien intégré de fonctionnalités de bout en bout. Un exemple pourrait être un ensemble d’outils de rapports ou de surveillance, pour les affaires ou la technologie, chacun étant le meilleur disponible, mais qui, pris ensemble, ne fournissait pas une surveillance complète de bout en bout en raison des failles et des chevauchements résultant d’une mauvaise intégration et couverture.

Comme je l’ai dit ailleurs, la rationalisation au moment de la migration n’a pas à être vue comme une mauvaise chose, ni même comme un défi majeur; cependant, il est impératif qu’elle soit correctement planifiée et exécutée.

Certains d’entre vous se souviennent peut-être de l’époque de la gestion de la qualité totale, et du slogan « La qualité est gratuite ». Le point soulevé, c’est que la qualité est gratuite en termes de profit, et devrait même l’améliorer, cependant, il faut investir dans la qualité pour en récolter les fruits, ce n’est pas juste un cadeau.

La rationalisation pendant la migration est dans le même cas : il faut investir dans une planification et une exécution appropriées pour en récolter les fruits. Cela peut être une façon très efficace de rationaliser le paysage applicatif, de passer des applications héritées aux applications actuelles, et de balayer les applications anciennes et difficiles à entretenir. Cependant, si c’est mal fait, presque comme une pensée après coup, cela ne fera qu’engendrer un monde de douleur et de frustration tant pour les entreprises que pour les TI, qui peinent à apporter des changements à la fois aux processus et à la technologie à la volée, sans aucune idée des efforts ou des ressources nécessaires.

Encore une fois, la communication est essentielle et, pour informer le plan, il faut un inventaire complet des applications, des propriétaires et des utilisateurs, et le plan de rationalisation et de migration doit tenir compte de chaque exigence fonctionnelle et de chaque donnée, ainsi que de tous les facteurs humains tels que l’obtention et le transfert des connaissances, Et bien sûr, l’entraînement.

La conteneurisation comme solution

La conteneurisation est souvent perçue comme une réponse à la demande d’une solution au problème de maintenance des applications.

Pour ceux qui ne connaissent pas la technologie, en termes très simples, un conteneur dans ce sens est une bulle dans laquelle vous pouvez installer une application. En ce qui concerne cette application, elle est dans un environnement hérité avec tous les anciens gadgets, mais la bulle réside en réalité sur une plateforme moderne et gère les interactions entre les applications à l’intérieur du conteneur et la plateforme à l’extérieur de la bulle.

Cette forme de conteneurisation se distingue de la virtualisation d’applications utilisant des outils comme App-V ou MSIX, qui sont une approche standard de livraison d’applications, mais utilise plutôt des outils spécifiquement conçus pour permettre la préservation des applications héritées et les faire fonctionner sur des plateformes modernes, plutôt que de traiter les faiblesses de versions légèrement différentes des plateformes actuelles ou quasi-actuelles.

Il faut aussi noter que la conteneurisation peut avoir un coût en termes de performance, car il se passe tellement de choses entre l’application, le conteneur et la plateforme que la performance en souffrira. Il est vrai qu’on peut déployer plus de ressources machine pour résoudre ce problème, mais cela renforce l’argument que plus de ressources seront nécessaires, dans ce cas, plus que pour une application à jour fonctionnant sur un environnement à jour.

Néanmoins, la conteneurisation semble souvent être une bonne option. Après tout, stationner une application héritée dans un conteneur règle le problème d’une application qui ne fonctionnera pas sur une nouvelle plateforme; Cependant, cette approche présente plusieurs inconvénients.

Premièrement, cela ne fait que déplacer le problème : au lieu que l’application doive maintenant fonctionner avec cette plateforme « evergreen » à jour et en constante évolution, le conteneur doit maintenant le faire. Certes, le fournisseur de contenants va s’en assurer, mais peut-on vraiment compter sur cette solution pour toujours?

Deuxièmement, et plus important à mon avis, cela renforce le comportement de ne pas maintenir la monnaie dans les systèmes, et de rendre la vie de tout le monde plus difficile. Cela s’explique par le fait que la divergence entre l’application dans « l’ancien monde » à l’intérieur de la bulle et la nouvelle plateforme à l’extérieur de la bulle augmentera simplement avec le temps, rendant le support du conteneur de plus en plus difficile.

Les fournisseurs et fournisseurs de conteneurisation ne sont généralement pas des institutions caritatives, et ils chercheront à tirer profit de cette approche. Inévitablement, plus l’entretien devient difficile et plus il dure longtemps, plus vous paierez cher. Il est aussi presque certain qu’à un moment donné, que ce soit bientôt ou dans quelques années, cette approche cessera de fonctionner pour un cas donné. Cela s’explique par le fait que les transferts entre l’application, le conteneur et la plateforme ne peuvent plus être facilement maintenus, car ces composants se seraient trop éloignés.

À ce stade, la migration sera probablement plus pénible qu’auparavant, car l’option d’exploiter les outils de migration fournis par le fournisseur, pour soutenir le passage entre applications ou versions, aura probablement disparu. Dans ce cas-ci, vous aurez affaire à la migration personnalisée et à tous ses coûts et risques inhérents.

Alors, qu’est-ce que cela signifie? Quelle est la meilleure approche?

Il n’existe, bien sûr, pas de meilleure façon unique d’aborder et d’offrir une rationalisation. Beaucoup de facteurs entreront en jeu, comme l’état des systèmes hérités, l’état de l’infrastructure physique, le paysage des affaires et sa stabilité (c’est-à-dire s’il est en état stable ou en état de changement dû à une forme de réorganisation).

Cela dit, il y a quelques notions de base qu’il faut toujours garder en tête.

Comme d’habitude, la communication est essentielle (et je sais que je le répète tout le temps, mais c’est le point le plus important et je vais continuer à le renforcer). Les exigences d’affaires doivent être comprises par les TI, et les TI doivent faire entendre leur voix en termes d’art du possible.

La rationalisation, c’est exactement cela. Selon Lexico.com, la définition de rationalisation est « l’action de rendre une entreprise, un processus ou une industrie plus efficace, notamment en se débarrassant du personnel ou de l’équipement superflu » ou « l’action de réorganiser un processus ou un système afin de le rendre plus logique et cohérent ». Nous pardonnerons l’utilisation de « matériel » qui ignore ainsi notre monde « doux » moderne, mais l’intention est claire. La rationalisation, selon nos termes, consiste à augmenter l’efficacité en se débarrassant des applications superflues ou redondantes. Cela ne veut pas dire qu’on se réduit à un noyau minuscule et qu’on abandonne les applications nécessaires en cours de route, car cela ne favorise pas l’efficacité. Cela ne signifie pas non plus s’accrocher à des applications dépassées et difficiles à entretenir lorsque des alternatives modernes existent, car cela est aussi inefficace. Ce que cela signifie, c’est que nous devrions avoir une feuille de route convergente pour les applications que, au fil du temps (qui peut être court), nous décomposons en un ensemble central d’applications, à l’exception nécessaire pour des cas vraiment particuliers, qui sont contrôlés centralement conjointement par l’entreprise et les TI et sont maintenus sous contrôle constant pour rester à jour. Même lorsqu’il y a des exceptions, par exemple une petite application offrant une fonctionnalité critique qui ne sert qu’un ou deux utilisateurs, le coût continu de la maintenance, et même la maintenabilité à long terme, doivent être équilibrés avec le coût du changement pour déplacer cette petite exigence pour ces quelques utilisateurs vers un autre type commun, plateforme maintenable. Il est très rare qu’une exigence soit si unique qu’elle ne puisse pas être traitée de cette façon, mais il faut l’admettre, cela peut arriver; Ce n’est pas un monde parfait, après tout.

Le contrôle centralisé est important. Cela ne signifie pas nécessairement que toutes les TI sont contrôlées absolument au même endroit, ni que l’entreprise ne peut pas avoir son mot à dire sur ses applications, mais cela signifie que tout doit s’inscrire dans un cadre architectural convenu afin qu’il y ait un seul « esprit guide » pour toutes les décisions TI. Cela signifie aussi que les applications achetées et installées localement ne devraient généralement pas avoir leur place en TI d’entreprise, car cela rend impossible d’assurer les niveaux d’intégration et de soutien nécessaires, ainsi que la maintenabilité continue requise.

La conteneurisation simplement pour préserver les applications héritées n’est pas une bonne idée. Elle a ses utilités, et dans certains cas peut être la seule alternative, mais ne devrait jamais être vue autrement que comme une solution à court terme, et vraiment, ne devrait être autorisée que dans le cadre d’un plan à plus long terme qui mènera au remplacement de l’application héritée dès que possible (ce qui, il faut l’admettre, ne sera peut-être pas si tôt).

Et juste pour recommencer, toute cette approche centralisée de la gouvernance et de la maintenance TI sera parfaitement familière aux praticiens plus âgés comme moi, qui se souviendront qu’à l’époque des mainframes, c’était beaucoup moins difficile car l’informatique avait vraiment le contrôle. Le passage aux applications virtualisées et basées sur le web nous pousse encore une fois dans cette direction, ce qui ne peut être qu’une bonne chose puisqu’il permet une meilleure gouvernance et un meilleur contrôle, ainsi qu’une diminution des déviations incontrôlées, mais cela doit être réalisé en partenariat entre les TI et l’entreprise afin que l’entreprise obtienne ce dont elle a besoin, les TI assurant une livraison efficace.