présentation migration automatisee Pacbase -> UML + Java
1 j'aime5,534 vues
Le document présente un projet de migration de systèmes basés sur PACBASE vers Java et UML, dirigé par Eranea, une entreprise suisse spécialisée dans les migrations automatiques. Le projet vise à moderniser les applications critiques d'une grande banque privée tout en réalisant des économies substantielles et en évitant les risques associés à la transition technologique. Les principales motivations incluent la réduction des coûts d'exploitation, l'adoption de standards modernes et l'amélioration de la productivité à travers l'automatisation du processus de migration.
présentation migration automatisee Pacbase -> UML + 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)