Le mainframe devient tendance

Le mainframe
devient tendance
Pour quelle raison intégrer les applications
legacy dans une démarche DevOps d’entreprise.
Comme tout le monde, vous êtes submergé d’information.
De ce fait, vous ne lisez probablement qu’une partie de ce
que vous recevez. Nous vous demandons néanmoins de
lire ce document avec attention, parce que nous croyons
sincèrement qu’il offre un point de vue unique, basé
sur des faits, facile à mettre en place et indispensable
au succès de n’importe quelle entreprise dotée d’un
mainframe. Nous vous demandons également de le lire
même si vous n’êtes pas actuellement responsable du
mainframe de votre entreprise. Car, comme nous le
défendons, remettre le mainframe dans la tendance
est l’affaire de tous.
Concepts clés
1)
Le temps presse pour les silo mainframe.
Les spécialistes du mainframe partent à la retraite,
et il y a peu de candidats pour les remplacer.
Pourtant, les applications mainframe restent
essentielles. L’IT a donc besoin d’une stratégie
viable pour maintenir et adapter rapidement le
code mainframe aux exigences en constante
évolution des entreprises.
2) L’IT doit réagir en rationalisant rapidement le
mainframe. Au lieu de continuer à dépendre
de spécialistes mainframe, l’IT doit octroyer
davantage de pouvoir au personnel DevOps pour
traiter le mainframe comme n’importe quelle
autre plateforme de l’entreprise multi-plateformes,
en utilisant les mêmes outils et procédés DevOps
qu’ils utilisent pour Java, les serveurs Linux x86,
le cloud, etc.
3) La rationalisation ne résout pas que le problème
du mainframe. Elle offre un avantage compétitif
à l’ensemble de l’entreprise digitale. Pour exceller
sur le marché digital, il ne suffit pas d’être grand.
Il faut également être rapide. Un environnement
DevOps d’entreprise qui soutient les bonnes
pratiques en matière d’agilité et de collaboration
sur toutes les plateformes, dont le mainframe,
est de ce fait un impératif concurrentiel.
LA FIN DU SILO MAINFRAME
Pendant des décennies, l’informatique a considéré le mainframe
comme un silo. Les équipes mainframe ont des compétences
différentes, utilisent des outils différents, emploient des méthodes
différentes et possèdent même une culture différente.
Ce compartimentage s’est produit pour des raisons
compréhensibles. Le mainframe, au cas où nous l’aurions oublié,
précède de beaucoup l’informatique distribuée. De ce fait, pendant
2
COMPUWARE CORPORATION | COMPUWARE.COM
de nombreuses années, il a été la seule occupation des équipes
informatiques. Lorsque l’informatique distribuée est apparue,
les équipes mainframe se sont inquiétées de la protection,
de la stabilité et de l’intégrité de leurs environnements. Et beaucoup
de ces inquiétudes, surtout celles qui concernent la fiabilité,
la complexité, les coûts et la sécurité, se sont révélées pertinentes.
Cependant, l’isolement qui a favorisé la stabilité du mainframe
et l’a maintenu en sécurité pendant des décennies de tumulte
technologique s’avère aujourd’hui être la cause de sa perte.
Le mainframe est devenu l’équivalent d’un culte secret auquel
n’assistent que ses prêcheurs bornés, à l’écart du monde des
infrastructures x86 grand public et du cloud, et indifférents à
celui-ci. Et la plupart des dirigeants informatiques ont aggravé la
situation en réduisant drastiquement les budgets mainframe, plutôt
que d’investir dans le développement d’applications mainframe.
Résultat : les environnements mainframe ne sont pas suffisamment
réactifs pour l’entreprise, non pas en raison d’une caractéristique
inhérente au mainframe en lui-même, mais plutôt en raison de la
façon dont il a été géré.
En outre, dans la mesure où le mainframe a été compartimenté
et négligé depuis si longtemps, peu d’informaticiens en dehors de
la sous-culture mainframe connaissent le COBOL ou comprennent
comment les MSU fonctionnent. Ils sont susceptibles d’écrire
du code qui recourt à DB2 dans le mainframe, mais la plateforme
en elle-même est totalement opaque pour eux.
Une approche compartimentée, non agile vers une trajectoire
mainframe DevOps n’est plus défendable pour plusieurs raisons,
dont les suivantes :
n Déperdition des compétences spécifiques au mainframe.
Les spécialistes mainframe, qui ont été en charge des
systèmes et applications, approchent de l’âge de la retraite.
Il est peu probable que les jeunes et talentueux informaticiens
souhaitent se consacrer à une carrière dans le monde isolé
du mainframe.
n Code irremplaçable. Les applications mainframe sont
tellement développées et enracinées dans l’entreprise qu’elles
sont indispensables. Et elles ne peuvent pratiquement pas
être déplacées sur une autre plateforme. Les entreprises
doivent donc trouver comment préserver à la fois leurs
applications et les systèmes mainframe pour au moins
la prochaine décennie voire au-delà, en dépit du départ
de leurs spécialistes mainframe.
n Dépendance inter-plateforme. La réussite d’une entreprise
dans le monde digital dépend en partie de la capacité des
équipes informatiques à réexploiter l’existant applicatif et
toutes les données disponibles dans l’entreprise, quels que
soient la plateforme et le langage de programmation. Les
entreprises doivent donc faire bien plus que conserver leurs
applications mainframe comme des processus indépendants.
Elles doivent également se développer de façon plus agressive
en tirant parti du code applicatif et des données mainframe,
conjointement à l’existant non-mainframe.
n Aller vite. Le rythme du développement mainframe ne peut
pas continuer à être plus lent que le reste de l’informatique.
Une grande réactivité est indispensable, surtout lorsqu’il
s’agit de contribuer aux applications mobiles clients. Des
méthodes DevOps lentes sur le mainframe entravent l’agilité
de l’entreprise de manière toxique et potentiellement mortelle.
Autrement dit, les entreprises ne doivent pas accepter le statu
quo du mainframe à un moment où les applications et les
données mainframe ainsi que la puissance de traitement sont plus
précieuses que jamais pour les entreprises. L’IT ne pourra fournir
à l’entreprise toutes les capacités numériques dont elle a besoin,
lorsqu’elle en a besoin, que si le mainframe est tout aussi agile et
accessible pour les développeurs, analystes de données et équipes
opérationnelles que les autres plateformes.
Tous les dirigeants informatiques doivent donc s’attaquer au
problème du mainframe résolument et sans délai, quels que
soient leurs préjugés et perceptions, et indépendamment du
fait qu’ils soient ou non directement responsables actuellement
du mainframe.
LE MAINFRAME DEVIENT TENDANCE
Le mainframe ne peut continuer à évoluer dans son silo. Mais l’IT
doit garantir son fonctionnement au quotidien, car ses applications
sont indispensables et ne peuvent pas fonctionner sur une autre
plateforme. Une seule conclusion logique : l’informatique doit
en fin de compte intégrer le mainframe dans une démarche
inter-plateformes DevOps.
Cette rationalisation doit s’attaquer aux 3 principales caractéristiques
du mainframe :
Les applications mainframe
Les applications mainframe existantes offrent sans doute aux
équipes informatiques leur objectif de rationalisation le plus
important et le plus exigeant.
Cet objectif est le plus important car :
1)
La logique applicative mainframe est extrêmement précieuse
pour l’entreprise.
2) Le changement de plateforme de cette logique applicative
Bref historique de
l’écosystème mainframe
L’IT a toujours lutté pour tirer profit des ressources
mainframe dans le contexte d’un mainframe
compartimenté. Cette bataille s’est déroulée
en cinq étapes successives :
s’est révélé très complexe.
Les applications mainframe existantes sont sans doute le sujet de
rationalisation le plus délicat pour les équipes informatiques car :
1)
Les applications mainframe fonctionnent depuis tellement
longtemps et ont été modifiées tellement souvent qu’elles
ne sont généralement plus très bien documentées, et parfois
même pas très bien comprises par les équipes informatiques.
2) La maîtrise de langages historiques tels que le COBOL,
ÉTAPE
1
ÉTAPE
2
ÉTAPE
3
ÉTAPE
4
ÉTAPE
5
Émulation des terminaux
Les équipes mainframe permettent aux
utilisateurs d’accéder aux applications et
aux données mainframe avec leurs PC
via du revamping ou d’autres techniques.
Appel aux applications
Les équipes mainframe permettent aux
applications distribuées d’accéder aux
données mainframe, aux applications et
aux transactions métiers, au cas par cas.
Monitoring global
Les équipes mainframe donnent
l’accès aux solutions de gestion
de la performance et d’anomalies
sur des environnements ciblés.
Analyse des données
Les équipes mainframe définissent les
règles de mise à disposition des données
aux principaux outils de BI, ouvrant la
porte au Big Data.
Mainstreaming
Les équipes DevOps possèdent les outils
et les méthodes nécessaires pour utiliser
la puissance du mainframe dans les
nouvelles stratégies digitales.
le PL/I et l’Assembleur tend à se faire plutôt rare.
La bonne nouvelle, c’est que le code, ça reste du code. De ce fait,
même si les développeurs de l’an 2000 ne sont peut-être pas
familiers de la syntaxe particulière du COBOL, les principes de
base de la logique applicative s’appliquent tout de même. Et étant
donnée l’adaptabilité des développeurs d’aujourd’hui pour ce qui
concerne l’apprentissage de nouveaux langages de programmation,
la fin de l’expertise en COBOL ne représente pas vraiment un
problème insurmontable pour les départements IT.
En fait, de nouveaux développeurs peuvent prendre en charge les
applications mainframe facilement, si on leur donne simplement
la capacité de :
n
Écrire, modifier, déboguer et gérer le code mainframe dans
leur IDE favori
n
Recevoir en temps réel des conseils et des préconisations
sur les problèmes de qualité pendant qu’ils codent
n
Tester le code mainframe dans les plateformes automatisées
et environnements qu’ils ont l’habitude d’utiliser
n
Mieux comprendre la logique applicative mainframe existante
par des représentations graphiques du fonctionnement
à l’exécution, des relations inter-programmes, etc.
En fin de compte, la normalisation du code applicatif mainframe
dans un environnement Devops élargi à l’entreprise permet aux
équipes IT de traiter le code mainframe comme n’importe quel
autre code au sein de n’importe quel projet agile. Et finalement
lui permettre de s’adapter aux exigences de l’entreprise sans
incompatibilité de rythme ou problème de coût.
3
COMPUWARE CORPORATION | COMPUWARE.COM
Contrairement aux applications, les données mainframe peuvent
au moins théoriquement changer de plateforme. Et il existe des
situations où il est avisé d’exporter certaines données mainframe
vers d’autres environnements pour faire évoluer des applications
ou pour des raisons analytiques.
Bien qu’en général, il est préférable de laisser les données mainframe
sur le mainframe. Parmi les raisons qui le justifient, on peut citer :
n
Une meilleure performance applicative
n
L’hébergement de données sur plusieurs plateformes
engendre des coûts qui peuvent être évités
n
Des exigences de sécurité, de conformité et/ou
de gouvernance
Cela dit, les données mainframe devraient toutefois être visibles
et compréhensibles pour tout développeur ou analyste actuel
dans la mesure où il dispose des autorisations adéquates. Ainsi,
comme pour le code mainframe, les directions IT doivent donner
au personnel non mainframe la capacité de découvrir et de
comprendre les données, métadonnées, leurs structures et liens
avec les programmes de façon intuitive. Et, une fois de plus, ceci
devrait idéalement être fait avec des outils qui leur sont familiers
(ex. : « projets » Java).
Exploitation mainframe
L’exploitation est un cas particulier pour cette rationalisation, car
à un certain niveau, toutes les opérations informatiques sont par
essence compartimentées. Différentes équipes techniques dotées
de différents outils et compétences gèrent les systèmes Linux
et Windows, l’infrastructure de stockage, les périphériques réseau,
les bases de données, les serveurs intermédiaires, etc. De ce fait,
l’IT continuera sans doute à dépendre de spécialistes des systèmes
z d’IBM pour mener à bien certaines tâches essentielles de gestion
et tuning du mainframe.
LE MAINFRAME EN SILO
Mainframe
DevOps
APPLICATIONS
COBOL,
PL/I, ETC.
DONNÉES
EBCDIC,
COMP-3, ETC.
PLATEFORME
z/OS, CPs,
zIIP, ETC.
INTÉGRATION FAIBLE/CONDITIONNÉE
Les données mainframe
APPLICATIONS
JAVA, PHP,
VBSCRIPT, ETC.
DONNÉES
DONNÉES
STRUCTURÉES,
NON
STRUCTURÉES,
IMAGES, ETC.
PLATEFORMES
WINDOWS,
LINUX,
VMWARE,
AZURE, AWS, ETC.
STABLE
AGILE
ÉVOLUTIF
COMPÉTENCES DISPONIBLES
HAUT RENDEMENT
INTÉGRATION CROSS-PLATEFORMES
PROCESSUS LENTS
NE PARTICIPE PAS AUX
ÉVOLUTIONS DU CŒUR DU MÉTIER
PÉNURIE DE COMPÉTENCES
ÉVOLUTIVITÉ COÛTEUSE
FAIBLE INTÉGRATION
PAS DE SYSTÈME TRANSACTIONNEL
À L’ÉCHELLE DE L’ENTREPRISE
Les organisations IT qui continueront à utiliser le mainframe en silo
perdront en réactivité et risqueront d’affaiblir leur cœur de métier.
LE MAINFRAME MAINSTREAM
DevOps
Mais, comme mentionné ci-dessus, les SLA dépendent souvent
de la combinaison de bout en bout de tous ces composants
séparés. Pour préserver ces SLA, l’IT doit plus globalement intégrer
l’exploitation mainframe dans l’exploitation d’entreprise. Cette
intégration se présente sous deux formes :
1)
APPLICATIONS
JAVA, PHP,
VBSCRIPT, COBOL,
PL/I, ETC.
DONNÉES
La gestion des données et des alertes émis par le mainframe
doit être intégrée dans les workflows au niveau entreprise.
DONNÉES
STRUCTURÉES,
NON STRUCTURÉES,
IMAGES, EBCDIC,
COMP-3, ETC.
2) Les techniciens d’exploitation doivent être capables
de descendre jusqu’au mainframe lorsqu’ils étudient les
problèmes concernant le niveau des services applicatifs et
sans avoir à dépendre de spécialistes des systèmes z d’IBM.
Certaines organisations IT ont déjà donné à leur personnel
d’exploitation mainframe une visibilité rudimentaire sur la santé de
certains processus et ressources mainframe. Mais l’intégration de
l’exploitation mainframe doit être portée beaucoup, beaucoup plus
loin si les entreprises veulent obtenir les avantages considérables
d’un véritable DevOps inter-plateformes.
Le principe clé de ces trois impératifs est que les professionnels
de l’IT soient capables de travailler sur le mainframe en utilisant
les outils et procédés qu’ils connaissent. Certes, l’IT doit
préserver l’intégrité de l’environnement mainframe. Mais le
mainframe ne peut continuer à être un élément isolé au sein
de l’entreprise. La responsabilité du mainframe doit en fin de
compte être transférée aux nouveaux développeurs, analystes
de données et professionnels de l’exploitation.
4
COMPUWARE CORPORATION | COMPUWARE.COM
PLATEFORMES
WINDOWS, LINUX,
VMWARE, AZURE, AWS
z/OS, CPs, zIIP, ETC.
AGILE
COMPÉTENCES DISPONIBLES
INTÉGRATION CROSS-PLATEFORMES
STABLE
ÉVOLUTIF
HAUT RENDEMENT
En permettant aux nouvelles générations de développeurs, aux analystes de données et aux
équipes opérationnelles d’interagir avec le mainframe, les organisations IT sont en mesure
d’embrasser l’évolution numérique et de garantir à long terme l’intégrité de leur cœur de métier.
UN BUSINESS CASE
DE LA RATIONALISATION
Les dirigeants IT ont beaucoup de travail devant eux. Il doit y avoir
des raisons décisives pour faire remonter la rationalisation du
mainframe en haut de la liste des tâches à accomplir en 2016.
Et elles le sont. Notamment les suivantes :
L’atténuation du risque mainframe
La fin imminente des compétences mainframe est un risque aussi sérieux pour les entreprises que l’était le
bogue de l’an 2000. La date du désastre n’est simplement pas fixée. Les entreprises qui continuent à différer
la résolution de ce problème verront au bout du compte s’évaporer la valeur de décennies d’investissement
dans une logique applicative cruciale pour l’entreprise.
Agilité indispensable de l’entreprise
Si vous ne pouvez pas modifier votre logique applicative mainframe rapidement et en toute confiance, votre
entreprise ne sera peut-être pas suffisamment agile pour faire face à la concurrence dans l’environnement
actuel du changement digital. Les entreprises doivent simplement intégrer la gestion du code mainframe
dans leurs cycles de développement et d’intégration continus/agiles.
Plus de valeur et une meilleure expérience client
Les entreprises sur tous les marchés ont besoin de tirer parti de l’information et des connaissances dont
elles disposent afin de faire davantage pour leurs clients que le font les concurrents. Une grande partie
de cette information et de ces connaissances réside sur le mainframe. Les entreprises qui ne peuvent
pas tirer parti immédiatement de ces informations et connaissances d parce que leurs mainframe sont
lents et fermés perdront invariablement des clients au profit de leurs concurrents plus agiles.
Conformité en plus grande confiance et avec moins de tensions
Les silos sont l’ennemi de la conformité. Ils empêchent de mettre en place des politiques communes
à toute l’entreprise et fragmentent le contrôle en des procédés qui augmentent les coûts et suscitent le
doute chez les auditeurs. En intégrant de façon globale le mainframe dans un environnement d’entreprise
plus large, l’IT peut unifier les processus de conformité pour optimiser la crédibilité tout en réduisant
les coûts.
Attirer les talents du nouveau siècle
Les organisations IT doivent attirer la nouvelle génération d’informaticiens compétents et motivés sur
des applications, données et opérations mainframe. Ce sera difficile à faire avec des outils et des processus
qui datent des années 1980.
Une informatique d’entreprise plus évolutive, fiable, sécurisée et rentable
Les plateformes systèmes z d’IBM sont un moyen formidable pour opérer toutes sortes de workloads
Linux et open source, particulièrement comparé à l’infrastructure x86 tentaculaire qui est effroyablement
complexe, peu fiable et coûteuse. En décompartimentant le mainframe, l’IT peut profiter de performances
et d’une fiabilité supérieures, d’une emprise au sol fixe et de surcoûts remarquablement bas.
Tôt ou tard, l’IT devra rationaliser le mainframe parce qu’elle n’a
pas vraiment le choix. Sa situation actuelle ne sera pas soutenable
encore très longtemps, et le mainframe ne peut pas être purement
et simplement supprimé. La rationalisation est la seule voie
possible. Et elle permet également de grandes opportunités
de développement.
Les applications mainframe sont irremplaçables et constituent
des actifs d’une valeur inestimable pour l’entreprise. L’informatique
bimodale les condamne à l’inutilité. L’intégration du mainframe
dans un DevOps d’entreprise, en revanche, garantit leur valeur sur
le long terme et optimise la capacité des grandes entreprises à être
compétitives et à réussir dans un monde de plus en plus digital.
5
COMPUWARE CORPORATION | COMPUWARE.COM
Aucun abandon de plateforme
Confrontés à l’importance des applications mainframe et à la
difficulté historique de rendre le mainframe entièrement agile,
plusieurs experts du secteur ont suggéré une « informatique
bimodale ». L’informatique bimodale, c’est en substance l’idée
que les entreprises devraient abandonner toute tentative de
rendre leur mainframe agile et devraient plutôt simplement
se segmenter en un « mode stable » et un « mode agile ».
Cette approche peut être tentante pour ceux qui reculent
devant la perspective de véritablement transformer le mainframe,
mais ce n’est pas une alternative viable pour plusieurs raisons :
n
L’agilité du mainframe est nécessaire à l’agilité
de l’entreprise.
Les améliorations de l’expérience digitale client dépendent
souvent de bases de données centrales, du traitement des
transactions et d’une logique d’entreprise très sophistiquée
qui se trouvent toujours dans le mainframe, et probablement
pour longtemps encore.
n
Stabilité et agilité ne sont pas incompatibles.
Suggérer que c’est le cas, c’est nier l’ensemble du
mouvement vers le DevOps, l’intégration continue, etc.
n
Choisir le statu quo par défaut n’est pas une stratégie
de différenciation concurrentielle.
S’il était facile de transférer les meilleures pratiques agiles
au mainframe, toutes les entreprises l’auraient déjà fait ;
mais cela ne leur offrirait pas pour autant un avantage
concurrentiel important.
n
A minima, le niveau de fiabilité, de performance et
de sécurité du mainframe est nécessaire, pas moins.
Il a été démontré que reproduire les qualités du mainframe
dans des environnements cloud/distribués s’est avéré
excessivement coûteux (et souvent impossible). L’IT doit
donc s’efforcer de mieux les exploiter, plutôt que de les
laisser se dégrader.
À PROPOS DE COMPUWARE
Compuware permet aux plus grandes entreprises mondiales d’exceller dans l’économie digitale en exploitant
pleinement la grande valeur de leurs investissements mainframe. Pour ce faire, nous fournissons des solutions
hautement innovantes qui permettent aux informaticiens de maîtriser les applications, données et l’exploitation
des applications et plateformes mainframe.
En savoir plus sur Compuware : compuware.com.
Compuware Corporation World Headquarters • One Campus Martius • Detroit, MI 48226-5099
© 2016 Compuware Corporation. Les produits et services de Compuware sont des marques commerciales
ou des marques déposées de Compuware Corporation. Java est une marque commerciale déposée d’Oracle
et/ou de ses filiales.
01.16 31287_Mainstreaming_the_Mainframe