Présentation faite au GUEPARD (09 Octobre 2012) sur la migration automatisée PacBase -> UML + Java en 2 temps : (a) sortie iso-fonctionnelle et automatique du mainframe via transcodage Cobol puis (b) import référentiel PacBase dans Enterprise Architect et génération Java

1. migration PacBase → UML /Java
association Guépard – 09 octobre 2012
Paris
didier durand
didier.durand@eranea.com

2. eranea
➢ basée à Lausanne, Suisse
➢ spécialisée dans la migration automatique et iso-fonctionnelle des
applications métier vers Linux et Java
➢ multiples références pour technologie : banque, média, assurance,
distribution, édition logiciel, etc.
➢ projet de référence : grande banque privée (Genève) :
 système de « core banking » (10M lignes de Cobol) migré 100 %
automatiquement et iso-fonctionnellement vers Linux et Java
 mainframes z/OS : 2'500 Mips, CICS, VSAM, DB2, MQ, Sysplex

3. agenda
➢ PacBase → Java / UML : étapes successives
➢ point de départ
➢ motivations du projet
➢ acteurs et attentes
➢ palette de solutions
➢ cible optimale
➢ technologie et méthodologie
➢ bénéfices, conclusions (1)
➢ PacBase → UML : comment + conclusion (2)

4. PacBase → UML / Java : 2 étapes
référentiel
PacBase
générateur transcodeur
modèle
Cobol
Cobol Java
Java tomcat
PacBase
Transcodage Cobol → Java dès
aujourd'hui !
économies massives rapides
+ partenaire + modernisation plate-forme & UI
Nécessairement postérieur à l'arrêt mainframe
(quand Cobol n'est plus nécessaire)
modèle
générateur
PacBase
Java
Java tomcat
modèle rétro-
UML ingénierie
Migration modèle PacBase → UML
référentiel
économies outils développement
multi-modèles + modernisation méthodes en cours

5. point de départ
➢ une grande application critique au métier du client
➢ encapsulant tout son savoir-faire, solidement
éprouvée sur des décennies
➢ représentant de lourds investissements (10s voire
100s d'années-hommes)
➢ en route vers l'obsolescence technologique
➢ sur un système opérationnel (très) cher comparé
aux standards 2012

6. motivations
➢ des économies en investissements (capex) et frais de
tactique
fonctionnement (opex) massives
➢ une mutation technologique vers les standards actuels:

technologies Web, interface RIA
 architecture technique: SOA, Java, Linux
stratégique
 productivité: IDE, tests automatisés, QA des sources,
 code coverage, etc
 N.B.: abandon des anciennes technologies
➢
via solution eranea, les 2 en même temps !

7. motivations - exemple
100% = approx. 5 millions CHF/an
100%
➢ logiciel trop cher →
logiciels tiers environnement compétitif
90%
base + tiers nécessaire
80%
70% ➢ passage à OSS :
60%
logiciels IBM
 -70 % sur la facture
50% (z/OS, Cics, DB2, etc..) logicielle
40%
30%
 possibilité de
20% Périphériques changement HW
10%
Cpu

8. agenda
➢ PacBase → Java / UML : étapes successives
➢ point de départ
➢ motivations du projet
➢ acteurs et attentes
➢ palette de solutions
➢ cible optimale
➢ technologie et méthodologie
➢ bénéfices, conclusions (1)
➢ PacBase → UML : comment + conclusion (2)

9. acteurs et attentes (1)
➢ utilisateurs finaux :
 économies → informatique trop chère
 pas de gêne ni de formation
➢ CIO :
 acquérir agilité et indépendance
 moderniser et améliorer
 réduire les coûts d'exploitations
 pas de risques pour la société … et lui

10. acteurs et attentes (2)
➢ développeurs, ingénieurs système :
 nouvelles compétences
 meilleure efficacité et productivité
 « et mon job ? » …
➢ architectes
 modernisation
 pérennité

11. agenda
➢ PacBase → Java / UML : étapes successives
➢ point de départ
➢ motivations du projet
➢ acteurs et attentes
➢ palette de solutions
➢ cible optimale
➢ technologie et méthodologie
➢ bénéfices, conclusions (1)
➢ PacBase → UML : comment + conclusion (2)

12. palette de solutions mutation
totale
solution appl.
éditeur dérivée DB
niveau 4
sur Linux
niveau 3 Java AS
sur Linux
Cobol → Java
niveau 2
CICS → Java AS
autres : identiques
différentes étapes
appl. Cobol → Java d'un
niveau 1
originale autres : identiques même projet
<>
différents projets

13. agenda
➢ PacBase → Java / UML : étapes successives
➢ point de départ
➢ motivations du projet
➢ acteurs et attentes
➢ palette de solutions
➢ cible optimale
➢ technologie et méthodologie
➢ bénéfices, conclusions (1)
➢ PacBase → UML : comment + conclusion (2)

14. cible optimale (1)
➢ devise Java → « write once, run anywhere »
 solution adaptable à tout système Java
➢ technologie eranea déjà testée sur
 linux, windows, z/Linux, z/OS, aix, solaris, etc.
➢ mais, il existe une cible optimale :
→ linux sur serveurs x86

15. cible optimale (2)
➢ architecture x86 → x1'000'000 en 40
ans
➢ x86 rivalise avec les meilleurs
processeurs propriétaires
➢ architecture exclusive chez Google,
Facebook, Twitter, etc.
➢ cf benchmark TPC-C : meilleur ratio
prix / performance
➢ projet eranea: 2 serveurs bi-
processeur pour 750'000 trans/j

16. cible optimale (3)
➢ x86 domine le
marché en $ ( > 2/3)
➢ … et en volume !
 10'000 système z
actifs (3 ans de vie)
 9 millions serveurs
x86 vendus par an
 ratio 1 / 300'000

17. cible optimale (4)
➢ linux en croissance
permanente
➢ OS propriétaires
Windows = prédominance
disparaissent
des
serveurs bureautiques
➢ références Linux :
London Stock Exchange,
NYSE, Euronext, etc.
➢ pour les « 3S » : Speed,
Stability, Security

18. agenda
➢ PacBase → Java / UML : étapes successives
➢ point de départ
➢ motivations du projet
➢ acteurs et attentes
➢ palette de solutions
➢ cible optimale
➢ technologie et méthodologie
➢ bénéfices, conclusions (1)
➢ PacBase → UML : comment + conclusion (2)

19. technologie et méthodologie (1)
➢ migration rapide et peu coûteuse :
 transcodage Cobol → Java 100% automatique
➢ risques quasi-nuls :
 construction // ancien et nouveau système
 partage de la même base de données ( « iso-
fonctionnalité » 100%)
 tests automatisés récurrents

20. technologie et méthodologie (2)
➢ adaptation minimale des développeurs :
 code Java généré bien connu → iso-structurel et
iso-syntaxique
➢ gêne réduite des utilisateurs:
 aucun décalage fonctionnel → transcodage
quotidien
 formation minimale (nulle?) → iso-fonctionnalité

21. transcodage 100% automatique
➢ répétable sans coûts humains additionnels :
 fréquence quotidienne possible
 N.B. : 1% de changement manuel sur 10 millions de ligne =
100'000 lignes !
➢ très rapide
 1 million de lignes → 4 minutes
➢ adaptations et améliorations faciles à l'échelle globale
 durant tout le projet !
 exemple : un web service (SOAP) généré par traitement
➢ qualité toujours identique

22. iso-fonctionnalité & -structure (1)
➢ cible du projet 100 % claire
➢ pas de mélange fonctionnel <> technologique
➢ construction :
 ancien et nouveau systèmes collaborent
 partage même base de données

23. iso-fonctionnalité & -structure (2)
➢ effort d'adaptation minimal
 syntaxe similaire
 structure des programmes préservée
➢ signe clair aux développeurs :
 leur job continue !
 ils sont aidés pour la transition

24. exemple avant <> après (1)
➢ référence : projet dans groupe média suisse
➢ contexte applicatif:
 20+ applications "maison" de gestion des
commandes / ordres d'insertion dans la presse
 1'500 utilisateurs internes, 750'000 transactions /jour
& 800'000 pages /mois
 400 travaux nocturnes en batch, 270 types de
documents
 500 écrans applicatifs / 1'500 tables relationnelles

25. exemple avant <> après (2)
➢ avant:
 mainframe IBM z800 (350 mips) z/OS / CICS / COBOL / DB2
 réseau TCP/IP / émulation TN3270
 4 millions de lignes de Cobol à transcoder (2'150 programmes)
➢ après:
 cluster de serveurs Intel sous linux (Redhat) /Java / apache
tomcat / UDB
 500 écrans html (+ Javascript / AJAX & CSS), 1'500 tables
relationnelles
 4 millions de lignes de Java

26. outils : transcodeur & runtime
Cobol NeaTranscoder
pgm
Cobol Lexical Syntax Semantics Code
copy Analysis Analysis Analysis Generation
BMS
desc
NeaRuntime
Java XML
Program Screen Online
(incl SQL)
“Cobol” support
SQL support
SOA
Internal
DBMS Object Display support
implementation
CICS Emulation
Tracing / logging
Batch

27. intégration continue
Application “historique”
+
Base de données
1. échanges automatisés
via «clonage»
symétrique et traçable
Moteur Moteur
CI CI
Internet
VPN
Entrepôt DB Entrepôt DB
sources ERIT 2. copie (partielle) sources ERIT
des assets propriétaires
Integrate 3. réplication des Integrate
processus
et systèmes
Client Eranea

28. migration (très) progressive
Java
becomes
activity reference
tomcat
• 100% of data on DB2
• Cobol remains reference
100%
migration to new
Java
DRDA
instantaneous progressive on Tomcat
data
way back
migration
DB
to old system
Cobol
on Cics
CICS DB2
0% time
6-9 2-3
months months
mainframe
switched
off
pas de Big Bang = clef du succès !!

29. capture et replay des tests
3270
CICS DB2 COBOL
(1)
XML transcoder or
screen run-time or Cobol
data bug fixes
(2)
(4)
XML
screen
when (1) & (3) different
data XML
screen (3)
data
Tomcat
HTML

30. agenda
➢ PacBase → Java / UML : étapes successives
➢ point de départ
➢ motivations du projet
➢ acteurs et attentes
➢ palette de solutions
➢ cible optimale
➢ technologie et méthodologie
➢ bénéfices, conclusions (1)
➢ PacBase → UML : comment + conclusion (2)

31. bénéfices (1)
➢ économies massives
 habituellement > 70 %
 > 90 % dans les cas favorables (mainframe → x86)
 exemple : 4.5 millions CHF / 5 → groupe média
➢ modernisation directe et « co-latérale »
 langage Java, interface html/ajax (GWT)
 génération de web services (SOAP), SOA généralisée
 généralisation PDF, système archivage (CMS) Open Source, etc.

32. bénéfices (2)
➢ synergie :
 abandon des technologies obsolètes
 unification des équipes système
➢ augmentation de la productivité :
 code mining et reporting : Integrate d'Eranea
 IDE moderne (Eclipse)
• saisie assistée, debugging interactif, fonctions QA
 outils de pilotage graphiques (Webmin, etc.)

33. bénéfices (3)
➢ nouvelles possibilités architecturales :
 croissance horizontale par ajout de serveurs
 incrément de croissance faible → décisions faciles
 fonctions haute disponibilité et Disaster Recovery
nettement moins chères :
→ groupe média : création de site de DR interne
 isolation des fonctions : serveur DB <> serveurs
TP <> serveurs batch

34. acteurs et attentes (bis)
➢ utilisateurs finaux :
 pas de dérangement et peu de formation
➢ CIO, architectes :
 système moderne et flexible, retour aux standards
 modernisation forte : réalisée + latente
 fortes économies
 absence de risques
➢ développeurs, ingénieurs
 nouvelles compétences
 effort d'adaptation limité
 pérennité de l'emploi

35. conclusion (1)
➢ un tel projet offre une double opportunité (unique?)
à votre société :
 économies massives et modernisation forte
simultanément
 auto-financement et ROI bref
➢ la stratégie sous-jacente est déterminante :
 vitesse de réalisation <> volume de modernisation
➢ la tactique d'exécution est clef :
 absence de risques, adhésion interne, etc.

36. agenda
➢ PacBase → Java / UML : étapes successives
➢ point de départ
➢ motivations du projet
➢ acteurs et attentes
➢ palette de solutions
➢ cible optimale
➢ technologie et méthodologie
➢ bénéfices, conclusions (1)
➢ PacBase → UML : comment + conclusion (2)

37. PacBase → UML / Java : 2 étapes
référentiel
PacBase
générateur transcodeur
modèle
Cobol
Cobol Java
Java tomcat
PacBase
Transcodage Cobol → Java dès
aujourd'hui !
économies massives rapides
+ partenaire + modernisation plate-forme & UI
modèle
générateur
PacBase
Java
Java tomcat
modèle rétro-
UML ingénierie
Migration modèle PacBase → UML
référentiel
économies outils développement
multi-modèles + modernisation méthodes en cours

38. modèle PacBase
➢ Un énorme investissement des clients à préserver et à valoriser dans
les mondes Objet et Java
➢ Une modélisation objet avant l'heure :
 Rubrique PacBase= objet de base avec type physique mais surtout
signification métier → classe Java
 Segment / Structure de Données = Bean (au sens Java) incluant les objets
de base → classe Java
 chaque entité de base du modèle PacBase peut devenir très simplement
une classe du monde Java / UML
➢ Proximité avec le standard UML : le modèle PacBase permet de
dériver aisément les composants fondamentaux UML
 diagramme de classes :
 diagramme de séquence
 diagrammes de communication
 etc.

39. Enterprise Architect (EA)
➢ développé par SparxSystems
➢ > 300'000 utilisateurs dans le monde
➢ France : forte communauté + écosystème :
 Atos, CapGemini, Sopra, Armée française, Casino, Alcatel, Airbus, Renault
➢ système complet de modélisation (BPMN, UML, BPEL, etc.) avec
référentiel
 s'applique à tout le cycle de développement
 fonctionne avec de grandes équipes
 intègre aussi la gestion de projet
 forte intégration Eclipse / portabilité Windows, Linux

40. transposition PacBase → UML
Prototype
modèle EA
partiel

41. génération java
➢ Modèle PacBase très objet → génération Java
très « canonique » :
 classes Beans d’agrégation pour les données
 une vraie hiérarchie d'objets métiers
 classe séparée par programme, écran
➢ Appui sur NeaRuntime pour préserver l'iso-
fonctionnalité : structures de données Cobol
➢ fonction rétro-ingénierie EA pour enrichir le
modèle UML déduit du modèle PacBase

42. conclusion (2)
➢ Le transcodage est utilisable dès aujourd'hui pour
• faire des économies très massives : jusqu'à 90%
• moderniser la plate-forme technologique et les fonctions utilisateurs
(UI) → profiter de l'innovation permanente des géants Internet dans
l'infrastructure
• la mise en place est transparente pour les développeurs
➢ la transposition vers UML intervient ensuite (quand le Cobol
n'est plus nécessaire pour mainframe) :
• modernisation des outils et méthodes
• augmentation de la productivité
• économies complémentaires
• la transition doit être préparée : formations, etc.

43. merci !
des questions ?
Didier DURAND
didier.durand@eranea.com
+41 79 944 37 10
eranea SA
chemin de Mornex
1001, Lausanne (Suisse)