Disparition annoncée de l’écran 3270 au profit des IDE

Les grands systèmes subsistent dans bon nombre d’entreprises. Alors que leur IHM a été modernisée, les évolutions appliquées à ces plates-formes doivent désormais répondre aux exigences du développement moderne.

L'évolution des interfaces utilisateur pour l'accès aux applications mainframe a rendu inéluctable l'adaptation des outils de développement aux nouvelles habitudes de travail des développeurs. Cette adaptation - en tirant les leçons de l'expérience - permet aussi aux entreprises de profiter pleinement des économies de l'externalisation des développements tout en maintenant la sécurité, la robustesse et la performance de leurs mainframes.

Après en avoir contesté la pérennité, tout le monde reconnaît aujourd'hui le rôle incontournable que continueront encore longtemps de jouer les grands systèmes mainframe dans l'informatique d'entreprise. Faire ce constat aujourd'hui, c'est aussi faire celui de l'évolution des usages du mainframe et en tirer des enseignements pour le futur.

Si les discours ont pu être contradictoires, les différentes vagues technologiques sensées contribuer à la "disparition" du mainframe montrent une cohérence frappante quant au moyen utilisé. Du "revamping" des années 90 à l'intégration du mainframe dans les architectures orientées services (SOA), il s'agit toujours de faire disparaître le seul inconvénient réel du mainframe, des interfaces écran peu attractives.

Aujourd'hui, la plupart des écrans verts 3270 ont été remplacés côté utilisateur par des applications Java, des interfaces Web ou des clients riches en environnement Windows. Ces efforts réalisés traduisent une volonté stratégique forte : privilégier la continuité du mainframe comme outil d'infrastructure clé pour la performance de l'informatique d'entreprise.

Un choc des cultures de développement
Comme le démontre la demande croissante de compétences autour des langages d'applications mainframe, et notamment Cobol, les entreprises ne se contentent pas de maintenir les applications existantes. Elles investissent désormais à nouveau dans la création de nouvelles applications de coeur de SI.

Mais les entreprises sont, là aussi, confrontées au choc des cultures et à l'évolution des interfaces homme-machine. Ce qui est vrai pour les utilisateurs finaux l'est d'autant plus pour les nouvelles générations de développeurs. Non seulement, ils ont eux aussi été nourris d'interfaces utilisateurs conviviales et flexibles, mais leurs méthodes de travail ont été fortement structurées par l'évolution des langages de programmation, et notamment par les langages orientés objet.

Mutualiser les méthodes communes à tous les langages
Pour avoir une plus juste idée de l'ampleur de cette évolution, il suffit de s'arrêter un instant sur les différences entre les outils de développement en ligne de commande accessibles sur un mainframe et un environnement de développement intégré comme Eclipse. La différence la plus importante n'est pas liée à l'interface graphique mais à une divergence profonde d'approche que les entreprises doivent désormais combler.

Avec la diversification des langages de programmation, les environnements de développement ont en effet considérablement évolués. Hier, ils étaient intimement liés à la plate-forme pour laquelle ils étaient conçus. Aujourd'hui, c'est de plus en plus dans l'environnement de développement que se mutualisent les méthodes et les procédures communes à plusieurs langages ou plates-formes. Qu'il s'agisse de code C++, Cobol ou Java, il est par exemple toujours nécessaire de compiler ou de déboguer.

Par leur vocation "universelle", les environnements de développement apportent aux entreprises et aux développeurs plus de fiabilité et de productivité, en permettant notamment de capitaliser sur les bonnes pratiques quel que soit le langage utilisé ou le système cible. Ouverts et collaboratifs, ces IDE (Integrated Development Environment) de nouvelle génération sont aussi des composants clés pour la mise en oeuvre des stratégies d'externalisation des développements et de la maintenance, qui constituent aussi un axe fort de la stratégie des entreprises.

Adapter l'outillage de développement du mainframe à un nouveau contexte
Les développements d'applications mainframes ont pu rester quelques années en marge de cet effort de standardisation des méthodes. A juste titre, les entreprises ont privilégié la stabilité et la sécurité offertes par les procédures rigoureuses du mainframe en matière d'identification des utilisateurs, de gestion des versions de fichier, etc... Mais dès lors que le mainframe est restitué pleinement dans sa dimension de composante stratégique du SI, dès lors qu'il s'agit de s'appuyer sur de nouvelles compétences de développement, il devient nécessaire de franchir une nouvelle étape dans l'adaptation du mainframe à ses nouveaux usages.

De même que l'évolution des technologies de présentation de l'information a permis à l'entreprise de pérenniser l'usage du mainframe auprès de nouvelles générations d'utilisateurs finaux, il faut aujourd'hui adapter l'outillage de développement des mainframes aux nouvelles exigences des entreprises et de leurs développeurs, depuis la mutualisation des méthodes et des procédures jusqu'au développement collaboratif, à l'externalisation et à l'offshore.

Tirer les leçons de l'expérience
Pour faire disparaître en toute sécurité l'écran vert 3270 du développeur, il est avant tout nécessaire de tirer les leçons de l'expérience. Les mécanismes de contrôle d'intégrité, de gestion des versions ou d'identification des mainframes ont fait leur preuve et ne sont donc pas à remettre en question. Par ailleurs, les environnements mainframe ne sont pas exempts de complexité. En matière de compilation par exemple, jusqu'à six méthodes différentes peuvent être utilisées pour un même code Cobol, en fonction de la version et de l'ancienneté de l'application.

Un autre aspect important à prendre en compte est celui de la sécurité. Dans l'environnement mainframe, l'accès du développeur aux objets et aux fichiers est strictement contrôlé par un processus rigoureux d'authentification, d'habilitation et de verrouillage automatique de la ressource pour prévenir tout conflit de version. Ces dispositifs indispensables à la sécurité du mainframe sont difficiles à concilier avec les nouvelles pratiques d'externalisation du développement et des tests, et encore plus avec les développements offshore.

Remplacer l'interface sans changer les procédures
La réponse à cette problématique tient pour l'essentiel dans la capacité à modéliser le savoir des développeurs mainframe. Dans la pratique, la réalisation d'un développement mainframe nécessite non seulement de connaître le langage utilisé mais aussi un certain nombre d'instructions et de procédures en ligne de commande. Ce sont ces instructions et ces procédures qui peuvent être modélisées pour être appelées à distance depuis un environnement de développement intégré comme Eclipse.

La meilleure façon d'intégrer le mainframe aux environnements de développement de nouvelle génération consiste en réalité à remplacer l'interface de développement 3270 par celle de l'IDE, mais sans modifier en aucune façon le comportement ou les procédures du mainframe. Lorsque, dans son interface IDE, le développeur clique sur l'option de menu Déboguer, comme il le ferait s'il s'agissait de code Java ou C++, la procédure n'est pas lancée sur son poste de travail mais directement et à distance sur le mainframe. Les résultats fournis sont ainsi beaucoup plus fiables et fidèles.

Qu'il s'agisse d'explorer les objets ou fichiers ou bien de modifier des lignes de code, l'ensemble des données reste sur le mainframe afin d'éviter les doublons ou les conflits de version. D'une certaine façon, l'environnement Eclipse est transformé en écran distant du mainframe, grâce à des procédures et une interface de communication adaptée. Cette approche apporte aux entreprises la flexibilité dont elles ont besoin pour pérenniser leurs développements mainframe dans les meilleures conditions économiques, grâce à l'externalisation, et quel que soit le niveau d'expérience de leurs développeurs Cobol.

Autour du même sujet