IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Stan Adkens

109PARTAGES

14  1 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de abriotde
Membre chevronné https://www.developpez.com
Le 12/10/2018 à 14:41
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...)
8  1 
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 13/10/2018 à 16:24
Citation Envoyé par 4sStylZ Voir le message
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…
j'ai bossé aussi longtemps sur AS/400 et je me souviens d'utilisateurs qui avaient choisi de passer d'un produit AS/400 vers du Client/Server Oracle car l'appli était très jolie avec des couleurs et des icônes partout...six mois plus tard, les utilisateurs regrettaient les écrans texte vert qui était réduits à leur plus simple expression, avec une saisie rapide et intuitive normalisée (F3 = Quitter, F4 = Liste, F5 = Actualiser, F7 = Page suivante, F8 = Page précédente...si je me souviens bien) alors que sous Windows ils passaient leur temps à prendre la souris pour cliquer sur un bouton, pour ouvrir ou fermer une boîte de dialogue, une perte de temps énorme avec des écrans pas au standard Windows en plus...et la gestion des impressions c'est un autre monde sur AS/400 ... longue histoire.
6  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 15/10/2018 à 17:37
Citation Envoyé par Pyramidev Voir le message
Pourquoi veux-tu absolument que ce soit en natif ?

Pour manipuler des nombres réels de taille fixe à virgule fixe, il n'y a pas besoin de les avoir en natif. Il suffit de coder une petite bibliothèque dans un langage qui supporte à la fois les entiers de taille fixe et la surcharge des opérateurs. Il en existe plusieurs, le plus connu étant C++.
Certes. Mais est-ce que les processeurs sont optimisés pour ça? Indépendamment du proc, est-ce que ce genre de fonctions a un impact sur les performances? Les machines Z/OS ont des proc spécificquements optimisés pour ce genre de calcule en COBOL. C'est tout un écosystème qui est performant sur ce point précis; pas juste le langage.

Citation Envoyé par Pyramidev Voir le message
Pourrais-tu nous en dire plus ?
En langage C, il faut fixer des conventions pour déterminer qui est responsable de désallouer. En général, par défaut, c'est celui qui alloue qui doit désallouer. Malheureusement, beaucoup de développeurs n'ont pas ce niveau de rigueur.
En C++, il suffit de maîtriser le RAII pour que les fuites de mémoire soient quasiment impossibles. Malheureusement, beaucoup de développeurs C++ ne le maîtrisent pas.
En COBOL, qu'est-ce qui décourage les fuites de mémoire ?
Partout ou je suis passé en COBOL, la partie orienté objet du langage était désactivée dans les compilateurs. C'est la seule partie qui permet des fuites mémoires.

Pour le reste, elles ne sont pas découragées, elles sont carrément impossibles : la mémoire est allouée à la compilation, et tout accès en dehors est puni par un plantage 0C4. Une zone mémoire en COBOL, doit être définie à la compilation, ne peut pas être étendue après compilation. Évidemment, ça rend certains styles de programmation impossibles, et certains algorithmes chiants(je reste poli) à coder. Mais il est rare(même si ça arrive) Qu'on aie besoin de ce genre d'algorithmes.

Citation Envoyé par Pyramidev Voir le message
Quelles règles ? Si tu parles des bonnes pratiques, je me rappelle que tu avais écrit que certains développeurs COBOL faisaient des copiés-collés au lieu de factoriser proprement le code.
Vrai, mais c'est vrai partout. Dans tous les langages, tu as pléthores d'ignares qui font n'importe quoi. J'en ai brièvement fait partie, d'ailleurs, puis j'ai appris. A chaque nouveau langage, d'ailleurs(le dernier étant le COS). Certains n'apprennent jamais.

Ce que je veux dire, c'est que le COBOL est bien plus tolérant vis-à-vis de ce genre de mauvais programmeurs. Un médiocre fera quand même tourner son appli, après bien des efforts. Et ça sera satisfaisant. Le même en JAVA, et les temps de traitement sont multipliés par 400(alors que le Java moderne est loin d'être lent, quand il est programmé dans les règles de l'art). En plus, l'aspect verbeux du COBOL, si il peut repousser le geek habitué à faire des choses complexes en trois caractères et demi, le rend bien plus lisible des années après. Même si il est codé moyennement. Du code immonde sera toujours immonde, mais du code à peine moyen sera quand même assez lisible, alors que dans des langages objets, j'ai tendance à trouver que du code moyen est vite incompréhensible.

Tous ces petits trucs, et quelques autres, mis bout à bout expliquent pourquoi tous les projets de refonte en profondeur échouent. Par contre, certaines boites font de la guérilla en pelures d'oignon, pour se rapprocher chaque années un tout petit peu du noyau, et c'est à mon sens la bonne stratégie. Mais même eux, quand ils s'approchent trop du noyau, se crament. Ce n'est pas un hasard. Je ne dis pas que c'est infaisable, hein. Je dis juste que l'approche qui consiste à dire "yaka mettre un langage moderne et virer toutes ces vieilleries" sans comprendres ce que sont réellement lesdites vieilleries ne marche pas. Et a déjà couté des sommes délirantes.
6  0 
Avatar de mitteljc
Membre à l'essai https://www.developpez.com
Le 19/10/2018 à 11:28
Cela fait plus de 30 ans que je suis dans l'informatique. Régulièrement on nous fait cette annonce et il est toujours là, et bien là. On oublie de parler de sa robustesse et de sa très faible vulnérabilité aux attaques pirates, ce qui financièrement n'est pas négligeable. J'ai aussi des applications datant de mes débuts et étant encore souvent sollicitées. Peut-on en dire autant d'un autre système ?
6  0 
Avatar de Gwilherm
Futur Membre du Club https://www.developpez.com
Le 12/10/2018 à 17:23
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...
5  0 
Avatar de benjani13
Membre extrêmement actif https://www.developpez.com
Le 12/10/2018 à 19:41
Citation Envoyé par 4sStylZ Voir le message
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.
5  0 
Avatar de sirthie
Membre éprouvé https://www.developpez.com
Le 13/10/2018 à 12:59
Je rêve ! Personne n'a évoqué les secrets industriels ?

Est-ce que des entreprises comme Arianespace, Airbus, Dassault, etc. doivent tout mettre "dans le cloud" ? Perso, avec les piratages récents, j'hésiterais.

Certes, un mainframe connecté à internet peut tout aussi bien être piraté, mais ça, ça dépend (entre autres) des moyens de protection déployés par l'entreprise.
5  0 
Avatar de Darkzinus
Expert éminent sénior https://www.developpez.com
Le 12/10/2018 à 12:14
Quand ils chiffreront les coûts de migration (et les risques) je ne suis pas certain que le pourcentage sera aussi élevé.
6  2 
Avatar de 4sStylZ
Membre éprouvé https://www.developpez.com
Le 12/10/2018 à 16:46
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…
4  0 
Avatar de Escapetiger
Expert éminent sénior https://www.developpez.com
Le 18/10/2018 à 19:57
Citation Envoyé par Ryu2000 Voir le message
Un jour il n'y aura plus de développeur COBOL, donc il faut bien passer à autre chose ^^
Pour recadrer les faits, lu dans ce rapport de décembre 2013 :
Gary Barnett, directeur de la recherche chez Ovum estime que 90 % de toutes les transactions financière et 75 % de l’ensemble des transactions dans le monde allant du retrait d’argent à un DAB, à la réservation d’un billet d’avion ou à la saisie d’une facture se font à l’aide de programmes écrits en Cobol. Il évalue le nombre des transactions quotidiennes supportées par un programme écrit en Cobol à 30 milliards.
Source: http://rapportsalzman.blogspot.com/2...-pas-mort.html
Rapport Salzman: Le Cobol n’est toujours pas mort

... et puisque nous avons de l'humour également :
A Cobol programmer made so much money doing Y2K remediation that he was able to have himself cryogenically frozen when he died. One day in the future, he was unexpectedly resurrected.

When he asked why he was unfrozen, he was told:

"It's the year 9999 - and you know Cobol"
4  0