Pourquoi le mainframe doit-il changer ?

• La vitesse : Actuellement, les outils et les processus que les organisations IT utilisent le plus pour gérer le développement des programmes Mainframe, pour effectuer les tests et pour assurer la production datent des années 1970. A cette époque il fallait du temps pour analyser, pour écrire, pour tester et corriger les programmes. Ce qui était dans le rythme des entreprises de l’époque.

Ce n’est plus le cas aujourd’hui. A présent, le rythme des changements dans des marchés très volatils est implacable. Donc, si l’entreprise a besoin de mettre à jour l’application Mainframe ou d’extraire des données à partir d’une base de données de l’ordinateur central pour réaliser des jeux d’essai, il faut que ce soit fait rapidement. Les outils Mainframe et les processus – et peut-être même la culture sous-jacente des équipes mainframe – doivent être transformés pour correspondre à l’agilité qui existe sur d’autres plates-formes.

• La convergence multiplateforme : Dans les années 1970 les applications Mainframe traitent toutes les informations en entrée pour fournir tous les résultats qui étaient généralement imprimés. Rien de plus n’était fait.

A présent, de plus en plus, les applications Mainframe traitent toujours les informations en entrée pour fournir des résultats qui vont alimenter des ressources back-end pour les utilisateurs qui utilisent le web et des applications mobiles. Ces applications fonctionnent sur toutes sortes de plateformes. Par conséquent, les équipes mainframe ne peuvent plus travailler dans leur bulle tenue à l’écart des autres équipes. Au lieu de cela, les équipes Mainframe doivent être en mesure de collaborer de manière plus efficace avec les équipes des autres plateformes (informatique distribuée, cloud, web, mobile, etc.). Les outils et les processus métier Mainframe (développement, sécurité, gestion des problèmes, planification des capacités, etc.) doivent être transversaux afin de répondre de manière optimale aux exigences croissantes de l’économie numérique.

• Le changement de génération : Toutes les équipes qui ont connu le démarrage des Mainframe, ses joies, ses ennuis, ses nuits blanches vont progressivement passer la main à une nouvelle génération d’informaticiens.

Seulement un tout petit pourcentage de ces nouveaux professionnels de l’informatique aura suivi un cursus de formation spécialisé sur le Mainframe. En effet les technologies des années 1980, méthode et langages, ne sont plus enseignées dans les universités. La plupart des jeunes de la prochaine génération d’informaticiens seront ancrés dans des technologies telles que la méthode objet, les langages Java, C ++, les produits Eclipse. Ils ne possèderont que très peu de connaissances spécifiques à l’ordinateur central et une tolérance proche de zéro pour les outils qui ne sont pas graphiques, intuitifs et automatisés.

En dépit de ce changement radical dans la dotation en personnel, l’informatique doit trouver une façon de maintenir à jour le cœur de ses applications basées sur le COBOL et les bases de données DB2. Les entreprises doivent maintenir les performances de leurs environnements reposant sur les systèmes z. En d’autres termes, il est nécessaire d’intégrer au mainframe des workflows issus des nouvelles technologies.

Que faire pour rendre l’ordinateur central plus « new-techno friendly » ?

Les responsables informatiques doivent entreprendre dès maintenant plusieurs modifications spécifiques s’ils veulent conserver leur environnement mainframe aussi performant qu’aujourd’hui :

• Adopter des processus agiles : La plupart des équipes de développement Mainframe utilisent le mode en cascade pour concevoir les applications et les programmes. Cette utilisation résulte du traitement par lots et par un manque d’outils.

La gestion des sources n’est pas toujours adaptée à une exploitation quotidienne et à une demande de modification nécessitant une programmation en parallèle de maintenances. Ceci d’autant plus que les demandes peuvent se succéder à un rythme rapide. Il faut donc attendre que les programmes soient libérés et livrés en exploitation pour les reprendre en modification dans le cadre d’une nouvelle évolution.

Les délais de réalisation doivent donc prendre en compte toute cette problématique et les évolutions ne sont pas aussi rapides que l’entreprise le voudrait.

La mise en place d’un système de management des sources ne suffira pas. Vous devez également obtenir des développeurs qu’ils pensent en termes agiles (Scrum, Kanban, etc.), de sorte que le travail soit motivé par l’urgence de l’entreprise plutôt que les habitudes et les commodités des développeurs.