Migration et Modernisation Mainframe

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