Comprendre la portée des systèmes hérités dans l'infrastructure de génie

Les systèmes hérités sont les fondements technologiques sur lesquels de nombreuses organisations d'ingénierie ont bâti leurs opérations.Ces systèmes comprennent souvent des plates-formes matérielles, des applications logicielles, des bases de données et des intégrations personnalisées qui sont en service depuis des décennies. Bien qu'ils puissent encore fonctionner correctement, ils présentent des défis importants : coûts élevés de maintenance, vulnérabilités en matière de sécurité, modulabilité limitée et difficulté à s'intégrer aux outils modernes.

Les équipes d'infrastructure en génie héritent souvent de ces systèmes par le biais d'acquisitions, de croissance organique ou simplement parce que « s'il n'est pas cassé, ne pas les réparer ». Cependant, le coût de l'inaction peut s'accumuler. Une enquête Gartner de 2023 a révélé que 70 % des organisations comptent encore sur des applications existantes pour des processus opérationnels critiques, mais que ces mêmes systèmes représentent une part disproportionnée des budgets de TI et des incidents de sécurité.

Un cadre stratégique pour la gestion du système hérité

Réalisation d'un inventaire et d'une vérification complets

La première étape de toute initiative de gestion du patrimoine consiste à dresser un inventaire complet et précis de tous les systèmes, applications et dépendances.Cette vérification devrait aller au-delà d'une simple liste – elle doit saisir les détails techniques : systèmes d'exploitation, versions de bases de données, langages de programmation, bibliothèques tierces, interfaces réseau et points d'intégration.

Utilisez des outils de découverte automatisés pour analyser le réseau pour trouver des logiciels et du matériel obsolètes. Cependant, la vérification manuelle est toujours essentielle pour les systèmes de niche ou les systèmes sur mesure.

Pour une approche structurée, veuillez consulter le Cadre NIST pour l'évaluation des systèmes existants[, qui fournit des lignes directrices pour l'évaluation des risques et de l'interopérabilité.

Établissement de priorités en fonction du risque et de la valeur opérationnelle

Une matrice de hiérarchisation qui évalue chaque système par rapport à deux axes — la criticité opérationnelle et le risque technique — aide à répartir judicieusement les ressources. Les systèmes à haut risque et à haute critique devraient être les principaux candidats à une modernisation immédiate. Les systèmes à faible criticité et à faible risque peuvent être maintenus avec un minimum de maintenance.

Les facteurs à prendre en considération dans les systèmes de classement comprennent :

  • Vulnérabilités de sécurité: Les systèmes avec des CVE connus et aucun correctif de fournisseur ne devraient être hautement prioritaires.
  • Exigences de conformité:[ Les systèmes qui gèrent les données réglementées (PCI-DSS, HIPAA, GDPR) doivent satisfaire aux normes actuelles.
  • Coûts d'entretien:[ Suivre à la fois les coûts directs de licence et les coûts de main-d'oeuvre pour maintenir le système opérationnel.
  • La complexité de l'intégration:[ Les systèmes avec de nombreuses interfaces sans papiers ou protocoles propriétaires augmentent le risque.
  • Disponibilité du personnel qualifié:[ Si l'expertise est rare, ces systèmes deviennent plus difficiles à entretenir.

Documenter les raisons de chaque décision de priorisation. Cette transparence permet d'obtenir l'adhésion des cadres et d'éviter l'apparition de choix arbitraires.

Établir une analyse de rentabilisation pour la modernisation

La modernisation des acquis concurrence souvent le financement de nouveaux projets de développement de fonctionnalités ou d'autres projets d'infrastructure. Une analyse de rentabilisation convaincante doit expliquer à la fois les coûts de l'inaction et les avantages de l'action.

Inclure une analyse coûts-avantages qui couvre :

  • Coûts annuels actuels[ (licence, maintenance du matériel, contrats de soutien, temps de travail du personnel pour les travaux manuels).
  • Coûts futurs prévus en supposant qu'aucune mesure n'est prise (y compris des amendes éventuelles pour atteinte à la sécurité ou pour défaillances d'audit).
  • Coûts de modernisation[ (effort de migration ponctuel, nouvelles licences, formation, chevauchements de la période de transition).
  • Coûts annuels après modernisation[ (généralement inférieurs, mais qui doivent être réalistes).

Présenter le cas en termes de résultats opérationnels, et non de mesures techniques. Par exemple, « réduire le temps de traitement par lots de 8 heures à 30 minutes permet d'analyser les données de production de la même journée ».

Approches et modèles de modernisation

Il n'existe pas de stratégie unique qui soit adaptée à tous. La bonne approche dépend de l'âge, de l'architecture, de la fonction opérationnelle du système et de la tolérance au risque de l'organisation.

Encapsulation et le motif de la Fig Strangler

Le modèle de figuier, popularisé par Martin Fowler, permet de remplacer progressivement la fonctionnalité d'un système existant sans une coupe de big-bang. Commencez par construire un nouveau système à côté de l'ancien. Comme de nouvelles fonctionnalités sont ajoutées au nouveau système, le trafic est acheminé loin des modules existants. Avec le temps, le système hérité est «étrangled» et peut être déclassé.

Ce modèle réduit les risques car chaque incrément de remplacement peut être testé et repoussé si nécessaire. Il permet également aux équipes d'apprendre des erreurs sans affecter l'application entière. Cependant, il nécessite une gestion soigneuse du routage et de l'état entre les anciens et les nouveaux composants.

Pour plus de détails, voir la description du motif original sur Le blog de Martin Fowler.

Réhébergement (Lift et Shift) vers le Cloud

Lorsque l'application existante est trop monolithique ou étroitement couplée pour être réactualisée, la réhébergement vers une infrastructure cloud peut apporter des avantages immédiats : une gestion matérielle réduite, des options améliorées de récupération après sinistre et des coûts énergétiques réduits.

Bien que la réorganisation ne résolve pas la dette technique architecturale, elle peut gagner du temps pour une modernisation plus approfondie plus tard. Elle permet également l'auto-échelle et la surveillance des capacités qui n'ont peut-être pas été disponibles sur place.

  • Compatibilité de licence:[ Certaines licences de logiciels existantes interdisent le déploiement de cloud.
  • Résidence des données: S'assurer que la région nuageuse satisfait aux exigences réglementaires.
  • Tayonnage de performance:[ La virtualisation peut introduire la latence si elle n'est pas configurée correctement.

Réactualisation et réarchivage

Pour les systèmes qui sont stratégiquesment importants mais techniquement dépassés, un retravail important peut être justifié. La refactoration implique des changements de code interne pour améliorer la maintenance, la sécurité et la performance sans changer de comportement externe. La re-architecture va plus loin: casser un monolithe en microservices, adopter de nouveaux modèles comme l'architecture axée sur les événements, ou remplacer des composants propriétaires par des solutions de rechange open-source.

Il s'agit de l'approche à risque le plus élevé, mais potentiellement la plus récompensante. Elle nécessite une expertise approfondie du domaine, une couverture de test approfondie et une gouvernance architecturale solide. Commencez par les parties les plus volatiles ou les plus encerclées du système. Utilisez des toggles pour remplacer progressivement les fonctionnalités.

Remplacer les solutions hors-la-sol

Certains systèmes existants ont des fonctionnalités bien définies qui peuvent être remplies par des logiciels commerciaux ou open-source. Par exemple, remplacer un ERP personnalisé par SAP ou remplacer une base de données de gestion de configuration maison par ServiceNow. Cette approche peut réduire les charges de maintenance à long terme mais introduit la dépendance des fournisseurs externes. Évaluer des facteurs comme le coût total de propriété sur 3-5 ans, la complexité de la migration des données et la flexibilité pour les futures personnalisations.

Une approche hybride est également courante : envelopper le système d'origine avec une API ou une interface utilisateur moderne tout en remplaçant progressivement les composants back-end. Cela donne aux utilisateurs une expérience moderne tandis que le remplacement sous-jacent se déroule de manière transparente.

Gestion des ressources pour les systèmes hérités

Affectation budgétaire et gestion des coûts

Les systèmes hérités consomment des ressources qui pourraient être consacrées à l'innovation.Une ligne budgétaire dédiée à l'entretien et à la modernisation des anciens permet d'éviter que ces coûts ne se cachent dans les dépenses générales de fonctionnement.

Les mesures de suivi, telles que Coût par transaction et [ Temps de déploiement[ pour les systèmes existants par rapport aux équivalents modernes.Ces mesures permettent de justifier des investissements de modernisation.

Dotation et maintien des compétences

Les ingénieurs qualifiés pour les technologies héritées (COBOL, AS/400, Fortran, etc.) sont de plus en plus rares et coûteux. Créer des incitatifs de rétention pour le personnel expérimenté qui possède des connaissances institutionnelles.

Envisager d'utiliser des spécialistes des zones côtières ou extracôtières pour l'entretien des anciens si les talents locaux ne sont pas disponibles.

Documentation et transfert des connaissances

Les connaissances institutionnelles n'existent souvent que dans l'esprit des employés de longue durée ou dans des fichiers de documents périmés. Documenter systématiquement : diagrammes d'architecture, procédures de déploiement, guides de résolution d'erreurs, schémas de données, règles d'affaires et solutions de rechange connues.

Organiser régulièrement des séances de brown-bag où les experts du système historique expliquent pourquoi certaines décisions de conception. Enregistrer ces séances pour référence future. Favoriser une culture où le partage des connaissances est reconnu et récompensé.

Gestion des fournisseurs et des licences

De nombreux systèmes existants dépendent de composants logiciels tiers qui ne sont plus pris en charge. Identifier toutes les dépendances tierces et évaluer leur statut de licence. Planifier pour les remplacements ou négocier des accords de soutien étendu avec les fournisseurs si le logiciel est critique. Surveiller les dates de fin de vie des systèmes d'exploitation, des bases de données et des middlewares – la conscience est la première défense contre les systèmes non soutenus.

Utiliser un outil de gestion des biens logiciels (SAM) pour suivre les licences et l'utilisation. La sur-licence est un gaspillage courant; la sous-licence peut entraîner des pénalités de conformité.

Risque et considérations de conformité

Vulnérabilités de sécurité

Les systèmes hérités sont des cibles principales pour les attaquants parce qu'ils ne disposent souvent pas de contrôles de sécurité modernes, ni de cryptage, ni de codes d'identification, ni de protocoles d'authentification périmés, ni de gestion des correctifs. Effectuer régulièrement des analyses de vulnérabilité et des tests de pénétration sur les systèmes hérités.

Élaborer un plan d'intervention en cas d'incident de sécurité qui traite spécifiquement des systèmes existants.

Conformité réglementaire

Les règlements de l'industrie (SOX, NERC CIP, RGPD, FDA 21 CFR Partie 11) imposent souvent des exigences que les systèmes existants n'ont jamais été conçus pour satisfaire.

Continuité des activités et reprise après sinistre

Les systèmes hérités peuvent dépendre de méthodes de sauvegarde ou de matériel dépassés, difficiles à remplacer dans un scénario de catastrophe. Tester régulièrement les plans de reprise après sinistre des systèmes hérités. Si le système ne peut pas être facilement restauré, envisager de le virtualiser en un format qui peut être réhésié dans un site de récupération.

Intégration et migration des données

Qualité des données et nettoyage

Avant de migrer les données vers un nouveau système, investir dans le profilage et le nettoyage des données. Utilisez des pipelines ETL (extract, transform, charge) avec des règles de validation. Documentez la lignage des données et la logique de transformation pour maintenir les pistes de vérification. La migration des données est souvent la tâche la plus sous-estimée dans les projets de modernisation.

Les défis de l'intégration avec les systèmes modernes

Les systèmes modernes préfèrent les API REST, les courtiers de messages ou les flux d'événements. Construisez une couche d'intégration ( passerelle ESB ou API) pour traduire entre les anciens et les nouveaux paradigmes. Envisagez d'utiliser la capture de données de changement (CDC) pour la synchronisation en temps réel des bases de données existantes vers les flux d'événements modernes. Cela permet une migration progressive sans casser les intégrations existantes.

Établir des objectifs stricts de niveau de service (ALS) pour le pont d'intégration – latence, débit, taux d'erreur – afin que toute dégradation soit visible avant qu'elle n'affecte les processus opérationnels.

Essais et assurance de la qualité dans les environnements hérités

Les systèmes existants sont difficiles à tester parce qu'ils manquent souvent de tests automatisés, qu'ils ont des dépendances fragiles et qu'ils produisent des résultats incohérents. Investir dans la création d'une suite de tests de régression qui couvre les flux commerciaux critiques.

Pour les projets de modernisation, utilisez une méthodologie à exécution parallèle : exécuter simultanément les systèmes anciens et nouveaux et comparer les extrants.Les disparités doivent être étudiées avant la réduction des coûts.

Configurez un environnement de mise en scène qui reflète la production le plus fidèlement possible, y compris le même matériel, la même version OS et des composants tiers.

La face humaine : gestion du changement et communication

Les utilisateurs du système hérité ont souvent une confiance profonde dans le système existant, même s'il est maladroit. Ils peuvent résister au changement parce qu'ils savent les solutions de rechange et craignent de perdre la productivité pendant la transition.

  • Impliquer les utilisateurs tôt dans la conception et l'essai de nouveaux systèmes.
  • Communiquez clairement la justification du changement – en mettant l'accent sur la façon dont il facilite leur vie, et non seulement sur les avantages de la TI.
  • Fournir une formation pratique bien avant la coupe. Créer des environnements de bac à sable pour la pratique.
  • Avoir un plan de recul et de le communiquer. Savoir qu'il y a un filet de sécurité réduit l'anxiété.
  • Célébrez les étapes et reconnaissez les contributions des experts du système qui aident à la transition.

La résistance est souvent le symptôme d'une formation inadéquate ou d'une mauvaise communication, et elle est traitée avec empathie et transparence.

Conclusion

La gestion des systèmes et des ressources hérités de l'infrastructure de génie n'est pas un signe d'échec, c'est une réalité d'environnements technologiques de longue durée. Les organisations les plus efficaces considèrent la gestion de l'héritage comme une discipline stratégique, et non comme une corvée lourde.

Le parcours de l'héritage à la modernité est rarement linéaire, mais avec une approche progressive, conscient des risques, il est possible de transformer les parties les plus anciennes de votre infrastructure en actifs qui soutiennent la croissance future. Que vous choisissiez l'encapsulation, la réorganisation, la refacturation ou le remplacement, les principes restent : savoir ce que vous avez, justifier chaque décision avec des données, et ne jamais sous-estimer la valeur des personnes qui maintiennent ces systèmes en marche chaque jour.