Services
Formation virtuelle IBM i
Découvrirez comment démarrer avec Watson sur IBM i aujourd'hui
En savoir plusSoutien technique
Robert Arce est l’expert en redimensionnement de champs principal chez Fresche Solutions. À son arrivé chez Fresche, il a immédiatement adopté X-Resize, la solution aidant à automatiser les projets de redimensionnement de champs. Il croit fermement en l'efficacité du produit et à son utilité dans tout effort de redimensionnement pour les entreprises IBM i.
Les discussions que Fresche entretient régulièrement avec ses clients et prospects portent sur la nécessité d’élargir les champs de leurs applications et de leurs bases de données IBM i existantes: ils sont très intéressés par les moyens de réduire le temps, l’erreur humaine potentielle et les efforts manuels nécessaires pour mener à compléter une tâche aussi complexe.
R: Je fais partie de l'équipe mondiale de stratèges informatiques, plus précisément d'un groupe de six personnes sélectionnées pour fournir des services de découverte aux clients souhaitant entreprendre un projet de modernisation. Au cours des trois dernières années, j'ai également joué un rôle dans l'équipe de conseil en solutions clients.
J'ai rejoint Fresche en raison de mon expérience avec le système IBM i. J'étais propriétaire d'une entreprise dans ce domaine particulier et j'ai également travaillé pour un cabinet de conseil de 1997 à 2000, qui jouait un rôle important à l'époque. Je suis considéré comme un expert quand il s’agit d’IBM i, et de tout ce qui englobe RPG et SQL également.
En ce qui concerne les bases de données, j'ai non seulement de l'expérience sur IBM i, mais aussi sur d'autres systèmes, tels que Microsoft SQL Server, et j'ai souvent travaillé avec Db2 en termes de modernisation, aussi.
En 1998/1999, j’avais géré cinq projets de conformité à l’an 2000. L'un de ces projets était un énorme effort de redimensionnement de champs pour une société d'assurances et de finances, où j'ai eu l'occasion de gérer 11 personnes uniquement pour ce projet. Il a touché tous les systèmes centraux de la société. Trois étaient des projets de taille moyenne et le dernier était de petite envergure.
R: C’est une excellente question. Cela tient en partie au fait que de nombreuses entreprises ont créé leurs applications il y a 30 ans ou plus, avec jusqu'à cinq ou six caractères pour leur numéro d’identification de client ou de produit, se limitant à des centaines, voire des milliers, d'identifiants. Cette configuration peut fonctionner très longtemps. Cependant, comme nous l’avons vu avec nos propres efforts de redimensionnement, cela peut rapidement devenir un problème, en particulier lors de fusions et d’acquisitions. J'ai travaillé avec un client qui acquérait de nouvelles entreprises 10 à 12 fois par an, dont 2 ou 3 auraient une taille importante avec une liste de produits atteignant rapidement des millions… Personne n'a pensé à cela lors de la conception du système d'origine.
Une autre chose concerne les champs monétaires, un problème souvent associé à l'internationalisation. Par exemple, une entreprise souhaite faire des affaires au Mexique avec des pesos et doit déterminer combien de pesos sont nécessaires pour un dollar. La limite de votre système de quelques milliers de dollars pour un article se transforme en millions de pesos. Lorsque vous effectuez le récapitulatif des détails de la facture, vous pouvez vous rendre compte que votre champ pour le montant total est insuffisant.
La croissance régulière d’une entreprise peut entraîner le même type de problème, car de nombreuses entreprises non seulement se développent par acquisition, mais aussi par croissance organique.
Il y a aussi la question de l'emplacement (nouveau bureau, magasins, etc.). Si une entreprise se porte vraiment bien, elle peut aller de 10 emplacements à près de 100. À ce stade, elle peut avoir presque entièrement utilisé le champ d’emplacement qui est limité à deux caractères.
Le numéro de client, l’identifiant de produit et les emplacements sont les principales raisons pour lesquelles les entreprises lancent un projet de redimensionnement de champs.
R: Cela rejoint très bien la question précédente. À bien y penser, si nous avions une application parfaitement écrite, bon nombre de ces projets seraient aussi simples que de changer la base de données et de recompiler certains des programmes… et le tour est joué! Sans critiquer qui que ce soit, une partie de la raison pour laquelle ces projets sont difficiles est que le code n'est pas toujours écrit de manière à faire une référence correcte aux champs provenant des tables. Souvent, la véritable définition de l'origine des données n'est pas utilisée.
Un bon exemple est le suivant: si j’avais un numéro de client et que chaque définition associée à un numéro de client provenait d’un dictionnaire de données ou du fichier principal du client, alors, comme je l’ai dit plus tôt, c’est aussi simple que de changer ces tables en fonction de la nouvelle définition voulue et tout recompiler.
Quelle est la difficulté? La difficulté réside dans le fait que de nombreux éléments sont dupliqués ou que la définition ne se trouve pas nécessairement dans une source particulière et est diffusée autour de leur application. Bien sûr, un effet domino se produit lorsque je modifie une table: ce champ va avoir un impact sur beaucoup de choses dans les programmes, car ces programmes ont été redéfinis. Cela vous amène à travailler sur des champs dans des programmes, et plusieurs fois, un programme en appelle un autre. Nous avons vu des choses presque drôles dans la façon dont ils nomment les paramètres… J'ai même vu quelqu'un les nommer « Parm1 », « Parm2 », « Parm3 », etc.! Donc, disons que le client doit ouvrir ce programme qui passe un appel et que le paramètre s'appelle « Parm1 ». Imaginez simplement quelqu'un qui essaie de résoudre ce problème simplement en procédant à un balayage source, ce que beaucoup de gens font quand vous n’avez pas d’outil comme X-Analysis. Cela rend très difficile la tâche de localiser un champ particulier dans une table, ce qui est le point de départ d'un projet d'expansion de champ.
L’absence de convention d’appellation des fichiers et des paramètres peut rendre difficile la tâche de trouver où ils sont utilisés dans l’application. C’est une des raisons pour lesquelles des choses sont perdues si vous n’utilisez pas les bons outils.
Tous ces facteurs rendent les projets plus complexes qu'ils ne devraient l’être, et le plus triste, c'est qu'un grand nombre de nos clients vivent une ou plusieurs de ces situations.
R: Ces projets peuvent être énormes et risqués, car ils touchent beaucoup de choses qu’ils ne veulent pas recompiler. Encore une fois, ils peuvent avoir démarré le projet et présumer que « nous aurons terminé dans un an ». Trois mois après le début du projet, ils pensent toujours qu'ils seront terminés « dans un an ». En outre, de nombreuses entreprises attendent deux ou trois ans après avoir découvert qu’ils avaient besoin de faire un projet de redimensionnement de champs. Bien entendu, ces entreprises ont souvent d'autres priorités plus visibles à traiter en premier.
Par exemple, un de nos clients souhaitait contracter des emprunts sur plus de 30 ans, mais avait un problème avec la façon dont ils avaient géré leurs années (cela remonte au problème de l’an 2000 dont nous avons parlé plus tôt). Dans ce cas, ils utilisaient auparavant une technique appelée « années de fenêtrage » pour résoudre le problème, comme cela se faisait souvent par le passé. Cette solution permet au système de deviner le siècle de dates à deux chiffres en comparant la date à l'année en cours. Voici un exemple: nous sommes en 2019, donc si la date est 30 ou 39, nous saurons que cela signifie 2030 ou 2039, mais si la date est 70, l'hypothèse sera 1970, en fonction de la fenêtre choisie pour chaque siècle. En raison des besoins d’aujourd’hui, l’organisation pensait avoir besoin de secteurs d’activité dans lesquels les prêts dureraient jusqu’à 50 ans. C’est un exemple clair de quelque chose qui affecte l’entreprise et si vous voulez y parvenir, vous devez développer correctement le champ.
Ce n'est pas tout le monde qui subit ce genre de pression, certaines personnes pensent qu'il leur reste encore un an, deux ou trois ans.
R: Beaucoup de nos clients ont un ou plusieurs domaines qui les anéantissent, les empêchant de lancer un nouveau produit, ce qui est toujours une priorité absolue. Il y a aussi d'autres domaines qui peuvent être ennuyeux, et ils ont trouvé des moyens de contourner le problème de la taille. Par exemple, en termes de numéro de clients, ils ont souvent recyclé les chiffres. Quels sont les problèmes avec ça? Eh bien, un problème est que vous pouvez afficher une longue historique pour un client tout nouveau, en raison du fait que vous recyclez un numéro. Vous pouvez afficher l'historique d'un client inactif depuis cinq ans, ce qui vous a permis de décider de recycler son numéro, puis de placer un nouveau client dans la coque de l'ancien. C’est juste pour mentionner un truc que les gens utilisaient dans le passé.
R: La première chose est que, dans l'un de ces projets de redimensionnement, l'un des problèmes les plus importants est la portée. Comment définissez-vous la portée de votre projet?
La première étape consiste à définir les tables dans lesquelles le champ est utilisé. Une fois que vous avez fait cela, vous devez référencer tous les programmes, objets et même requêtes à travers lesquelles ces tables sont utilisées. Dans certains cas, cela sera simple: si vous avez toujours les auteurs originaux de l’application, leur contribution sera très utile car il s’agit de connaissances. La réalité est que nous n’avons souvent pas ce genre de luxe. Souvent, le personnel actuel travaille avec l'application IBM i depuis seulement quelques années, voire moins d'un an. L'expertise que vous avez dans votre entreprise va être un facteur très important qui déterminera combien de temps il faudra, même pour identifier uniquement les tables affectées.
Laissez-moi vous donner un exemple de projet de redimensionnement d’un champ de base de données d’un client. Ils ont estimé que le simple effort d'identification de l'inventaire de tout ce qui serait dans la portée leur prendrait environ huit mois. Essentiellement, huit mois pour que les personnes puissent simplement trouver les tables, programmes, requêtes, etc. dans l'inventaire afin que la portée puisse être défini. Avec X-Resize, nous avons pu le faire en quelques jours, et non en plusieurs mois.
Disons que vous avez votre portée et que nous sommes tous les deux des développeurs. Il nous faudra donc 300 objets chacun pour changer. Que va-t-il se passer avec tous ces changements? Vous le ferez d'une manière, je le ferai d'une autre manière, et plusieurs fois, il est probable que même la même personne changera la façon dont elle le fait au cours du projet, même si nous étions d'accord sur la manière de résoudre ce type de problème au début.
Certains éléments de code sont dupliqués dans l'ensemble de l'application IBM i. Vous pouvez donc en trouver plusieurs centaines de fois. Donc, même moi, je ferai une erreur à un moment donné, ce qui deviendra incohérent avec le reste des corrections. J'ajouterai un nouveau bogue à l'application, ce qui nous amènera bien sûr à réduire les risques. La cohérence de l'outil de redimensionnement automatisé atténue le risque, l'impact d'une telle erreur humaine, qui peut être assez difficile à gérer.
Une des dernières parties du projet consistera à tester et que se passera-t-il lorsque votre projet touchera l’ensemble de l’application? Vous feriez mieux de faire des tests intégrés, mais à quelle fréquence les entreprises le font-elles? Ils peuvent ne pas avoir les outils ou l'expertise. Le projet était risqué au départ, alors ajoutez à cela des contraintes de temps et des tests - ces dernières étapes seront probablement réduites au minimum, ce qui n’est pas une sage décision.
L’une des choses que j’aime avec X-Resize, c’est que cela nous permet de commencer les tests dès que possible, au lieu d’attendre que tout le monde ait terminé, ce qui est formidable, car vous pouvez vérifier les éléments que vous trouverez normalement uniquement quand il est trop tard dans votre projet.
Lorsque nous exécutons un projet, nous incluons le test des données dans l’ensemble (ou package) du projet.
R: Tout d’abord, il est extrêmement important d’avoir une visibilité sur tout ce qui doit être modifié. Tandis que nous pensons souvent qu’un domaine n’a pas besoin d’être touché, les rapports X-Analysis peuvent apporter beaucoup plus de confiance que lorsque nous essayons de faire l’inventaire et le cadrage manuellement.
Parfois, l'application X-Resize ne peut pas gérer un cas particulier dans un projet de redimensionnement de champs, car le code est un peu différent. Ce n’est généralement pas un gros problème, car il est parfois plus facile de faire la modification que d’attendre que l’application réponde à 100%. Dans beaucoup de cas, nous réussirons à tout convertir automatiquement, mais parfois ce ne sera pas possible à cause de la façon dont le code a été écrit.
En fin de compte, il est important de savoir quels objets doivent être modifiés et si le nombre de modifications manuelles est important, nous pouvons revenir au laboratoire et trouver un moyen de l’automatiser, au lieu de le convertir manuellement.
Les principaux avantages de notre approche du redimensionnement des champs sont les suivants:
• un délai plus court pour terminer le projet,
• une meilleure couverture,
• moins de risque,
• moins de personnes requises,
• moins d'erreurs humaines et manuelles,
• des tests facilités.
Nous vous invitons à visionner la vidéo de témoignage de redimensionnement de champs avec Chris Nickchen, responsable des TI chez New Penn, pour en savoir plus sur ce sujet.
