Mutation technologique d'applications métier vers Linux & Java -  JUG Lausanne  - (09 février 2012)
Agenda <ul><li>Business case / Méthodologie </li><ul><li>Quoi ? Point de départ
Pourquoi ? Motivations </li><ul><li>Business case </li></ul><li>Où ? Cible optimale
Qui ? Les acteurs, leurs attentes
Quoi ? Continuum de solutions
Comment ? </li><ul><li>Technologie & méthodologie </li></ul><li>Bénéfices et conclusions </li></ul><li>Points technologiqu...
Cobol : quo vadis ?  Selon Microfocus : <ul><li>Chaque consommateur a 13 interactions quotidiennes avec des applications c...
220 milliards de lignes de Cobol actives : + 5 milliards chaque année
60 à 80 de l'activité des multinationales « repose » sur Cobol : 80% des transactions commerciales l'utilise
200 x plus de transactions Cobol que de requêtes Google chaque jour </li></ul>Source:  www.developpez.net
Retour d'expérience <ul><li>Basé essentiellement </li><ul><li>Sur un projet en cours avec grande banque privée genevoise :...
Sur un projet média terminé à 100%: 4.5 millions de lignes de Cobol + zOS + CICS + DB2
Sur un projet avec un éditeur de logiciel australien 100% terminé
Sur un projet avec assurance étrangère 100% terminé
Sur un projet avec une administration étrangère terminé à 75% </li></ul></ul><ul><li>Signalés par  dans les slides qui sui...
->  La méthodologie (automatisation, 3-iso, fonctionnement //, etc.)  est aussi voire plus  importante que la technologie ...
Quoi ?  Point de départ <ul><li>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 2011 </li></ul>
Pourquoi ? Motivations <ul><li>Des économies en investissements (capex) et frais de fonctionnement (opex) massives
Une mutation technologique vers les standards 2011:  </li><ul><ul><li>technologies Web, interface RIA
architecture technique: SOA, Java, Linux
productivité: IDE, tests automatisés, QA des sources, code coverage, etc
N.B. : abandon des anciennes technologies en fin de projet </li></ul></ul><li>Si possible les 2 en même temps ! </li></ul>
Business case  (projet média - 2003) <ul><li>Le  Logiciel Système  est le &quot;point chaud&quot;
Un environnement  plus compétitif  est impératif
Il aura un  impact positif  sur les logiciels tiers
Prochain SlideShare
Chargement dans…5
×

2012 02-09-eranea-presentation-jug-lausanne

1 680 vues

Publié le

Retour d'exppérience au Java User Group de Lausanne autour du transcodage automatique de grandes applications Cobol vers Java - 09 février 2012

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 680
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1 027
Actions
Partages
0
Téléchargements
9
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

2012 02-09-eranea-presentation-jug-lausanne

  1. 1. Mutation technologique d'applications métier vers Linux & Java - JUG Lausanne - (09 février 2012)
  2. 2. Agenda <ul><li>Business case / Méthodologie </li><ul><li>Quoi ? Point de départ
  3. 3. Pourquoi ? Motivations </li><ul><li>Business case </li></ul><li>Où ? Cible optimale
  4. 4. Qui ? Les acteurs, leurs attentes
  5. 5. Quoi ? Continuum de solutions
  6. 6. Comment ? </li><ul><li>Technologie & méthodologie </li></ul><li>Bénéfices et conclusions </li></ul><li>Points technologiques / démo </li></ul>
  7. 7. Cobol : quo vadis ? Selon Microfocus : <ul><li>Chaque consommateur a 13 interactions quotidiennes avec des applications cobol (achats, appels Natel, etc...)
  8. 8. 220 milliards de lignes de Cobol actives : + 5 milliards chaque année
  9. 9. 60 à 80 de l'activité des multinationales « repose » sur Cobol : 80% des transactions commerciales l'utilise
  10. 10. 200 x plus de transactions Cobol que de requêtes Google chaque jour </li></ul>Source: www.developpez.net
  11. 11. Retour d'expérience <ul><li>Basé essentiellement </li><ul><li>Sur un projet en cours avec grande banque privée genevoise : 10 millions de lignes de Cobol + zOS + CICS + DB2
  12. 12. Sur un projet média terminé à 100%: 4.5 millions de lignes de Cobol + zOS + CICS + DB2
  13. 13. Sur un projet avec un éditeur de logiciel australien 100% terminé
  14. 14. Sur un projet avec assurance étrangère 100% terminé
  15. 15. Sur un projet avec une administration étrangère terminé à 75% </li></ul></ul><ul><li>Signalés par dans les slides qui suivent
  16. 16. -> La méthodologie (automatisation, 3-iso, fonctionnement //, etc.) est aussi voire plus importante que la technologie qui doit la servir ! </li></ul>
  17. 17. Quoi ? Point de départ <ul><li>Une grande application critique au métier du client
  18. 18. encapsulant tout son savoir-faire, solidement éprouvée sur des décennies
  19. 19. représentant de lourds investissements (10s voire 100s d'années-hommes)
  20. 20. en route vers l'obsolescence technologique ?
  21. 21. sur un système opérationnel (très) cher comparé aux standards 2011 </li></ul>
  22. 22. Pourquoi ? Motivations <ul><li>Des économies en investissements (capex) et frais de fonctionnement (opex) massives
  23. 23. Une mutation technologique vers les standards 2011: </li><ul><ul><li>technologies Web, interface RIA
  24. 24. architecture technique: SOA, Java, Linux
  25. 25. productivité: IDE, tests automatisés, QA des sources, code coverage, etc
  26. 26. N.B. : abandon des anciennes technologies en fin de projet </li></ul></ul><li>Si possible les 2 en même temps ! </li></ul>
  27. 27. Business case (projet média - 2003) <ul><li>Le Logiciel Système est le &quot;point chaud&quot;
  28. 28. Un environnement plus compétitif est impératif
  29. 29. Il aura un impact positif sur les logiciels tiers
  30. 30. Hardware/périphériques ne représentent pas la priorité initiale. On pourrait rester sur hardware grand système
  31. 31. Les très bonnes performances Pentium ont permis le passage sur serveurs x86 </li></ul>0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% <ul>100% = approx. 5 millions CHF/an </ul><ul>Cpu </ul><ul>Périphériques </ul><ul>logiciels tiers </ul><ul>logiciels Système (OS, TP, DB, etc.. </ul><ul>Passage à l'Open Source: 70%+ des cash-outs quasi-annulés ! </ul>
  32. 32. Où ? Cible <ul><li>Serveurs x86 (Intel, AMD)
  33. 33. Linux pour le système
  34. 34. Java pour l'environnement applicatif </li></ul>
  35. 35. Où ? Cible : serveurs x86 <ul><li>Quantité </li><ul><li>Architecture #1 en dollars et volume! </li></ul></ul><ul><li>Performances </li><ul><li>Progression exponentielle
  36. 36. 8 machines du top 10 du Top500 mondial sur base x86
  37. 37. Top 10 du TPC-C = 100% x86
  38. 38. 3 Pentiums pour 750'000 trans/jour (rempl mainframe) </li></ul></ul>
  39. 39. Où ? Cible : Linux <ul><li>Google: 2 millions de serveurs
  40. 40. Linux utilisé par London Stock Exchange et autres places boursières (NYSE, Deutsche Börse, Shanghai, etc.) </li><ul><li>pour ses 3S («  Speed , Stability , Security ) »
  41. 41. 1'000'000 trans/s (réponse: 400 ms) pour le « flash trading » </li></ul><li>Fonctionne sur toutes les architectures matérielles : x86, Power, Sparc, ARM (Android), etc. </li></ul>-> Architectures sophistiquées (redondance, haute disponibilité) et évolutions HW possibles (exemple: projet média -> début sur zLinux puis bascule vers x86) -> Fort levier sur les fournisseurs HW placés dans un environnement compétitif
  42. 42. Où ? Cible : Java <ul><li>devise Java : « Write Once, Run Anywhere »
  43. 43. Java : langage le mieux « équipé » de l'histoire de l'informatique (Eclipse, outils QAs, outils monitoring, etc.)
  44. 44. Open Source et très majoritairement gratuit : </li><ul><li>JVM, application server (Tomcat, JBoss, etc.), Java Melody
  45. 45. Jenkins, Ant, Eclipse, GWT, Selenium, Cobertura, etc. </li></ul></ul>Le même code source fonctionne sur Linux, zLinux, MS Windows, AIX, zOS, Solaris.
  46. 46. Qui ? Les acteurs, leurs attentes Massive savings Risks (corporate … & personal) IT cost reductions Disturbance Structural, functional changes Job / position danger Higher productivity New skills Modern technology New skills Job / position danger Training Architecture flexibility Functional agility ?? -> Toutes les parties au projet doivent y trouver leur compte developers engineers architects CIO users
  47. 47. Quoi ? Continuum même DB même OS même TP (CICS, IMS) Cobol -> Java même DB même OS Java AS Cobol -> Java même DB autre OS Java AS Cobol -> Java autre DB autre OS Java AS Cobol -> Java à chaque version ( éditeur de logiciel multi-plate-forme ) Application “ historique ” Application Java “ dérivée ” Migration totale <ul>Différentes cibles possibles ou étapes d'un même projet <li>(NB: aucune interruption des évolutions fonctionnelles ) </li></ul>1 2 3 4
  48. 48. Comment ? <ul><li>Faire baisser drastiquement les coûts de de mutation en migrant automatiquemen t cette application
  49. 49. … avec des risques minimaux via une méthodologie spécifique et éprouvée («  petits pas réversibles  » + tests automatisés) </li></ul>Points-clefs dans un grand compte
  50. 50. Comment ? La forme <ul><li>Transcodage automatique continu: </li><ul><ul><ul><li>100 % de l'application complètement transcodée chaque nuit
  51. 51. tests automatiques via scenarii capturés et rejoués par robot </li></ul></ul><li>Transcodage 3-iso: </li><ul><ul><li>iso-fonctionnel: le minimum...
  52. 52. iso-structurel: code source (développeurs), interface et cinématique (utilisateurs)
  53. 53. iso-syntaxique (développeurs) </li></ul></ul></ul></ul><ul><ul><li>un processus industriel et répétable et pas du «1-shot » à l'arraché car le projet dure 15+
  54. 54. mois (variable selon restructuration applicative initiale / inventaires / niveau de
  55. 55. modernisation souhaité) </li></ul></ul><ul><ul><li>Le partage “live” de la base de données unique est essentiel au succès </li></ul></ul><ul><ul><li>V1 du nouveau système strictement identique à l'ancien. Ensuite seulement, multiples
  56. 56. petits pas rapides d'évolution </li></ul></ul>
  57. 57. Comment ? Les raisons (1/2) Transcodage 100% automatique: <ul><ul><ul><ul><li>répétable à coûts nuls </li></ul></ul></ul></ul><ul><ul><ul><ul><li>rapidité de réalisation </li></ul></ul></ul></ul><ul><ul><ul><ul><li>qualité toujours identique, risques faibles </li></ul></ul></ul></ul><ul><ul><ul><ul><li>évolutions globales par transcodage n+1 (EJBs, SOA) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>pas d'arrêt de la maintenance ni décalage fonctionnel … sans mélange des genres ! </li></ul></ul></ul></ul><ul><ul><li>Les bonnes idées peuvent arriver tard dans le projet (bien après la RFP....) </li></ul></ul><ul><ul><li>un processus industriel et répétable et pas du «1-shot » à l'arraché </li></ul></ul><ul><ul><li>L'automatisation permet de réfléchir pour bien faire les choses …. sans paralyser
  58. 58. le “daily business” </li></ul></ul>
  59. 59. Comment ? Les raisons (2/2) <ul>Iso-transcodage: <ul><ul><ul><li>cible 100% claire !
  60. 60. ne pas déranger les utilisateurs: implication minimale et formation nulle
  61. 61. ne pas perturber les équipes de développement
  62. 62. rassurer et les motiver les collaborateurs loyaux et fidèles </li></ul></ul></ul></ul><ul><ul><li>Une mutation complète et rapide ne peut aboutir qu'avec les équipes en place pas contre </li></ul></ul>elles !
  63. 63. Comment ? (projet média) <ul><li>Contexte applicatif: </li><ul><li>20+ applications &quot;maison&quot; de gestion administrative de commandes. 100% code source disponible.
  64. 64. 1'500 utilisateurs internes, 750'000 transactions /jour & 800'000 pages /mois
  65. 65. 400 travaux nocturnes en batch (270 types de documents)
  66. 66. 500 écrans applicatifs / 1'500 tables relationnelles </li></ul><li>Avant: </li><ul><li>Mainframe IBM z800 (350 Mips) zOS / CICS / COBOL / DB2
  67. 67. Réseau TCP/IP / émulation TN3270
  68. 68. 4 millions de lignes de Cobol à transcoder (2'150 programmes) </li></ul><li>Après: </li><ul><li>cluster de serveurs Intel sous Linux (Redhat) / Java /Apache Tomcat /UDB
  69. 69. 500 écrans html (+ Javascript/AJAX & CSS), 1'500 tables relationnelles
  70. 70. 4 millions de lignes de Java </li></ul></ul>
  71. 71. Comment ? Technologie <ul><ul><li>Transcodage iso-strucurel facilite grandement la transition des équipes en place </li></ul></ul>NeaTranscoder NeaRuntime <ul>Java Program (incl SQL) </ul><ul>XML Screen </ul><ul>DBMS </ul><ul>Lexical Analysis </ul><ul>Syntax Analysis </ul><ul>Semantics Analysis </ul><ul>Code Generation </ul><ul>Online </ul><ul>SOA </ul><ul>Batch </ul><ul>“ Cobol” support </ul><ul>SQL support </ul><ul>CICS Emulation </ul><ul>Display support </ul><ul>Tracing / logging </ul><ul>Internal Object implementation </ul><ul>Cobol copy </ul><ul>Cobol pgm </ul><ul>BMS desc </ul>
  72. 72. Comment ? Processus Entrepôt sources DB ERIT Integrate Moteur CI cobol déclenchement travaux consultations + recherches code source rapports code source DB2 Application server monitoring développeurs administrateurs utilisateurs Jenkins + Ant (windows) DB2 (zOS) Subversion (zLinux) Tomcat + GWT + Lucene (zLinux) Shared Batch Online ServiceBackend Batch WebServiceFront Application
  73. 73. Comment ? No big-bang = no risk <ul><ul><li>Souplesse et adaptabilité de la planification de la migration sont critiques </li></ul></ul><ul>2-3 months </ul><ul>DRDA connection </ul><ul>Time </ul><ul>Activity </ul><ul>Cobol on Cics </ul><ul>Java on Tomcat </ul><ul>100% </ul><ul>6-9 months </ul><ul><li>100% of data on DB2
  74. 74. Cobol remains reference </li></ul><ul>Java becomes reference </ul><ul>Data Migration to new DB </ul><ul>Mainframe Switched off </ul><ul>Progressive Migration </ul><ul>Big Bang Avoidance = Key Success Factor !! </ul><ul>Instantaneous way back to old system </ul><ul>0% </ul><ul>CICS </ul><ul>DB2 </ul><ul>Tomcat </ul>
  75. 75. Comment ? Tests permanents <ul><ul><li>Les tests ne doivent pas être “gommés”: ils font partie du projet
  76. 76. mais aident les développeurs à s'approprier le nouveau code </li></ul></ul><ul>CICS </ul><ul>DB2 </ul><ul>XML Screen Data </ul><ul>3270 </ul><ul>XML Screen Data </ul><ul>HTML </ul><ul>COBOL </ul><ul>XML Screen Data </ul><ul>Transcoder or run-time or Cobol bug fixes </ul><ul>(1) </ul><ul>(2) </ul><ul>(3) </ul><ul>(4) when (1) & (3) different </ul><ul>Tomcat </ul>
  77. 77. Bénéfices (1/2) <ul><li>Économies: Projet média -> 4.5 millions / an (= 90% !) </li></ul><ul><li>Levier « naturel » et rapide sur les apports technologiques intrinsèques de la nouvelle plate-forme: </li><ul><ul><ul><li>Projet média: Interface Web, 100% documents PDF, système d'archivage standard (Knowledge Tree)
  78. 78. Projet bancaire: SOA généralisée, intégration BPM, interface RIA (Google GWT), fonctionnalités augmentées (« contexte sémantique ») </li></ul></ul></ul></ul><ul><li>Synergies technologiques additionnelles par abandon technologies – Optimisations RH résultantes </li></ul><ul><ul><li>Economies -> facteur principal d'adhésion du management (généralement peu “sensible”
  79. 79. à la beauté des nouvelles technologies...) </li></ul></ul>
  80. 80. Bénéfices (2/2) <ul><li>Augmentation de la productivité : </li><ul><ul><ul><li>Architecture: structuration optimisée par « code mining » (« NeaMining »), pilotage / suivi intégré du parc logiciel (« NeaIntegrate »)
  81. 81. Développement :outillage Java, debugging interactif, environnement personnel indépendant
  82. 82. Production : interface graphique de gestion du système (Webmin – open source -> gratuit !) </li></ul></ul></ul><li>Nouvelles possibilités architecturales : </li><ul><ul><ul><li>Projet media -> propre centre de backup
  83. 83. Croissance horizontale par ajout de serveur
  84. 84. Isolation des fonctions : batch vs transactionnel, etc.. </li></ul></ul></ul></ul>
  85. 85. Qui ? Les acteurs, leurs attentes Risks (corporate … & personal) Disturbance Job / position danger Job / position danger Training developers engineers architects CIO users - automated testing - dual systems - iso-functional / iso-structure for appl. - progressive migration - dual system on same data - automated testing - direct involvement in migration - iso-structure & iso-syntax - new capabilities -> new demand - builder (= owner) of new system - new projects: backup center, etc. Everybody now on modern and “fun” platform
  86. 86. Conclusion Une mutation technologique vers Linux/Java offre 2 opportunités habituellement non simultanées : <ul><ul><ul><li>Évolution fonctionnelle fondamentale
  87. 87. Réduction massive des coûts </li></ul></ul></ul>Le transcodage automatique permet une synergie entre elles: <ul><ul><li>Les réductions opex/capex permettent le financement du projet avec ROI court puis des économies restituables ensuite au business </li></ul></ul>
  88. 88. Points technologiques (1/2) <ul><li>Structure « plate » d'une application Cobol <> packages Java : un outil de mapping est nécessaire pour structurer le Cobol initial </li></ul><ul><li>Necéssité d'un outil Ajax / Interface riche pour pouvoir reproduire (via Javascript) fidèlement le mapping du clavier mainframe orignal. Possibilités de « belle » interface ensuite -> Google Web Toolkit </li></ul><ul><li>Structures des données Cobol : « Redefines » -> gestion d'un buffer mémoire impératif (en gérant la compatibilité UTF <> octet)
  89. 89. Cobol : ordre de lecture + goto -> utilisation massive d'exceptions Java pour produire les mêmes effets </li></ul>
  90. 90. Points technologiques (2/2) <ul><li>Cobol permet des calculs sur des nombres avec 31 digits -> Java ne le permet pas à la base -> extensions nécessaires
  91. 91. Codage « packé » des nombres (COMP-3 COBOL) </li></ul><ul><li>Page de code EBCDIC des caractères sur le mainframe (ordre de tris, etc.) </li></ul>
  92. 92. Merci de votre attention ! Des questions ? Didier Durand [email_address] +41 79 944 37 10 Eranea SA chemin de Mornex, 2 1003 Lausanne Suisse

×