Le contexte actuel
Dans le contexte de crise et de mondialisation actuel les fusions de sociétés sont courantes. Les demandes de nouvelles fonctionnalités ou d’intégration de nouveaux services sont récurrentes. De plus, comme partout, la réduction et le contrôle des couts reste une priorité et le DSI doit justifier tout budget.
Tout cela génère beaucoup de travail pour les services informatiques et rarement plus de moyens.
Un peu d’histoire
Toutes les sociétés n’ont pas le même historique informatique. Les grandes entreprises et les gouvernements ont été les premiers à utiliser l’outil informatique très souvent pour remplacer la mécanographie et les cartes perforées. C’était la « grande » époque des mainframes IBM, BULL, ICL des langages COBOL, PL1, GAP …
Toutes ces applications développées entre 1965 et 1990 sont devenues le cœur du SI, depuis leurs lancements elles ont souvent été modifiées et les équipes de développement ont changé. De plus les technologies ont également évolués, on est passé aux bases de données relationnelles pour remplacer les fichiers ou les bases de données hiérarchiques, on découvre la programmation structurée.
Aujourd’hui ces applications sont parfois encore en « activité », elles ont vieilli et sont souvent mal documentées. La moindre modification devient vite dangereuse et le cœur du SI peut alors être sclérosé. Il devient urgent de faire évoluer cela, de moderniser le SI.
Migrer Pourquoi ?
Un DSI à besoin de raisons précises pour lancer un tel chantier, on ne se lance pas dans un projet pour essayer une technologie mais plutôt pour :
- Réduction des coûts – Cela fait toujours plaisir. Si on dit que le ROI d’un projet est de 3 ans ou même moins vous avez beaucoup de chance d’intéresser la direction générale.
- Technologies Obsolètes – Cela ne semble pas avoir un impact directe pour la DSI mais par contre cela génère une prise de risque importante. Ces technologies peuvent disparaitre ou ne plus être supportées (GCOS, PacBase, …) et la main d’œuvre les maitrisant est, également, en voie de disparition.
- SI mal maîtrisé, obsolète ou sclérosé – C’est une conséquence d’un SI vieillissant et cela génère une prise de risque très importante et une lenteur de réaction du développement.
- Disparition des compétences – Aujourd’hui les jeunes diplômés sortent rarement d’école avec des compétence dans les architectures Mainframe cela augmente les difficulté et les couts de recrutement.
Scénarii de modernisation/migration (applicatif)
Comme toujours vous avez diverses solutions pour réagir à ce problème. Le choix se fait en fonction de l’urgence de ce changement, le budget, les compétences internes, …
- Ne rien faire (on attend la retraite…) : cela implique d’avoir une maitrise encore importante de l’existant et aucune date butoir (trop proche).
- Front-End Web ou Re-vamping : la demande de modernisation vient surtout des utilisateurs qui trouvent leurs interfaces (3270, 5250, …) vieillottes. Cela permet de relooker vos applications rapidement et d’intégrer cela dans votre portail intranet.
- Attention au choix de l’outil de revamping (cela ne doit pas générer une double maintenance)
- ++ rapide à réaliser
- ++ iso fonctionnel
- + modernisation réelle de l’interface utilisateur
- + peu de modification des habitudes utilisateurs
- – Pas de diminutions de coûts
- – Pas de gains dans la rapidité de développement
- Re-Hosting : Vous changez la plate forme hébergeant vos applications en limitant au maximum l’impact sur le code.
- ++ iso fonctionnel
- ++ rapide a réaliser
- – Pas de véritable modernisation dans l’applicatif
- – Pas ou peu de gain dans les développements futur
- Progiciel : Si cela est possible cela peut être un très bon choix mais implique
- -/+ Avant tout standardiser les besoins : autrement le coût/temps de paramétrage du progiciel deviendra trop important
- ++ faible charge de développement (après la mise en place)
- ++ standardisation
- – reprise de données importantes à prévoir
- – changements importants des habitudes utilisateurs
- - coûts initiaux importants
- - Perte de contrôle vous ne maitrisez plus le développement
- Etudier dès le départ les possibilités d’intégration avec d’autres outils
- Vérifier la pérennité de la société, du produit
- SOA Mise en place d’une Architecture Orientée Services. Cela est normalement lié à une re-écriture.
- ++ Capitalisation des services
- ++ Réutilisation
- – Coûts importants
- - Architecture complexe
- Re-Ecrire Il est alors conseillé (mais pas obligatoire) de regarder également le coté SOA.
- + Maîtrise complète de la solution
- – Coûts important
- – Analyse très importante
- Prévoir des projets pilotes courts (1ans)
Le projet de « modernisation » :
Un projet de modernisation c’est un état des lieux du SI existant (l’origine), une définition du SI idéal (la cible), et comment y parvenir (la route ou les routes).
Cet article parle principalement de « modernisation Applicative » mais le projet doit être effectué sur 3 niveaux (très dépendants les uns des autres) :
– Applicatif
– Matériel (serveurs, réseaux, disques, …)
– Humain (il faut également identifier le chemin à parcourir pour les équipes informatique et les utilisateurs pour atteindre cette cible)
Ne pas oublier que dans bien des cas plusieurs solutions différentes seront choisies pour moderniser l’ensemble du SI. Le projet sera un mixte d’intégration de progiciels, de développements spécifiques (le reHosting / reVamping sont alors des solutions temporaires pour abandonner plus rapidement le mainframe ou uniformiser l’interface utilisateur). Cela s’étend sur plusieurs années et il faut obligatoirement faire évoluer le projet initiale en fonction de ses retours d’expériences ou des évolutions du marché.
Cette solution sera plus viable et fiable si ses choix techniques sont homogènes et pérennes .
Prochainement…
J’essayerai de donner des suites à ce premier article en vous parlant des thèmes suivants :
- Cartographie du SI
- Conversion Cobol / Java
- Ré-Ecriture
- Revamping 3270
Bonjour,
Connaissez-vous des outils de front-end web en solution libre qui soient customisables ?
De vraiment liee au monde mainframe vous avez NACA en open source mais il ne gere pas que le front-end.
Pour le reste je dirais que cela depend de ce que vous avez en back-end et des protocoles d’echanges entre les deux.
En front-end j’ai teste et utilisé Crysalid qui fait un excellent revamping (et meme bien pus) mais c ‘est payant et cela ne modernise que l’interface.
Tout depend de votre projet de la manière dont vous souhaitez moderniser .
Bonjour,
connaissez-vous des entreprises ayant quitté le MF avec succès?
Oui, et heureusement !
Le mainframe est un très bon système mais il est possible de le quitter.
Je connais plusieurs sociétés ayant changé de plateforme avec succès (parfois avec quelques douleurs tout de même). Par exemple dans le monde hospitalier (en passant souvent de développement spécifique à de progiciels spécialisés).
Je pense que la clef d’un projet de migration réussi est :
– Se donner le temps de le faire (ne pas migrer en catastrophe suite a l’abandon d’un logiciel)
– Connaitre l’existant (d’où l’importance de la cartographie)
– Impacter ses utilisateurs, ils ne doivent pas avoir l’impression que c est un projet purement technique. Cela doit apporter un plus.
– Former ses équipes et ses utilisateurs (conduite au changement très importante)
Bonjour,
Je voudrais savoir si la virtualisation pouvait être considérée comme une solution de modernisation ? puisqu’il est possible de virtualiser les systèmes d’exploitation des mainframes et ainsi faciliter les migrations.
Si oui, quels seraient les avantages et les inconvénients de cette solution.
Merci d’avance pour vos éclaircissements
Actuellement, je en connais pas de solution de virtualisation Mainframe (MVS, VSE) qui soit supportée par IBM.
Les émulateurs de type « Hercule » fonctionnent mais il n’y a pas (à ma connaissance) de support IBM sur cela.
Par contre si vous pensez à une solution de re-hosting unix ou windows sur des machines virtuelles cela ne doit pas poser de probleme.
Mais dans le cas d’une solution de re-hosting, les applications qui passeront sur une machine virtuelle devront avoir été adaptées pour être compatibles avec autre chose que leur mainframe ? la virtualisation apporterait-elle de réels avantages dans ce cas-ci ? car on pourrait simplement migrer les applications sur des machines Unix ou Windows physiques.
En ce qui concerne la modernisation des applications en générale (pas seulement mainframe),j’ai lu que certaines entreprises se tourneraient vers la virtualisation pour remplacer les postes x86 (utilisé en moyenne à 15%) et ainsi mieux répartir la charge et la puissance de calcul.
Cela reste pour moi une solution de rehosting même si elle est améliorée.
Dernière question : le cloud computing peut-il être considéré comme une solution de modernisation des applications ?
Merci d’avance
Oui dans tous les cas (sauf les emulateurs qui ne sont pas supportés par IBM), il y a un travail important pour adapter les applications à la nouvelle cible.
Cela implique souvent de : changer de base de données, de système d’exploitation , de moniteur TP, d’ordonnanceur pour les batchs…
La virtualisation concernant les serveurs (Windows, Linux, ..) de l’entreprise est à mon avis une très bonne chose permettant de faciliter l’administration, le remplacement des ce serveurs, et de lisser/d’équilibrer la charge.
En ce qui concerne la virtualisation du poste client, j’ai personnellement un doute de l’utilité (un passage a une ferme de Citrix ou autre reste très complexe, le poste client existe toujours).
Pour le poste client je pense que la meilleur solution consiste a banaliser celui ci en favorisant le développement des applications Web en creant un bureau virtuel.
Pour le Cloud computing, je ne me suis pas vraiment intéressé a cela donc je préfère ne rien dire…
Bonne suite
Bonjour,
Vous avez cité la modernisation des applications dans le monde hospitalier, avez-vous des noms de progiciels spécialisés dans le monde hospitalier ?
Merci
Oui bien sur vous avez (de mémoire…)
- Clinicom de Siemens
- Noyau Reference de McKesson HBOC
- Symphonie Online ( de ? )
Il en existe beaucoup d’autre et le choix d’un produit, ou plus souvent de l’intégration de plusieurs produits se fera suivant la taille de l’établissement, la couverture fonctionnelle recherchée, le budget, et bien sur l’existant…
Le plus souvent vous aurez « n » briques separés en deux groupes
– applications administratives (compta, paye, … ) qui ne sont pas centrées sur le patient
– appli centrées sur le patient ( facturation, dossier medical, rdv, pacs, ….)
Donc beaucoup de travail en perspective…
C’est une section anti-mainframe???
Connaissez-vous réellement le mainframe??? Vous êtes vous vraiment penché sur cette technologies et ses avantages? A vous lire, je ne crois pas.
Le mainframe est beaucoup plus fiable que les serveurs sur lesquels vous travaillez, c’est un fait et vous pourrez argumenter autant que vous voulez, je pense être en mesure de pouvoir vous contrer.
On se moque du Mainframe, il est vieillot!!! Je crois rire, quand je vois ce qui est fait sur Unix, avec vos petites fenêtres et ce superbe outil « VI », laissez moi rire. Le mainframe est bien plus convivial. En réalité, vous avez des à priori, c’est peut-être là votre tort et ce « qui cause notre perte ».
Quoiqu’il en soit, le mainframe se modernise et à encore de beaux jours devant lui. On peut faire à peu près tout ce que l’on veut sur du mainframe. De plus, les entreprises devraient se pencher de plus en plus vers cette technologies pour une raison principale, l’aspect financier. On entend dire le mainframe coûte cher, c’est ce que l’on pourrait croire, mais si vous comptez le nombre de serveurs dans vos entreprises, l’hébergement, la consommation électrique, le nombre d’administrateurs pour gérer le parc, le coût de la maintenance… Vous êtes certains que le mainframe coûte cher???
Pour finir, je dirais qu’il n’y a vraiment pas besoin de changer de technologie pour moderniser les applications.
Anti-Mainframe… Non au contraire , je travaille dans ce monde depuis plus de 20 ans et je pense bien maitriser cet environnement ( Cobol, DL1, DB2, CICS, CPIC, BMS, zOS, VSE, …). J’ai connu plusieurs arrêts de sites MVS ou VSE (mais 0 ouverture ou re-ouverture).
Oui l’architecture mainframe est excellente et offre un très grande stabilité. Mes principaux griefs sont :
- En 20 ans je n’ai pas vu évoluer les outils de développement mainframe.
- Idem concernant l’ergonomie des interfaces 3270
- Certains outils mainframe n’évoluent PLUS (DB2-SQL/DS sous VSE est une pièce de musé pas d’alias, pas de jointure ouverte, des perfs moyennes).
- Beaucoup d’outils de bases sont en options ( débogueur, fileaid, gestionnaire de source, …)
- très peu de compétence du coté des jeunes diplômés
VI est effectivement vieillot et pour cause il est à mon avis au moins aussi vieux que Xedit (j’ai pas vérifié). Mais VI comme XEDIT sont tous les deux d’excellents éditeurs.
MVS se modernise effectivement, il s’ouvre surtout à d’autres technologies (TCP-IP, Java, Websphere , zLinux, …) et communique très bien vers les systèmes dis « ouvert ».
Concernant le cout chaque DSI doit effectuer sa propre étude pour évaluer de quel coté penche la balance mais je pense que cela sera toujours vers Unix (en restant cohérent bien sur, c’est à dire utilisation de système ESX ou équivalent, limiter les versions différentes d’Unix, de langages ou de bases de données, ….).
PS : Je ne comprend vraiment pas ce que vous trouvez d’anti-mainframe dans cet article…
Pourquoi pas de sujet sur migration inverse ?
Le mainframe est quand-même plus intéressant que ces plateformes Unix, Java, J2EE …
Ce que savent faire ces plateformes, le mainframe peut aussi le faire et sait faire bien plus et bien mieux.
Si beaucoup d’entreprises reviennent sur le mainframe, ce n’est pas pour rien !
J’ai même rencontré des drôles de gens qui voulaient nous vendre une ‘moulinette’ pour transformer des applis COBOL/CICS/DB2 en Java/Oracle/Linux ! Le problème c’est qu’il aurait fallu investir sur des serveurs énormes qui revenaient encore plus cher qu’un mainframe ! Et ce, sans engagement de résultats !!!!
Je me marre ….
Pourquoi pas la migration inverse, tout simplement parce que je suis jamais tombé sur une société souhaitant faire cela.
Cela fait plus de 20 ans que je travaille dans les environnements mainframe et durant cette période j’ai vu certain système disparaitre complètement. Aujourd’hui mis à part MVS – z/OS il ne reste plus grand chose.
Je ne dis pas que le mainframe est inintéressant bien au contraire. Par contre pour dire que les plateformes Unix, Java le sont cela implique que vous ne connaissez pas vraiment cela.
J’ai testé avec succès certaines de ces moulinettes et on arrive normalement à faire tourner cela sur un serveur standard (aucun problème sur les « gros » batchs ni sur CICS bien que le paramétrage soit plus complexe). De plus le cout de la plateforme matériel est secondaire c’est plutôt la facture logiciel qui est lourde coté mainframe.
Je vous invite à regarder Naca 3 (concernant ces moulinettes) .
N’hésitez par à me contacter pour débattre de ce sujet …
Pacbase s’arrête, « bientôt ». Avez vous connaissance des offres de « migration » des patrimoines applicatifs ? Par « offre », j’entends « offre de service », pas solution technique (de type de celle proposée par IBM). Qui propose quoi en la matière ?
Bonjour,
Concernant les offres de « migration » Pacbase je ne suis pas vraiment au « top » car je ne suis pas directement impacté par une telle migration.
Je connais deux sociétés en cours de migration dont une (je crois) est en phase de d’activation de la plateforme cible (migration terminé). Par contre, je pense qu’une migration Pacbase reste principalement technique (Pacbase étant un outils purement technique que l’on doit remplacer par un autre)
L’offre de service dans le cadre d’un migration n’est pas lié à un outils mais plutot à une démarche méthodologique ( étude existant, définition cible, accompagnement, conduite au changement formation, carto, identification des risques, cela pouvant aller jusqu’à un engagement de réussite).
Bonjour,
Je souhaite apporter une réponse à propos de Pacbase. Pacbase est un AGL initialement porté par la CGI avant de se faire racheter par IBM, lequel arrête cet atelier de développement en 2015. La solution de continuité que nous proposons, Reptide (REPository, Transform, IDE) conserve ce qui a fait de Pacbase, un redoutable outil de développement mais encore plus redoutable dans le cadre des actes de maintenance. Cette solution moderne apporte, entre autre, une interface digne d’un développeur Mainframe moderne car s’exécutant dans un environnement Eclipse. Son dictionnaire simplifie la vie des utilisateurs, l’analyses d’impact de premier niveau est immédiates, les patterns de générations apportent la productivité que les Entreprises réclament de nos jours (plus vite, mieux et moins chère). Pour en savoir plus : http://www.metrixware.com !
Ajouter une réponse