Points clés
- La transition a été menée par un découplage progressif, sans remplacer entièrement le système existant.
- Un système de données en temps réel fondé sur le CDC a remplacé l’accès direct au mainframe.
- GraphQL a permis de supprimer une grande partie de la couche BFF au lieu de REST, tout en gagnant en flexibilité et en maintenabilité.
- Une organisation d’équipe centrée sur les domaines (Team Topologies) a clarifié les responsabilités et la propriété de chaque équipe.
- Grâce aux déploiements progressifs et à l’automatisation, le système a été migré sans risque et la valeur livrée de manière stable.
Cas d’introduction : la moitié du système a survécu malgré une panne
Une panne du mainframe s’est produite, mais grâce à une architecture de streaming basée sur le cloud, la nouvelle interface utilisateur a continué à fonctionner normalement.
Même lorsque le système existant était hors service, le nouveau système a maintenu l’expérience client et démontré sa résilience.
Stratégie clé : découplage multicouche
- Domain-Driven Design (DDD) : reconstruction du modèle centré sur le mainframe dans une logique plus proche du métier
- Team Topologies : passage à une organisation en équipes centrées sur les flux métier
- Architecture orientée événements : réduction du couplage entre systèmes via un fonctionnement asynchrone
- Change Data Capture (CDC) : détection des changements de données en temps réel pour relier l’ancien système et le nouveau
Architecture précédente : Unified Web Portal 1.0
Différentes données du mainframe étaient intégrées via ETL puis exposées dans une base SQL et en SaaS,
mais cela posait des problèmes de manque de temps réel, de baisse de qualité des données et d’appels directs au mainframe.
Problèmes
- Retards de données dus à l’ETL
- Connexion synchrone au mainframe peu élastique
- Création d’un très grand nombre d’API BFF
- Goulots d’étranglement organisationnels et retards de release
- En cas de pic de trafic, une surcharge du mainframe provoquait une panne générale du service
Définition des nouveaux objectifs
Objectifs techniques : séparer le mainframe du web, supprimer les BFF, renforcer l’autonomie des équipes
Objectifs métier : réduire les sollicitations au centre d’appels, diminuer les coûts de licence, améliorer la satisfaction client
Vue d’ensemble de la nouvelle architecture
- Le mainframe reste le system of record
- CDC → Kafka → base de domaine (CosmosDB)
- API GraphQL + REST → BFF → UI
- Tous les composants sont reliés par une structure orientée événements et un message broker
Étape 1 : Change Data Capture
- Mise en place d’un system of reference via le streaming de données en temps réel
- Mainframe → Kafka → transformation → base de domaine → exposition via API
- Obtention d’une structure de données flexible, non dépendante du schéma du mainframe
Étape 2 : Domain-Driven Design + GraphQL
- Définition du modèle de domaine avec DDD (Entity, Command, Event)
- Chaque domaine est structuré comme un nœud GraphQL, avec création d’un supergraph via schema stitching
- Prise en charge de requêtes optimisées ne récupérant que les données nécessaires
Évolution de l’organisation : Team Topologies
- Réorganisation en stream-aligned teams centrées sur les capacités métier
- Les zones complexes (par exemple l’intégration mainframe) sont gérées par une équipe dédiée
- Mise en place d’une équipe Enablement pour l’accompagnement technique
Extension orientée événements : événements de domaine internes + pattern Saga
- Génération d’événements lors des changements de domaine via le pattern Outbox
- Synchronisation entre les traitements du mainframe et le CDC avec une Parallel Saga
- Construction de workflows fondés sur des machines à états pour gérer aussi les flux complexes
Défis
- Nécessité de faire évoluer la perception interne de l’adoption d’une architecture orientée événements
- Dans une architecture asynchrone, l’observabilité est indispensable
- Les traitements batch du mainframe peuvent surcharger le pipeline CDC
- Complexité de la gestion du schéma GraphQL et réflexion autour d’une approche fédérée
- Les préoccupations transverses comme l’authentification et le logging sont gérées via des packages séparés et de l’automatisation
Stratégie de release : release train + feature flags
- Chaque équipe déploie indépendamment, avec intégration dans un dépôt de déploiement
- Mise en place de pipelines de déploiement par environnement avec Kustomize
- Séparation des releases fonctionnelles et de sécurité grâce aux feature flags, tout en conservant un développement trunk-based
Mise en œuvre d’une architecture hybride
- UWP 1.0 et UWP 2.0 coexistent pour permettre une transition progressive
- Le routage en périphérie bascule progressivement les requêtes utilisateur vers le nouveau système
Conclusion : construire une plateforme capable d’évoluer
- Séparation complète entre le frontend et le mainframe
- Une organisation centrée sur les équipes pour gagner en vitesse et en stabilité
- Amélioration de la satisfaction client et des coûts d’exploitation
- Une base flexible qui rend possible, à terme, le remplacement du mainframe
1 commentaires
L’amélioration progressive et l’extraction progressive des microservices sont vraiment essentielles... Quand je lis ce genre d’article, je me dis que le PM qui pilote ce projet est vraiment important et impressionnant. Gérer tout ça, c’est énorme.