Que sont les applications héritées ?

Dans le monde de l'informatique, on entend souvent parler de « systèmes hérités ». Le terme fait référence aux systèmes qui sont utilisés dans une organisation depuis des années et qui ne sont donc plus haut de gamme ou récents.

Un système hérité peut être un logiciel ou un matériel, un format de fichier ou un langage de programmation. Compte tenu de cela, a « application héritée » est une application obsolète ou en voie de l'être. application héritée peut créer des problèmes au fil du temps s'il est bogué et difficile à mettre à jour.

S’en tenir à des applications héritées expose une organisation à un risque de catastrophe si l’application perd sa compatibilité avec les systèmes d’exploitation modernes. Cela peut même entraîner des vulnérabilités en matière de sécurité.

Dans cet article de blog, vous découvrirez les étapes à suivre pour moderniser les applications héritées et ce qu’implique ce processus de modernisation.

Pourquoi les systèmes et applications hérités sont-ils une préoccupation ?

Les systèmes hérités incluent des processus et technologies métier critiques, mais obsolètes. Les logiciels mainframe ont commencé à être qualifiés d'« applications héritées » lorsque les PC ont commencé à prendre le contrôle de l'entreprise.

« Applications héritées « Ce sont des choses avec lesquelles les nouveaux enfants ne veulent pas jouer », déclare Gary Baney, directeur du développement chez le fournisseur de services informatiques Groupe de gestion avancée du serveur (ASMGi). « C'est la meilleure définition technique car, en fin de compte, elle définit la durabilité, la maintenabilité et le degré d'enthousiasme technique qui sera présent dans le processus de développement d'applications. »

Les systèmes existants sont limités à leur objectif initial et il n’est généralement pas facile ni rentable de les intégrer à une technologie plus moderne.

« Il existe une relation symbiotique entre le développement commercial et le développement technologique », explique Baney. « Le plus gros inconvénient des applications traditionnelles est que cette relation symbiotique a disparu. »

Pourquoi devriez-vous abandonner vos anciens logiciels ?

« La langue dans laquelle le code est écrit ou l’âge du logiciel importe moins que notre capacité à le maintenir, à le soutenir et à le maintenir », déclare Peter Anderson, directeur technique chez Centre des Systèmes Informatiques (CCSI). « Ce qui entre en jeu, c’est la fin de vie du fabricant et le niveau de risque que nous sommes prêts à prendre. »

Imaginez qu'on puisse aujourd'hui utiliser sur le terrain un ordinateur 8 bits construit en 1969. Trouver des programmeurs est aussi difficile que de trouver des techniciens capables de construire les tubes à vide nécessaires au fonctionnement du système. À l'époque de sa construction, une carte de remplacement coûtait 400 $. Aujourd'hui, elle coûte plus de 70,000 XNUMX $.

« Les personnes qui prennent des décisions technologiques ne sont pas directement concernées par ces décisions », a déclaré Anderson. « Elles considèrent les choses en termes de coûts directs plutôt que de coût total de possession. En même temps, je réfléchis au coût de fabrication d'un tube à vide et de tout tester. L'entretien de l'ancien système est probablement plus coûteux que l'achat d'un nouveau système. »

Le coût n’est pas toujours un obstacle

Bien que le coût de maintenance d’un ancien système puisse indiquer qu’un changement est nécessaire, il est également possible de dépenser plus que nécessaire pour une nouvelle solution.

L'un des clients de Baney était prêt à dépenser 500,000 18 $ sur 10 mois pour remplacer complètement un système de gestion des ressources d'entreprise (ERP) vieux de XNUMX ans. En adoptant une approche plus stratégique de la modernisation de l'ancien système, la même fonctionnalité pourrait être fournie pour moins d'un cinquième du coût et réalisée en moins d'un tiers du temps.

« Le client souhaitait ajouter huit nouveaux types de fonctionnalités. Il suffisait simplement de relier les appareils portables à la base de données ERP existante », explique Baney.

En étendant les capacités de leurs systèmes existants, le projet de modernisation du client comprenait :

• mises à niveau de la base de données et du serveur de production
• l'ajout d'un stockage plus rapide pour améliorer la capacité de traitement de l'ancien système
• une nouvelle interface mobile

« Ils utilisent toujours l'ancienne application et ils ont obtenu tout ce dont ils avaient besoin pour 85,000 XNUMX $ », dit-il.

Qui décide du moment de la modernisation ?

Les décisions de remplacement des applications héritées sont souvent mal prises lorsque les choix technologiques ne sont pas en phase avec les besoins de l'entreprise. Les choix effectués et la manière dont ils sont appliqués peuvent faire la différence entre être en tête ou à la traîne par rapport à la concurrence dans un secteur donné.

En tant que directeur technique du CSCI, Anderson est chargé de faire des recommandations au directeur financier et au PDG. Avant cela, il organise des réunions régulières avec le responsable des opérations système et le responsable du développement système. Ils déterminent ensemble si le matériel est devenu obsolète et si la base actuelle de développeurs est capable d'accéder au code ou de le modifier.

« Si nous arrivons au point où je ne parviens pas à trouver le matériel ou que nous n'avons plus l'expertise nécessaire en matière de développement, nous avons le sentiment désagréable que nous acceptons plus de risques que nous ne le devrions », a déclaré Anderson. « Mon PDG n'aime pas accepter de risques à un moment où les facteurs économiques affectent les petites entreprises. »

Même si les entreprises les plus sophistiquées s'efforcent activement d'améliorer la communication entre les professionnels de l'entreprise et les professionnels de l'informatique, des défis subsistent. De nombreux techniciens ne donnent pas de leur temps à l'unité commerciale parce qu'ils estiment que celle-ci ne les respecte pas suffisamment. Et certaines unités commerciales ne respectent pas les techniciens parce qu'elles estiment qu'ils ne les écoutent pas suffisamment. « Si une culture d'entreprise veut prospérer et rester perpétuellement compétitive, il doit y avoir un fort sentiment de partenariat entre l'unité commerciale et le groupe technologique », explique Baney d'ASMGi.

Gérer le processus de modernisation de l'héritage

Norm Ringgold, ancien responsable des opérations et de l'infrastructure informatiques de Centre d'accélération linéaire de Stanford (SLAC) gère les transitions des applications existantes selon une méthode formalisée de cycle de vie des applications (ALC) de la bibliothèque d'infrastructure informatique (ITIL) qui devient de plus en plus courante dans les moyennes et grandes entreprises. L'idée est qu'un organisme directeur doit prendre des décisions informatiques « éclairées » en fonction de la proposition de valeur commerciale.

Développer de nouvelles solutions commerciales coûte cher. Si une application existante continue de répondre aux besoins de l'entreprise et que la plateforme complète, les licences, le service et le modèle d'assistance présentent une proposition de valeur continue, alors pourquoi changer ?

« En règle générale, je ne suggère pas de modifier une solution applicative à moins qu'un facteur de valeur commerciale ou une urgence technologique ne le justifie », explique Ringgold. « Dans de nombreux cas, le cycle de vie d'une application est déterminé par un événement important, comme une fusion ou une acquisition. »

Par exemple, quand Oracle a acquise Sun Microsystems et a déclaré qu'il fallait mettre fin à la plateforme Sun Solaris, ce qui a créé une urgence technologique qui a nécessité un changement global des applications. Cela a également ouvert la voie à des opportunités de solutions tierces.

L'US Postal Service, où travaillait Ringgold à l'époque, disposait de 2,000 XNUMX serveurs exécutant des applications Solaris. Bien que des événements tels que l'acquisition de Sun ne puissent pas être entièrement anticipés par les clients, il est possible de gérer ce risque et d'autres risques de manière à minimiser les retombées.

Déterminer le retour sur investissement

Lorsqu’un changement est indiqué — que ce soit par les circonstances ou par des frais de maintenance astronomiques — Ringgold étudie au préalable si un meilleur retour sur investissement pourrait être obtenu d’une autre manière.

Si un retour sur investissement plus élevé semble probable, il présente une suggestion à un comité d'examen qui comprend :

• le coût d’une enquête plus détaillée sur les processus opérationnels actuels
• comment l'application fonctionne à ce moment précis
• les options de remplacement, y compris le matériel, les logiciels, les machines virtuelles, les applications, la formation des utilisateurs finaux et les coûts d'utilisation

Il peut présenter un trio de solutions de plusieurs fournisseurs sur lesquelles une décision commerciale peut être prise. « L’entreprise doit disposer de suffisamment d’informations pour choisir la plateforme, l’application, la solution du fournisseur et le coût total de maintenance », explique Ringgold.

« Il y a encore de la place pour un cycle de développement logiciel (SDLC), mais nous parlons d'une manière plus sophistiquée de le gérer. » Le style de stratégie de gestion des applications des responsables informatiques d'aujourd'hui comprend une entité de gouvernance informée (avec des représentants clés de l'entreprise et de la technologie) impliquée dans chaque décision technologique majeure prise. « Le partenariat garantit la fourniture de solutions de valeur, ainsi que le remplacement rapide des solutions héritées moins précieuses », explique Ringgold.

4 étapes pour moderniser les applications existantes

Les transitions de systèmes hérités présentent souvent plusieurs points de friction impliquant les personnes et la technologie. Si disposer d'un organe de gouvernance formel est essentiel dans les grandes organisations, les petites organisations craignent qu'une telle formalité affecte négativement leur agilité.

Les petites entreprises peuvent être réticentes à l'idée de créer un organe de gouvernance. « Je leur rappelle qu'il n'est pas nécessaire d'avoir 20 personnes dans l'entreprise alors que 3 suffisent », explique Ringgold.

Les entreprises peuvent perdre leur temps à essayer de gérer les changements d’application. « La meilleure façon de s’y préparer est de mettre en place un cycle de vie de développement logiciel, une gestion du cycle de vie des applications et un organisme de gouvernance capable de s’adapter changement agile, connecté aux exigences de l'entreprise. »

En ce qui concerne la technologie, Baney suggère une approche en quatre étapes pour éviter les oublis.

1. Assurez-vous que la documentation est complète

Des problèmes surviennent lorsque les logiciels et les systèmes ne sont pas bien documentés ou que la documentation n'est pas tenue à jour. Idéalement, la documentation devrait permettre de déterminer l'état réel de la base de code, de l'architecture, de l'intégration et des API.

2. Déterminer la stabilité de l'application

Baney vérifie les journaux d'erreurs pour déterminer où se trouvent les défauts et les répercussions que ces erreurs peuvent avoir sur l'entreprise. Il se peut que les niveaux de service se détériorent et que la cause principale soit une application particulière.

3. Comprendre les points d’intégration

Cela vous aide à déterminer quelles applications surveillent et communiquent avec d'autres, et quelles interfaces vous devrez reconstruire si quelque chose change.

« Il faut organiser quelques réunions au cours desquelles on dit : « Écoutez, vous devez réécrire ici, mais nous ne voulons pas créer un effet d'entraînement qui vous affecterait », explique Baney. « Il faut étudier en profondeur les interfaces et les API et les comprendre très bien. »

4. Rencontrez l'unité commerciale dans le but de comprendre le flux de travail de l'application

Il se peut que le flux de travail actuel soit le résultat d'une préférence personnelle d'un responsable ou qu'il ait été spécifiquement conçu pour améliorer l'efficacité des processus métier. Expliquez-lui le flux de travail de l'entreprise. Assurez-vous que vous faites les choses correctement ou voyez s'il existe des possibilités d'amélioration.

« S’il y a des possibilités d’amélioration, il faut les associer au retour sur investissement », explique Baney. « Si je peux réduire le temps de traitement des réclamations d’un agent de 20 à 11 minutes, j’ai un impact sur l’expérience client. L’efficacité, la satisfaction client et la précision sont autant de facteurs qui contribuent au retour sur investissement. »

Le changement est inévitable

La manière dont un processus de modernisation du patrimoine est géré peut faire la différence entre rester compétitif ou prendre du retard sur la concurrence.

Quelle que soit la taille de l'entreprise, il doit exister un processus permettant de déterminer les changements à apporter et le moment où ils doivent être apportés. Constituez un groupe de décideurs ayant pour double objectif d'agir dans l'intérêt supérieur de l'entreprise et de minimiser les risques.

Si certains changements peuvent être anticipés (comme la date de fin de vie d'un système d'exploitation), d'autres ne le sont pas. Les entreprises avisées font de la gestion du changement une priorité afin de pouvoir gérer les événements prévus et imprévus de manière à minimiser les risques et les coûts inutiles.