Discussion :

[Stan Adkens]

94 % des chefs de grandes entreprises envisageraient d’abandonner le système mainframe
A cause de son coût élevé et de sa rigidité, selon un rapport

L’open source et le cloud computing ont fait entrer l’univers technologique dans une nouvelle dimension. Au fil des années, la culture du développement open source est devenue un moteur de l’évolution de l’industrie du développement de logiciel, tandis que les exigences de collecte, de stockage, de traitement et de diffusion de données font de l’adoption du cloud computing un impératif afin de réaliser les objectifs. Cependant, certaines grandes entreprises utilisent encore la technologie mainframe dans le cadre de leurs activités.

Toute fois, une nouvelle enquête de LzLabs & Microsoft qui s’est intéressée aux leaders informatiques de certaines grandes entreprises du monde qui utilisent toujours des systèmes mainframes hérités révèle que cette technologie limite leur capacité d'innovation en raison du coût élevé et de la rigidité de la plateforme. Les responsables informatiques des États-Unis, du Canada, du Royaume-Uni, de France et d’Allemagne qui ont été interrogés sont préoccupés par le fait que la technologie mainframe ne leur permet pas d’exploiter des approches modernes de gestion d’applications, notamment l’open source et le cloud. Par ailleurs, ils s’inquiètent de la rareté des professionnels mainframe sur le marché, selon le rapport.

En effet, les mainframes ont longtemps été considérés comme une plateforme fiable et disponible sur laquelle les applications principales du système informatique s’exécutaient. Ce sont les ordinateurs centraux qui sont utilisés principalement par les grandes organisations pour l’exécution des applications critiques et des traitements en masse des données. Mais avec le temps, ils sont dépassés par l’évolution des technologies, car le matériel et les logiciels sont restés en l’état depuis lors. Aussi les langages traditionnels qui ont servi à développer les logiciels tels que COBOL, PL / I et Assembler risquent de ne plus être enseignés à la prochaine génération de programmeurs.

A cause de cette inflexibilité du système, les responsables informatiques donnent la priorité aux modèles open source et cloud pour le déploiement futur d'applications afin de garantir la pérennité de leur entreprise et pour qu’elle reste compétitive dans son secteur d’activité.

Les décideurs informatiques interrogées considèrent les applications mainframe comme essentielles pour les entreprises, cependant, ils sont unanimes que la plateforme constitue un obstacle à l'innovation. Pour 84 % des répondants, il est difficile de modifier les applications de leur système mainframe tandis que 71 % affirment que le manque de flexibilité de leur plateforme mainframe limite la capacité d'innovation du service informatique.

En ce qui concerne les professionnels mainframe, 81 % sont inquiets à cause du déficit potentiel de compétences au sein des équipes mainframe de leur organisation tandis que 56 % des répondants pointent du doigt le manque de plan de relève permettant à la nouvelle génération d’employés d’acquérir des compétences nécessaires. Par ailleurs, 94 % des personnes interrogées envisageraient d’abandonner la plateforme mainframe et 77 % des décideurs informatiques affirment avoir déjà entamé le processus de migration.

Les décideurs informatiques préfèrent abandonner la technologie mainframe au profit des solutions open source et des modèles cloud pour le déploiement de leurs futures d'applications. 96 % des répondants privilégient l'open source pour leurs futures initiatives informatiques tandis que 71 % choisissent le cloud pour le déploiement de leurs nouveaux systèmes et applications.

Le manque de flexibilité, le coût élevé, la pénurie de professionnels et le manque de maintenance du système mainframe limitent la capacité des entreprises à innover. Ce sont ces raisons qui incitent les décideurs informatiques à opter pour des modèles open source et cloud afin de moderniser les systèmes de leur entreprise pour la rendre plus compétitive.

Source : LzLabs

Et vous ?

Que pensez-vous de ce rapport ?
Que pensez-vous de l’abandon total des mainframes ?

Voir aussi

Cloud : quelles sont les tendances et comment les développeurs choisissent-ils leurs fournisseurs ? Un sondage de VisionMobile
Les premiers mainframes d'IBM ont 50 ans, et ils continuent à être utilisés dans de nombreuses entreprises
L'open source, moteur de l'innovation technologique ?, 80% de logiciels commerciaux seront basés sur des piles open source
Emploi : l'open source est un domaine porteur, mais les talents restent une denrée rare, révèle l'Open Source Jobs Report de 2016
Découvrir les avantages du DevOps dans une architecture de cloud hybride, un livre blanc gratuit disponible en téléchargement

[Darkzinus]

Quand ils chiffreront les coûts de migration (et les risques) je ne suis pas certain que le pourcentage sera aussi élevé.

[redcurve]

Quand ils chiffreront les coûts de migration (et les risques) je ne suis pas certain que le pourcentage sera aussi élevé.

Ces solutions ne sont plus viables à moyen, long terme donc il n'y a plus le choix

[benjani13]

Quel sont les solutions majoritairement envisagées? Une bascule brutale vers le "monde moderne" ou une migration minimale vers une solution comme celle de LzLabs?

[AndMax]

Quel sont les solutions majoritairement envisagées? Une bascule brutale vers le "monde moderne" ou une migration minimale vers une solution comme celle de LzLabs?

LzLabs peut répondre à des problèmes d'infrastructure (faire tourner les logiciels mainframe sur autre chose qu'un mainframe), mais cela ne résoudra rien en ce qui concerne la maintenance ou l'évolution de ces logiciels, les compétences disponibles, etc...

Une "bascule brutale" étant généralement un projet titanesque, il n'y a pas de solution simple.

[foetus]

Quand ils chiffreront les coûts de migration (et les risques) je ne suis pas certain que le pourcentage sera aussi élevé.

Je demande s'il y aura que des coûts de migration Parce que je pense que certains s'imagent déjà piloter leur mainframe stockée sur un cloud avec leur tablette et pouvoir surveiller le résultat de l'intégration continue.

[abriotde]

Quand ils chiffreront les coûts de migration

Il ne migreront pas, ils la laissent mourir. C'est simple toute application Mainframe qui tourne continuera de tourner mais toute nouvelle application est développée sur un autre système. Et il viens un moment ou tout a été remplacé sauf une petite fonctionnalité central qui migrera par obligation. C'est ainsi que le Mainframe meurt. Cette agonie durera encore 20 ans (comme celle du minitel, de Gopher...)

[Ryu2000]

Un jour il n'y aura plus de développeur COBOL, donc il faut bien passer à autre chose ^^

[Darkzinus]

Un jour il n'y aura plus de développeur COBOL, donc il faut bien passer à autre chose ^^

Ca n'existe déjà plus un développeur COBOL à l'heure actuelle et depuis longtemps. Un développeur COBOL est quelqu'un formé en 3 mois (ça peut même concerner des gens formés il y a 20-30 ans) qui devient par la suite compétent (ou pas).

[Darkzinus]

Il ne migreront pas, ils la laissent mourir. C'est simple toute application Mainframe qui tourne continuera de tourner mais toute nouvelle application est développée sur un autre système. Et il viens un moment ou tout a été remplacé sauf une petite fonctionnalité central qui migrera par obligation. C'est ainsi que le Mainframe meurt. Cette agonie durera encore 20 ans (comme celle du minitel, de Gopher...)

C'est totalement vrai pour tout ce qui est IHM. Pour la partie moteur c'est plus complexe. Les batchs ne sont pas remplacés du jour au lendemain (la complexité des traitements étant ce qu'elle est) et c'est bien là le cœur du système.

[LeBressaud]

Et d'après ce rapport 93% pensent que les mainframes sont viables à long terme...

[darklinux]

Il est plus que temps

[4sStylZ]

Quelques petits trucs sur les environnements mainframe. Je ne suis pas une bible, je ne dev même plus mais j’ai bossé sur AS-400…

On ne code pas forcément en COBOL si on fait du Mainframe (Ou des mini-ordinateurs comme l’AS-400). Il y a des langages qui lui ressemblent comme RPG-IV ile qu’il ne faut pas oublier. De mon experience le COBOL*est peut être moins utilisé que le RPG. Au final ça ne change pas grand chose juste que de lire tout le temps COBOL sans jamais lire RPG j’ai l’impression que personne sait se représenter le mainframe. Moi même je ne sais pas de quoi parle l’article étant donné que tous les sujets ici je les ai constaté sans jamais avoir bossé dans le main-frame mais sur AS-400.
Pour generer du COBOL ou du RPG on ne code pas dans ces langages, on utilise parfois des langages de plus haut niveau, des AGL etc.
Pour apprendre les langages de bas niveaux il y a toujours des formations qui existent. Bien-sur ça attire moins de gens… mais ça file du boulot, c’est bien payé etc. Sur que c’est pas à la mode mais faut pas cracher dans la soupe :*On fait des trucs incroyable avec la puissance de ces machines.

Pour ce qui est du patrimoine applicatif il faut comprendre que les boites qui ont travaillés en mainframe le font depuis 30~40 ans et qu’il s’agit des banques, des assurances, de la logistiques. 99 des 100 plus grande entreprise française possède un AS-400.
Ces sociétés ont des patrimoines immenses. Un exemple :*l’un des groupes logistique pour lequel j’ai bossé possède un patrimoine de 12000 programmes interactifs (sans parler des batchs donc) pour son appli logistique. La migration envisagé a été validé et en 2014 ils parlaient d’une horizon 2027 pour passer chez SAP.
Ce genre de client ne « laisse pas » mourir leurs applicatifs car ils peuvent ce permettre ça.

J’ajouterai sur la partie IHM qu’on peut très bien mettre à profit la puissance du Mainframe pour faire des interfaces web hyper modernes. Pour la plupart des gens toute l’IHM des applis en COBOL sont des écrans verts sur noir qu’on exploite via un émulateur de terminal. Or il existe des produits qui permettent d’attaquer des serveurs main frame.
Donc l’argument du mainframe qui meurt à cause de l’IHM…

[Jiji66]

Un jour il n'y aura plus de développeur COBOL, donc il faut bien passer à autre chose ^^

100% d'accord, les informaticiens ont trop longtemps vécus sur le mythe qu'ils sont irremplaçables, être grassement payé à ne rien faire ne peux pas durer toute une vie...

[Gwilherm]

1. Le mainframe coute cher.
2. le mainframe est rigide.
3. le mainframe manque de glamour.
4. le mainframe manque de personnel qualifié.
5. les langages n'évoluent pas.

1 -> le cout de la facturation est élevé, c'est incontestable mais si on prend le nombre de traitement batch traité par un Z et celui du monde distribué, on s’aperçoit que si votre machine Z tient dans un bureau de 4 personnes, l'équivalent en terme de serveur pour traiter le même nombre de batch vous nécessite un datacenter. Je serais gentil et ne parlerais pas du cout de gestion en terme de réseau, de mise à niveau, de personnel, de surveillance et de gestion du parc. (A qui il est ce serveur ?)... (dans ma boite, sur un Z, nous sommes en termes de batch à 70 000 traitements jours, et pour les transactions...)
2 -> Tout les traitements ne nécessitent pas d'être modifiés tout les 5 matins, une chaîne comptable reste une chaîne comptable. Et la gestion du legacy nécessite un environnement stable et fiable. Donc non on ne peut pas installer n'importe quoi, (enfin si on peut mais pas les dev... ). Et pour être exact, ce sont le plus souvent les process qui rendent la gestion des projets et évolutions sur les Z lourdingues.
3 -> Ah le côté suranné des panels ISPF... On n'est pas dans le clic & drop, les interfaces sont peu conviviales c'est vrai mais ça fait le taf et ça le fait bien.
4 -> Oui mais la faute à qui ?
5 -> Si si, les langages évoluent, et la prise de tête que génère chaque migration cobol...

Oui la tendance est à la disparition du Mainframe, mais d'un autre côté j'entends ce discours depuis le début des années 2000. Cela arrivera, mais la réactivité et les grands groupes...

[Aiekick]

c'est quoi ca le mainframe ? c'est genre une facon de faire comme "l'agile" ou c'est tout autre chose ?

[4sStylZ]

En plus de ne pas savoir ce qu’est le mainframe tu n’as pas l’air de savoir ce qu’est un moteur de recherche.

[benjani13]

Un exemple :*l’un des groupes logistique pour lequel j’ai bossé possède un patrimoine de 12000 programmes interactifs (sans parler des batchs donc) pour son appli logistique. La migration envisagé a été validé et en 2014 ils parlaient d’une horizon 2027 pour passer chez SAP.

SAP ERP ne souffre-t-il pas des mêmes défauts que les systèmes pour mainframe? Un écosystème très à part, souffrant d'un héritage technique assez lourd, de peu de développeurs (de part le manque de formation et le fait que le dev SAP est peu sexy), une UX à la ramasse (même si il y a des possibilités de clients légers, d'interfaces web plus poussées). J'ai fait du dev ABAP sur SAP R/3 pour une boite et c'est franchement pas un bon souvenir.
Je ne remet pas en cause les capacités de SAP, mais sa façon de fonctionner très "vieux monde" qui lui colle peut être les même tares que le développement mainframe aujourd'hui.

[darklinux]

Personne ne contexte le coté batch des mainframes , ils sont conçus ainsi et à donné l ' une des bases d ' UNIX . Le problèmes est que les AS/400 like ont une conception qui remonte aux années 1960 . Les mini ont disparus à cause de Linux et du prix des serveurs . Il me semblent que l ' on à essayé un assemblage UNIX et mainframes , mais cela n ' a pas réussi . Une solution ? passé les données dans des moulinettes pour la préservation de celle ci

[el_slapper]

les AS/400 sont des mainframe "light", généralement utilisés dans des structures plus petites, ce qui rend la migration vers autre chose possible. Il est possible qu'ils disparaissent à moyen terme.

Pour les énormes machines Z/OS qu'on trouve dans la plupart des grands comptes financiers(ainsi qu'à la FNAC et quelques autres), c'est différent. On a des existants absoluments massifs, et la plupart des projets de migration se terminent mal. Ce qui se passe, par contre, c'est que tout ce qui est loin du noyau comptable(à commencer par les interfaces utilisateurs) a déjà été remplaçé, et que les langages modernes, peu à peu, s'emparent des couches intérmédiaires.

Mais pour les couches basses, les immenses batchs comptables du noyau et des données connexes, le duo COBOL/Mainframe reste diablement efficace. J'en veut pour preuve ce projet ou on avait été mis en concurrence avec le JAVA, et ou notre estimation était moitié moindre(alors qu'on avait à gérer l'aller-retour depuis UNIX en plus, eux tournaient en natif), et ou on a quasiment tenu le tryptique delai-cout-qualité. Ou encore ce grand compte qui a mis 100M$ sur la table pour passer son SI de COBOL/ZOS à JAVA/UNIX et qui a fait demi-tour pour des raisons de performances.

Le truc, c'est que COBOL est le seul langage à ma connaissance à proposer en natif des formats de données numériques optimisées pour la comptabilité(suivi de très très loin par, ne rigolez pas, le VB6,avec son très limité format currency qui est mieux que rien). Tant que les nouveaux langages seront conçus par des geeks qui considèrent qu'un nombre de taille fixe à virgule fixe, c'est l'anathème absolu, alors le COBOL restera le meilleur dans cette niche là. Le jour ou le prochain Guido Van Rossum aura des bases comptables, alors oui on pourra remplacer le COBOL. Pas avant.

Bon, et puis nombre des défauts de COBOL sont aussi des qualités dans le monde bancaire. Notamment, son extrême rigidité sur la déclaration de variables fait que les fuites mémoires sont impossibles. Si on fait une erreur, le programme plante, mais ne va pas empêcher les autres de tourner. Son aspect repoussant pour les geeks fait que les gens qui bossent dessus auront moins des réflexes de contournement des règles. Ce qui allonge les temps de développement, mais sécurise aussi le banquier prudent avec l'argen de ses clients.