Création d’un concept de modernisation du back-end pour un client du secteur manufacturier

Le client développe depuis de nombreuses années des solutions innovantes dans l’industrie manufacturière, en utilisant la technologie pour assurer la sécurité des données sensibles. 

Le principal défi consistait à développer et à proposer une nouvelle architecture de système avec un chemin de migration vers un nouveau système adapté aux besoins actuels.

L’objectif premier de la migration était, entre autres, le suivant :

• Augmentation de la capacité de traitement requise par les machines de production -Un nouveau système de processus de contrôle de la production était nécessaire pour améliorer la vitesse des opérations. En effet, dans le monolithe, l’ajout d’éléments prolongeait le processus d’essai, ce qui nécessitait une aide pour développer une meilleure architecture.
• Détection des goulets d’étranglement dans le système et optimisation -Le passage aux conteneurs a facilité les mises à jour régulières et la création d’un plus grand nombre d’instances pour gérer les difficultés liées au flux d’informations.
• Capacité à faire évoluer le système actuel
• Facilité d’ajout de solutions pour de nouveaux produits
• Amélioration de la stabilité, de la fiabilité et de la tolérance aux pannes -La gestion du monolithe a été un défi, notamment en raison de la gestion des pannes.

PHASE I 

INITIATION -Discuter d’une compréhension commune des tâches et des objectifs du client

Notre tâche principale consistait à comprendre les processus de production, l’architecture et l’étendue des opérations du client. Nous nous sommes également attachés à établir une perspective commune afin d’éliminer tout malentendu sur les exigences. Nous avons défini ce que l’équipe du client souhaitait accomplir et ce que devait être le produit final de ce projet. La chose la plus importante pour nous était de connaître leurs attentes, leurs besoins et l’étendue des tâches.

L’équipe allemande nous a fait part de ses objectifs, ce qui nous a permis de diviser plus facilement les exigences en deux catégories : techniques et commerciales.

• Objectif de l’entreprise – le client souhaite accroître l’évolutivité de son système et déployer de nouveaux produits en utilisant peu de ressources et en respectant un délai de mise sur le marché rapide.
• Objectif technique – il s’agit principalement d’optimiser le processus de circulation des données et de détecter les éventuelles perturbations (goulets d’étranglement), et de réduire le temps de retraitement des données à un maximum de 15 minutes.

Le principal besoin de l’équipe du client était une recommandation technologique, spécifiant la préparation d’une description architecturale comme une approche strictement substantielle d’une proposition technologique.

PENSÉE CONCEPTUELLE -Collecter les données et présentation du concept initial

Au cours de l’étape suivante, nous avons discuté de tous les composants des systèmes actuels du client et des éléments de son réseau ainsi que de son infrastructure. Nous sommes ensuite passés en douceur à l’analyse de l’ensemble de la production d’équipements. Lors de la préparation des données, nous en avons appris davantage sur les machines et leur fonctionnement ; à cette fin, nous avons posé de nombreuses questions, telles que le fonctionnement du système, les processus, les dépendances, les systèmes limites, etc.

Après avoir pris connaissance de la documentation du client, nous avons défini les objectifs à atteindre. Nous avons utilisé différents types de méthodologies Agile au cours du processus de développement, tels que les diagrammes de cas d’utilisation et les diagrammes d’activité. Nous avons défini l’architecture du système avec le client et discuté des modules et des fonctionnalités à remplacer ou à améliorer. La pile technologique choisie devait être supportée à long terme (LTS) et basée sur des conteneurs.

Cette discussion technique a facilité la modélisation des processus d’entreprise (BPMN/Diagramme d’activité) et la proposition de nouvelles solutions. Après le premier atelier, nous avons défini une proposition de solution. Nous avons ensuite défini que nous préparerions une recommandation technologique, comprenant des informations sur tous les avantages et les risques des solutions proposées et une esquisse de l’architecture. Nous avons également défini des réunions hebdomadaires avec le client au cours desquelles nous avons échangé des commentaires, des suggestions et des propositions avec le client.

PHASE II 

PLANIFICATION

Au cours du deuxième atelier, nous avons à nouveau souligné les buts et les objectifs de la conception. Nous avons ensuite discuté d’un premier projet d’architecture basé sur la documentation technique que nous avons reçue. Lors de l’étape suivante, nous avons présenté deux concepts comparant l’approche actuelle et la nouvelle approche de l’architecture pilotée par les événements, combinées à une solution hybride basée sur les microservices et le modèle de monolithe modulaire. Entre autres choses, nous avons passé en revue la pile technologique que nous recommandons et la proposition d’architecture.

Nous avons opté pour l’architecture pilotée par les événements parce que cette approche permet d’obtenir :

1. Liens lâches entre les composants -Les composants peuvent communiquer à l’aide d’une messagerie asynchrone basée sur les événements, ce qui permet une plus grande flexibilité et une meilleure évolutivité du système.
2. Évolutivité -Dans cette architecture, le traitement peut être séparé en plusieurs composants, chacun pouvant traiter indépendamment les événements entrants. Il est ainsi facile de faire évoluer le système en fonction de l’augmentation de la charge de travail et de garantir une utilisation homogène des ressources.

Dans l’étape suivante, nous avons montré comment nous envisagions le nouveau système et discuté des principales hypothèses.

Nous avons ensuite présenté une stratégie comportant deux approches sur la manière de passer du système actuel au nouveau système. Elle se compose de deux parties :

• Concept évolutif – implique de changer la façon dont nous communiquons.
• Un concept révolutionnaire – nous avons modifié en profondeur la manière dont les modules communiquent et la communication entre les modules. La création de « files d’attente » a amélioré les performances des modules, la communication et le temps de traitement a été réduit.

La planification technologique comprenait la sélection des technologies appropriées ; dans ce cas, il s’agissait de Java 17 (JDK 17) et de Spring Boot 3.1/Spring 6. Le facteur principal dans le choix d’une pile technologique était la connaissance des exigences du système et la disponibilité des ressources et des développeurs.

Qu’est-ce que le client a reçu après l’atelier sur le produit ?

Après l’atelier, le client a reçu une documentation complète en allemand, rassemblant toutes les conclusions conceptuelles. Il contient toutes les étapes décrites précédemment, telles que la définition des objectifs, la sélection de la pile technologique et la définition de l’approche évolutive ou révolutionnaire visée.

Le client a été très satisfait de l’atelier de fabrication, car nous avons répondu à pratiquement toutes ses attentes. Grâce à une excellente communication, nous avons créé une proposition architecturale entièrement nouvelle. L’attente du client n’était pas de créer un plan de migration, une tarification de projet ou une répartition des phases de mise en œuvre.

Les avantages que le client a retirés de l’atelier de réflexion sur la conception sont les suivants : 

• Réduction des coûts – au lieu d’expérimenter en interne et de détourner ses propres développeurs des tâches principales, l’équipe a reçu une solution prête à l’emploi.
• Une innovation qui sort des sentiers battus – grâce à une approche objective, nous avons jeté un regard factuel sur l’architecture actuelle du client et sur les objectifs qu’il souhaite atteindre.
• Des solutions technologiques et architecturales modernes.
• Coopération active – l’équipe du client a participé activement au processus depuis l’échange d’expériences sur l’approche technologique et a pris une part active aux ateliers, y compris la modélisation.
• Réduction significative des risques – en n’ayant pas à expérimenter elle-même les nouvelles solutions technologiques, l’équipe du client gagne du temps en évitant de commettre des erreurs au début de l’adoption du système.

Le résultat final après une présentation en interne était si impressionnant que nous avons développé deux projets PoC (Proof of Concept) avec le client. Chaque projet se compose de plusieurs étapes, développées par intervalles. À la fin de chaque projet, nous organisons une démonstration pour présenter et discuter de l’avancement du travail.

Les projets futurs que nous avons identifiés avec le client sont les suivants

1. Mise en œuvre du concept d’architecture pilotée par les événements (Event-Driven Architecture) basée sur les conteneurs. La base sera de construire l’infrastructure, de créer une configuration de base de la file d’attente et une surveillance de base avec de la documentation.
2. Mise à l’échelle automatique de la solution en fonction de la charge des files d’attente ou des ressources. En outre, le travail consistera à effectuer diverses opérations sur la disponibilité des applications, les files d’attente, etc. ainsi que la documentation.