Le document présente l'évolution de l'architecture de modernisation des systèmes d'information de Sodifrance, en mettant l'accent sur la migration des applications VB vers .NET. Il décrit les défis techniques et métiers liés à cette transformation, ainsi que les solutions proposées, notamment l'approche MDA pour faciliter la ré-ingénierie et la maintenance des applications. Des exemples de projets de migration réussis sont également fournis, illustrant l'application des processus automatisés de transformation et de génération de code.

1. Evolution d’architecture Présentation du 26/03/07 au Microsoft Technology Center, Paris

2. Plan Sodifrance Evolution d’architecture Chaîne de modernisation VB vers .NET

3. Carte d’identité Chiffres clés SSII créée en 1986 600 collaborateurs 43,2 M€ de CA en 2005 12 implantations : France et Belgique Cotée Second Marché d’ Euronext Société à Conseil de surveillance et Directoire Agence Centre de Services ou d’infogérance R&D Stratégie Expertise en développement et modernisation des systèmes d’information Développement piloté par les offres à forte valeur ajoutée technologique Une clientèle de grands comptes Des secteurs d’activités diversifiés Les 12 premiers clients MMA CNP CREDIT MUTUEL MAIF AXA BELGIQUE MAAF MEDERIC CREDIT AGRICOLE ING SUISSE ET BELGIQUE BERGERAT MONNOYEUR LA POSTE BANQUE POPULAIRE Un positionnement affirmé dans le secteur Banque/Assurance Des clients grands comptes Une forte fidélisation de nos clients

4. Les offres Système d’information Modernisation de patrimoines applicatifs Rétro-documentation Transformation en masse Migration Évolution J2EE et .Net Maintenance / TMA Edition de logiciel MIA Studio ESSOR Infrastructure IT Architecture et Intégration de systèmes Sécurité Infogérance Études & Développement Conseil génie logiciel Développement d’applications Industrialisation Projets NT/Approche MDA Solutions métier

5. Une gestion complète du cycle de vie du logiciel Comprendre Mesurer Application Modernization (Re) développer Application Portfolio Management Migrer -Langage - Plateforme Intégrer - SOA Transformer -Refactoring Application Development Arbitrer Application Maintenance Migrer -Langage - Plateforme Corriger Transformer -Refactoring Agir

6. Plan Sodifrance Evolution d’architecture Chaîne de modernisation VB vers .NET

7. Problématique de l'évolution d’architecture Difficultés d'ordre métier/fonctionnel : Difficultés à formaliser le besoin Evolutions des souhaits des utilisateurs Difficultés d'ordre technique : Obsolescence des technologies Complexité des règles de production de code Hétérogénéité des technologies utilisées Instabilité du socle technique Pression économique : Maitrise coûts/délais/risques Problème des DSI Comment moderniser le patrimoine applicatif ? Comment suivre les évolutions technologiques ? Difficultés d'ordre exponentiel par rapport à volume et complexité... technologie métier

8. Quelles solutions ? Moins rapide que Migration Combine migration et rénovation Maintenance MDA possible Refonte outillée : Migration outillée + évolution via les modèles Complètement iso-fonctionnel Plus économique (-30%) Plus rapide (-50%) Iso-fonctionnel, iso-ergonomie Maintenance MDA possible Migration outillée : Transformation automatisée de l’architecture et du code Plus cher et plus long Sollicitation forte des sachants Processus connu Refonte manuelle : Nouveaux développements Inconvénients Avantages Stratégie de ré-ingénierie

9. Notre solution de migration/refonte outillée Processus éprouvé Résultat de notre capitalisation sur nos projets Processus outillé Rétro-conception, transformation, génération Pas de phase de spécification fonctionnelle (le code en fait office) Gain important en délai et en charge par rapport à une refonte manuelle Processus non intrusif N’impose pas une cible particulière S'intégre dans tout cycle de développement Processus adaptable Migration partielle : par exemple, migration des couches front-office vers le web et conservation des services back-office sur le mainframe Réécriture partielle : composants graphiques, d’architecture ou liés aux couches système

10. Migration d'une architecture client serveur vers une architecture n-tier Deux difficultés Changement d’architecture : passage client-serveur à une architecture 3-tiers Changement de paradigme de programmation : passage à l ’objet Notre réponse Remonter au niveau des modèles : ne pas se limiter à de la transformation de code, mais abstraire la problématique en travaillant au niveau des modèles Notre philosophie : Adopter une démarche MDA en passant par des modèles

11. Intérêts du passage par les modèles Code applicatif Modèle Refactoring Changement de socle technique Rétro-documentation Rétro-conception Cartographie applicative

12. Avantages de la démarche MDA Une capacité supérieure à ré-architecturer les applications à migrer que n’offre pas une « simple » transformation code à code, Une agilité supplémentaire dans le choix de la cible de migration, Un accroissement de la valeur ajoutée de la migration au travers la rétro-conception de l’existant, La possibilité de capitaliser sur les modèles obtenus pour la maintenance des applications migrées, La possibilité de capitaliser sur la démarche MDA et la mécanique de génération de code pour de nouveaux développements , Utilisation des standards de l’OMG (MOF, XMI, UML), Indépendance vis-à-vis de l'outillage de conception/modélisation du client.

13. Le processus Application existante (Cobol, L4G, VB6, …) Modèle de l'application Source Mia-Generation  Rétro-ingénierie  Re-conception  Génération  Evolution Modèle de l'application Cible Mia-Transformation Système cible (.NET, J2EE, ...) Parsers code source

14. Phase 1: Rétro-ingénierie Analyse automatique du code à l’aide d’un parseur Rétro-modélisation des informations Instanciation d’un modèle de l’application source (100% des informations de départ) Application existante (VB6, NSDK, NATSTAR, INFORMIX, PB, COOL:GEN …) Modèle de l'application Source Parsers code source Analyse du code

15. Phase 2 : Transformation Processus automatisé de transformation de modèles grâce à l’outil Mia-Transformation Détection de composants particuliers (objets persistants, cinématique, modèles de vue…) Instanciation d’un modèle de l’application proche de la cible Modèle de l'application Source Modèle de l'application Cible Mia-Transformation

16. Phase 3 : Génération Processus automatisé de génération grâce à l’outil Mia-Generation Génération du code de l’application migrée Intégration dans l’architecture et le cycle de développement cible Mia-Generation Modèle de l'application Cible Système cible (.NET, J2EE, ...)

17. Une évolution possible grâce au cycle en Y Modèle de l’application cible Architecture logique et technique cible Générateurs Application cible L’application migrée respecte les standard d’architecture La maintenance est facilitée

18. Phasage d’un projet de migration GO 2 Réalisation (par lots) avec parallélisation Préparation     GO 1  Industrialisation  Réal. Chaîne automatisée : - Adaptations outillage - Règles de transformation - Règles de génération - Lotissement projet  Pilote déployable  Proposition forfaitaire Cadrage  Macro chiffrage - Analyse rapide  Chiffrage ±30%  Etude préalable : - Points durs - Cible technique - Ergonomie - Scénarios - POC  Proposition Pilote  Chiffrage ±20% Migration industrielle  Migration automatisée - Tests de référence - Transformation - Génération - Compléments manuels - Réécritures partielles - Refactoring IHM - Tests de Non Régression  Lot migré  Intégration - TNR - Tests charge & perf.  Lot intégré  Recette utilisateur  Lot recetté Déploiement  Déploiement   GO 3 ~2 semaines ~ 3 mois ~ 1 mois X mois

19. Exemples de références MAAF : Migration NSDK  J2EE d’une application d’assurance auto (50 écrans, 50 000 lignes de code) AGF : Migration NSDK  J2EE d’une application d’assurances maritimes (160 écrans, 60 000 lignes) Migration Natweb  J2EE de 4 applications CDC Ixis : Migration NSDK  .NET/WinForms (20 écrans, 30 000 lignes de code) France Telecom : Migration NSDK  J2EE NSDK .Net

20. La source : CoolGen La cible : migration mixte J2EE / Cobol Services back-office conservés en Cobol Couches applicatives en J2EE (framework spécifique) Approche SOA Le périmètre : tout le patrimoine applicatif 50 applications, 1000 écrans, 1000 serveurs Contraintes : S’intégrer dans l’architecture S’intégrer dans la démarche de développement (le client a déjà initié une démarche MDA) Conserver le niveau d’utilisabilité des applications Le projet Charge : 9000 jours (dont 400 d’outillage) Délai : 18 mois Référence Crédit du Nord

21. Plan Sodifrance Evolution d’architecture Chaîne de modernisation VB vers .NET

22. Évolution d’architecture > Conclusion Merci pour votre attention …