migration PacBase → UML /Javaassociation Guépard – 09 octobre 2012

Paris

didier durand didier.durand@eranea.com

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

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)

PacBase → UML / Java : 2 étapes

tomcat

tomcat

modèlePacBase

modèlePacBase

modèleUML

transcodeurJava

générateurCobol

Cobol Java

générateurJava

Java

Transcodage Cobol → Java économies massives rapides

+ modernisation plate-forme & UI

Migration modèle PacBase → UML économies outils

+ modernisation méthodesréférentiel

multi-modèles

référentielPacBase

rétro-ingénierie

+ partenaire

dèsaujourd'hui !

développementen cours

Nécessairement postérieur à l'arrêt mainframe(quand Cobol n'est plus nécessaire)

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

motivations

➢ des économies en investissements (capex) et frais de fonctionnement (opex) massives

➢ une mutation technologique vers les standards actuels: 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

➢ via solution eranea, les 2 en même temps !

tactique

stratégique

motivations - exemple

➢ logiciel trop cher → environnement compétitif base + tiers nécessaire

➢ passage à OSS :

-70 % sur la facture logicielle

possibilité de changement HW

10%20%30%40%50%60%70%80%90%

100%

100% = approx. 5 millions CHF/an

Cpu

Périphériques

logiciels tiers

logiciels IBM(z/OS, Cics, DB2, etc..)

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)

➢ 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

acteurs et attentes (1)

acteurs et attentes (2)

➢ développeurs, ingénieurs système : nouvelles compétences meilleure efficacité et productivité « et mon job ? » …

➢ architectes modernisation pérennité

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)

palette de solutions

appl.originale

mutationtotale

niveau 1

niveau 2

niveau 3

niveau 4

Cobol → Javaautres : identiques

Cobol → JavaCICS → Java ASautres : identiques

Java AS sur Linux

DBsur Linux

différentes étapes d'un

même projet<>

différents projets

appl. dérivée

solutionéditeur

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)

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

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

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

cible optimale (4)

➢ linux en croissance permanente

➢ OS propriétaires disparaissent

➢ références Linux : London Stock Exchange, NYSE, Euronext, etc.

➢ pour les « 3S » : Speed, Stability, Security

Windows = prédominancedes

serveurs bureautiques

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)

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

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é

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

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

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

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

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

outils : transcodeur & runtime

“Cobol” support

SQL support

CICS Emulation

Display support

Tracing / logging

InternalObject

implementation

JavaProgram

(incl SQL)

XMLScreen

DBMS

LexicalAnalysis

Syntax Analysis

Semantics Analysis

Cobolcopy

Cobolpgm

BMSdesc

Code Generation

NeaTranscoder

NeaRuntime

Online

SOA

Batch

intégration continue

Internet

Entrepôt sources

DB ERIT

Integrate

Client

1. échanges automatisésvia «clonage»

symétrique et traçable

2. copie (partielle) des assets propriétaires

3. réplication des processus

et systèmes

MoteurCI

Entrepôt sources

Integrate

Eranea

MoteurCI

Application “historique”+

Base de données

DB ERIT

VPN

migration (très) progressive

2-3months

DRDA

time

activity

Cobolon Cics

Javaon Tomcat

100%

6-9months

• 100% of data on DB2• Cobol remains reference

Javabecomesreference

dat

am

igra

tio

n t

o n

ew

DB

mainframeswitched

off

CICS DB2

progressivemigration

pas de Big Bang = clef du succès !!

instantaneousway back

to old system

0%

tomcat

capture et replay des tests

Tomcat

CICS DB2

XMLscreendata

3270

XMLscreendata

HTML

COBOL

XMLscreendata

transcoder orrun-time or Cobol

bug fixes

(1)

(2)

(3)

(4)when (1) & (3) different

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)

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.

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.)

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

➢ 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

acteurs et attentes (bis)

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.

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)

PacBase → UML / Java : 2 étapes

tomcat

tomcat

modèlePacBase

modèlePacBase

modèleUML

transcodeurJava

générateurCobol

Cobol Java

générateurJava

Java

Transcodage Cobol → Java économies massives rapides

+ modernisation plate-forme & UI

Migration modèle PacBase → UML économies outils

+ modernisation méthodesréférentiel

multi-modèles

référentielPacBase

rétro-ingénierie

+ partenaire

dèsaujourd'hui !

développementen cours

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.

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

transposition PacBase → UML

Prototype modèle EA

partiel

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

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.

merci !

des questions ?

Didier DURANDdidier.durand@eranea.com+41 79 944 37 10

eranea SAchemin de Mornex1001, Lausanne (Suisse)