(article publié sur le numéro de Programmez! de la rentrée)
Un mot sur l’infrastructure
En 2010 (derniers chiffres connus), le système d’exploitation IBM i (et ses prédécesseurs OS/400 et i5/OS) était la plateforme IBM disposant du plus grand nombre de clients (250 000 entreprises environ clientes IBM i dans le monde). L’IBM i dans ses différentes itérations a été vendu à plus d’un million d’exemplaires depuis son introduction en juin 1988.
En recul dans sa commercialisation, L’IBM i reste dans beaucoup d’entreprises la plate-forme informatique de référence, celle sur laquelle sont hébergées les applications et les données vitales.
Ses atouts ?
Un serveur d’applications, une base de données et un système de stockage interne hors pair.
Elle a su évoluer avec le temps pour devenir le couteau suisse de l’informatique en intégrant de multiples fonctions (JAVA, PHP …) et en s’ouvrant à d’autres systèmes (AIX, linux).
Son défaut majeur ?
Un environnement de programmation désuet – SEU– et un langage de programmation peu moderne – RPG.
Aujourd’hui les entreprises peinent à trouver des spécialistes du RPG.
Le renouvellement des compétences RPG est en effet très limité, ce qui amplifie un phénomène de fond : la raréfaction des développeurs RPG. Cette carence s’accentue par une vague massive de départ à la retraite programmée sur les 10 prochaines années associée à une forte volonté des grands éditeurs et intégrateurs de gérer à leurs profits cette raréfaction.
Au final, il s’agit bel et bien d’un risque énorme pour les entreprises de perdre leur capital et savoir-faire métier, sans pouvoir assurer la relève.
Le langage n’est pas le principal problème
Dans un contexte de crise économique, on pourrait penser qu’il est facile de trouver des candidats disponibles pour les postes de développeur RPG. Malheureusement, il n’en est rien. En effet, le langage RPG n’est plus attractif comparé aux langages modernes. Les applications cibles ne sont pas « sexy » notamment parce que la couche de présentation graphique n’est pas développée en RPG.
Autre phénomène : il n’est pas évident de se mettre en avant lors d’une soirée devant les copains quand on programme en RPG ! Il est même difficile d’expliquer que la majeure partie du business des entreprises est programmée dans ce langage.
Ceci étant, le langage RPG est procédural, facile à appréhender et ne constitue pas à lui tout seul le point de blocage quant à l’embauche de jeunes développeurs.
L’environnement de développement : la double peine
L’accès à l’environnement de développement RPG natif (SEU) se fait via des émulateurs 5250 en mode caractère. L’outil de travail numéro 1 du développeur étant l’éditeur de texte, les développeurs IBM i passent le plus clair de leur temps dans l’éditeur SEU datant des années 80 !
Lors de leur formation, les stagiaires considèrent l’accès à l’IBM i en 5250 comme une sorte de minitel antédiluvien. Certains d’entre eux abandonnent purement et simplement lorsqu’ils comprennent qu’ils vont passer leurs journées dans un tel environnement.
Cet outillage est clairement un frein pour le recrutement de jeunes talents et constitue un filtre de sélection naturelle retenant certes les plus motivés mais pas forcément les plus talentueux…
La comparaison entre l’interface 5250 et les interfaces graphiques modernes est tellement désavantageuse pour le 5250 qu’il ne faut pas espérer que les jeunes recrues deviennent des experts dans l’utilisation du SEU … même en Inde ! Leur efficacité dans un tel environnement restera donc très limitée pour la plupart d’entre eux.
La solution : Eclipse
Par quels outils remplacer l’outillage traditionnel sous SEU ? Il n’y a désormais plus beaucoup de questions à se poser : Eclipse est devenu un standard de fait.
Eclipse fournit en effet un cadre permettant de développer des outils de développement intégrés largement utilisés dans le monde Java (Eclipse, lui-même, est développé en Java). Faire profiter les développeurs RPG de cette infrastructure présente plusieurs avantages :
- environnement moderne, intégré, attractif pour les jeunes développeurs
- fonctionnalités ouvertes sous forme de plugins
- rapprochement des développeurs Java et RPG
- bénéficie d’une forte communauté, dynamique, active et internationale
Etant largement utilisé dans le monde Java, Eclipse dispose d’une multitude de plugins de gestion de sources, gestion des anomalies, gestion de projet, tests unitaires, etc. Tous ces plugins sont mis en œuvre aujourd’hui dans le cadre de méthodes projet agiles et constituent une opportunité d’évolution pour les méthodes de développement IBM i.
Outils: Opter pour l’Open Source
Les plugins Eclipse sont généralement développés en EPL (Eclipse Public Licence), modèle de licence qui permet à tout un chacun de modifier, compiler et éventuellement commercialiser des plugins. Ceci favorise l’émergence de solutions professionnelles basées sur des plugins Open Source.
Il devient alors possible de bâtir un atelier de développement RPG sur mesure en assemblant les plugins qui conviennent aux modes de fonctionnement et aux outils de son entreprise. Il suffit seulement que les plugins accèdent de manière native aux ressources Eclipse et n’enferment pas l’utilisateur dans un cadre propriétaire.
Cet atelier devient un logiciel résultant de l’assemblage de plugins dans lequel on configure les fichiers de paramétrage communs à l’ensemble des développeurs et que l’on distribue sur les postes de travail. Une bonne pratique communément partagée est de faire une mise à jour annuelle.
Dans certains cas, le développement de plugins spécifiques et/ou la contribution à l’évolution de plugins existants doit être considéré.
A propos du ROI
Si Eclipse est gratuit, tous les plugins ne le sont pas ! Outre l’achat des plug-ins, la mise en place d’un atelier Eclipse RPG va nécessiter des couts d’adaptation de l’existant plus ou moins importants en fonction des choix fonctionnels décidés. Les couts de formation ne sont pas non plus à négliger. Ceux-ci peuvent toutefois être minimisés si on ne remet pas en cause les processus existants ; dans le meilleur des cas (et pour une solution bien adaptée) une seule journée suffit !
Une recommandation : commencer petit en évitant dans un premier temps de remettre en cause toute l’infrastructure de gestion des sources (sauf si cette infrastructure est le problème, bien sur).
Bien que les gains en transmission de la connaissance de l’entreprise, des applications et du savoir faire ne fassent pas souvent l’objet d’un chiffrage (on se demande d’ailleurs pourquoi ?), il est possible de considérer des gains de productivité « robotiques » sur les opérations de base du développement (navigation dans les sources, édition, auto-complétion, contrôle syntaxique local, etc…). Un benchmark a été réalisée par IBM et exhibe un gain de productivité de l’ordre de 30%.
Les gains de type « robotique » sont à relativiser car un développeur ne passe pas tout son temps à manipuler des sources. En revanche, la différence d’efficacité entre les éditeurs SEU et Eclipse est tout simplement indiscutable même pour des programmeurs RPG chevronnés.
Faut-il procéder à des calculs d’apothicaire ? Tout dépend du prix de la solution évaluée. Si celle-ci est peu onéreuse, on peut faire l’économie d’une étude de ROI pour peu que l’on soit convaincu que la modernisation des outils de développement RPG est incontournable pour continuer à faire vivre son patrimoine applicatif IBM i.
J2EE / IBM i : Opter pour l’agilité et la convergence
Mettre en place un atelier de développement RPG/400 sous Eclipse est une formidable opportunité pour faire évoluer les méthodes de travail et les mentalités : commencer à mettre en place de l’agilité côté AS/400. Afin de tendre vers des livraisons régulières, fiables et en phase avec les demandes du métier, il est nécessaire de ne pas sacrifier la qualité de la production :
- contrôle qualité du code : ce point est en général déjà adressé dans les organisations (CMMI oblige) mais de manière inégale.
- tests automatiques (unitaires et de non régression) : ce sujet est plus délicat et fait l’objet souvent de réserves alors qu’il est avant tout une question de volonté de la direction et de méthodologie.
L’enjeu, à terme, serait de pouvoir unifier les usines RPG et Java, grâce à des méthodes et des processus communs. Cette tendance apporterait une vraie plus-value en termes de productivité, de rendements et de coûts.
Ainsi, les développeurs formés au langage Java seraient davantage incités (motivés !) à monter en compétence RPG, si les outils sont les mêmes. A l’inverse, l’apprentissage du langage Java serait facilité pour un RPGiste. D’un point de vue managérial, cette transversalité reste un facteur clé d’avenir pour la continuité des patrimoines AS/400 et un facteur clé de motivation pour les nouveaux développeurs!
A propos de METRIXWARE
Depuis 1995, l’éditeur français et indépendant Metrixware propose des technologies innovantes et des solutions industrielles pour la modernisation des applications cœur de métier et ce qui sert à les produire, l’usine logicielle.
Metrixware édite notamment Cobos (https://cobos.metrixware.com), l’IDE COBOL de référence sous Eclipse pour les Mainframe et Unix. Cobos permet de gagner en productivité en modernisant le poste de travail des développeurs COBOL et PL1, sans impact sur les infrastructures centrales.
Sa filiale SystemObjects édite Cobol4i (en complément de SmartPad4i), l’IDE RPG de référence sous Eclipse pour IBM i. Aussi avantageux sur le plan technique que financier, Cobos4i permet de gagner en productivité, de systématiser le contrôle des « bonnes pratiques » RPG et de moderniser le poste de travail des développeurs, sans impact sur le coût des ressources IBM i.
Pour en savoir plus sur Cobos4i : https://www.metrixware.com/solutions/cobos4i/
