Services
Formation virtuelle IBM i
Découvrirez comment démarrer avec Watson sur IBM i aujourd'hui
En savoir plusSoutien technique
Une réalité ironique persiste : les entreprises de TI, dirigées par des gens qui construisent d’excellents logiciels d’affaires pour la gestion des actifs et de l’inventaire, négligent si souvent d’utiliser ce même concept de gestion de l’inventaire lorsqu’ils gèrent leurs propres actifs logiciels.
Devant leurs projets de modernization imminents et les risques d’exode des compétences liés à la retraite et à l’attrition, un nombre grandissant de sites de développement IBM i se tournent vers des données d’analyse poussées pour comprendre leur base de code et mieux gérer leurs ressources de développement.
Malheureusement, beaucoup d’organisations qui continuent de dépendre d’IBM i ne savent pas exactement quelle quantité de leur base de code est toujours pertinente, non plus qu’ils ne sont conscients de la complexité de toute portion de cette base, des règles d’affaires qu’elle met en place, du modèle relationnel ou de toute autre mesure qui correspond à un processus de gestion structuré.
Il n’est pas rare que les dirigeants des TI travaillant au sein d’entreprises valant des milliards de dollars ne soient pas pleinement conscients de la quantité de code dont ils sont responsables ou de la désuétude de leurs processus de gestion du développement.
Lors d’une récente rencontre d’un groupe de super-utilisateurs, un gestionnaire de TI chevronné avec beaucoup d’ancienneté avouait qu’il était responsable de « milliers » de programmes, mais qu’il ne savait pas exactement quelle était la taille de la base du code, ni quelle quantité de ce code était redondante. En outre, il ne possédait aucune information explicite quant à la conception du système au-delà de ce qui avait été écrit il y a 20 ans, lors de la construction initiale du système.
Cependant, il est tout aussi révélateur (et satisfaisant) de voir l’expression d’étonnement et de fascination qu’affichent les gens lorsqu’un système sur lequel ils travaillent depuis une trentaine d’années est enfin quantifié, mesuré et présenté devant leurs yeux pour la première fois. À tout coup, cette vue d’ensemble offre une nouvelle approche hautement efficace pour travailler ainsi que pour gérer les systèmes de TI et processus de développement.
Un des principaux livrables d’un projet de visualisation du code est une liste détaillée des problèmes logiciels. Cette liste peut comprendre les disparités entre les logiciels et objets, le code source manquant, les programmes, fichiers, chemins d’accès et le code inutilisés ainsi que différentes constructions héritées, telles que les instructions GOTO, les fichiers décrits en interne et les fichiers à formats multiples.
L’émerveillement qui résulte au départ de cette vue d’ensemble du système se transforme rapidement en surprise et en malaise, à mesure que l’envergure de ces problèmes est révélée. Toutefois, ces désagréments ne tarderont pas à se traduire en plan d’action proactif pour corriger ou éliminer les problèmes touchant les parties du portefeuille des applications qui sont essentielles à la mission de l’entreprise.
Comprendre la portée des projets de modernization et des tâches de maintenance générales ou spécifiques. Établir des coûts et une planification efficaces. Voilà des stratégies dont dépendent la réussite ou l’échec de la carrière d’un gestionnaire des TI. Sans compter que la plateforme elle-même est souvent montrée du doigt lorsque la planification est faite à l’aveuglette. « Ah! C’est encore à cause de cette plateforme désuète! On ne réussit jamais à mettre en place des améliorations à temps! » Toute personne connaissant le développement avec SYNON ou le générateur automatique de programmes (GAP, ou RPG) sur IBM i répliquera qu’il s’agit probablement du kit de développement le plus productif qui soit pour les applications d’affaires.
Certains services informatiques reposant sur IBM i utilisent des références croisées de base et une forme quelconque de SCM (« Source Change Management ») pour aider à gérer le développement. Une idée répandue est que SCM peut aider à effectuer le contrôle des stocks d’actifs logiciels. C’est faux. SCM permet de gérer des actifs précis à des fins particulières à un moment donné, mais ne fournit aucune donnée de gestion concrète sur le système entier, soit avant ou après un changement ou une série de changements.
À l’opposé, Rational Team Concert (RTC) d’IBM offre un excellent portefeuille de fonctionnalités et de modules qui aident à gérer des projets de développement majeurs et complexes impliquant un grand nombre de développeurs et d’intervenants. RTC s’avère une solution formidable lorsqu’un service de TI doit développer une nouvelle base de code, en faisant appel à plusieurs équipes travaillant de différents emplacements.
Toutefois, les projets de modernization et de développement IBM i ne correspondent pas à ce modèle. Dans ces scénarios, de petites équipes sont mobilisées pour maintenir ou moderniser de très grandes bases de code qui existent déjà. L’utilisation de RTC dans une telle situation pourrait en fait décourager les développeurs IBM i. Qui plus est, le soutien offert au sein de RTC est très restreint pour l’analyse en profondeur du code d’applications IBM i en RPG/SYNON.
Les gestionnaires des TI se tournent de plus en plus vers l’analyse du code pour améliorer la visibilité de leurs systèmes. Des outils tels que X-Analysis s’avèrent indispensables pour quantifier votre base de code, gérer la taille et la qualité de celle-ci, évaluer le risque de maintenir et moderniser les bases de code héritées et améliorer la qualité du développement. En analysant la base de code un niveau au-dessus de sa syntaxe et en utilisant différents diagrammes interactifs ainsi que du pseudo-code au lieu de RPG, les développeurs non spécialisés en IBM i et autres intervenants sont exposés à la valeur et à la conception éprouvées des applications héritées IBM i. La plupart des outils d’analyse s’intègrent aux outils SCM, de sorte que les décisions clés résultant de l’analyse sont mises en place de manière structurée et méthodique.
Vu la diminution des ressources RPG disponibles sur le marché, la hausse des coûts de maintenance, la croissance incessante des bases de code et la diversification des technologies et compétences, nous arrivons à un tournant qui mènera vers une approche plus scientifique et mesurable du développement et de la modernization d’IBM i. Que les entreprises souhaitent moderniser ou simplement maintenir les systèmes IBM i sur lesquels leurs affaires reposent actuellement, l’analyse structurée du code améliorera leur compréhension de la base du code. Ainsi, elles acquerront une compréhension approfondie de leurs affaires et un plan stratégique clair pour l’avenir.
