Icham Berreghioua
Product Owner Integration Platform
46 ans
Lausanne (1004) Suisse
En poste
Ouvert aux opportunités
Leader Technique en intégration et automatisation, je gère et priorise les backlogs pour garantir l'alignement des besoins métiers, relevant du fonctionnel, avec les exigences techniques, relevant du non-fonctionnel. Je coordonne et facilite la conception, fabrication et livraison d'échanges inter-systèmes en garantissant leur release management et maintien en conditions opérationnelles grâce aux pipelines CI/CD et aux processus IaC. Cela améliore significativement la stabilité et l'efficacité du système d'information au sein duquel s'opère ces échanges.
Ma passion pour l’IT se reflète dans mon éthique de travail, axée sur la rigueur, l'efficacité et l'intégrité. Dans un cadre méthodologique Agile, je m'appuie sur une approche structurée qui part toujours des personnes et des processus impliqués pour en arriver à la solution appropriée. Cela nous permet, en tant qu’équipe, de co-construire des systèmes évolutifs qui répondent précisément aux besoins métiers tout en respectant les contraintes techniques et impératifs QCD projets.
« For the things we have to learn before we can do them, we learn by doing them. »
Aristotle 384–322 BC
Ma passion pour l’IT se reflète dans mon éthique de travail, axée sur la rigueur, l'efficacité et l'intégrité. Dans un cadre méthodologique Agile, je m'appuie sur une approche structurée qui part toujours des personnes et des processus impliqués pour en arriver à la solution appropriée. Cela nous permet, en tant qu’équipe, de co-construire des systèmes évolutifs qui répondent précisément aux besoins métiers tout en respectant les contraintes techniques et impératifs QCD projets.
« For the things we have to learn before we can do them, we learn by doing them. »
Aristotle 384–322 BC
Notre organisation a décidé d'adopter une approche API First pour répondre à un besoin crucial : réduire les dépendances qui sont liées aux solutions « out of the shelf » choisi par nos métiers . Cette décision stratégique vise à minimiser le couplage entre les systèmes, existants et à venir, en gardant la maitrise de la qualité, des coûts et délais de livraisons pour nos projets métiers dans un SI stable.
Mon Rôle en tant que Solution Architect :
En tant que Solution Architect, j'ai interprété ces besoins de l'architecture d'entreprise pour concevoir un framework en trois zones conceptuelles :
1. Systèmes d’Entreprise Monolithe (ECS) :
Catégorisation des systèmes legacy ou « out of the shelf » stables mais rigides, avec de rares mises à jour à risque métier donc leur cycle de vie impose une modernisation progressive. C’est aussi l’ensemble des systèmes « maître de donnée » qui ont souvent leurs propres modèles.
2. Cœur d'Intégration par APIs (AIL) :
Simplification des interactions entre les systèmes en réduisant les dépendances complexes. Les requêtes en entrée sont normalisées selon un modèle de données interne sous la gouvernance du métier et Business Analyst du domaine métier impliqué. C'est ici que la transformation entre modèle de données (interne <--> spécifique) est opérée.
3. Écosystème d'Applications Agiles (AAE) :
Catégorisation des systèmes dont le cycle de vie est rapide avec des mises à jour fréquentes et légères, offrant plus de flexibilité mais nécessitant une gestion continue pour maintenir la stabilité. Ces systèmes sont nativement en adéquation aux modèles de données interne ou ne dispose simplement pas de base de données (SPA, etc...).
Ce framework nous a permis d’aligner les besoins de l’architecture d’entreprise sur les exigences concernant la nouvelle plateforme d’intégration. Il nous a servi de boussole en orientant nos choix et arbitrages entre solutions technologique concurrentes.
Mon Rôle en tant que Solution Architect :
En tant que Solution Architect, j'ai interprété ces besoins de l'architecture d'entreprise pour concevoir un framework en trois zones conceptuelles :
1. Systèmes d’Entreprise Monolithe (ECS) :
Catégorisation des systèmes legacy ou « out of the shelf » stables mais rigides, avec de rares mises à jour à risque métier donc leur cycle de vie impose une modernisation progressive. C’est aussi l’ensemble des systèmes « maître de donnée » qui ont souvent leurs propres modèles.
2. Cœur d'Intégration par APIs (AIL) :
Simplification des interactions entre les systèmes en réduisant les dépendances complexes. Les requêtes en entrée sont normalisées selon un modèle de données interne sous la gouvernance du métier et Business Analyst du domaine métier impliqué. C'est ici que la transformation entre modèle de données (interne <--> spécifique) est opérée.
3. Écosystème d'Applications Agiles (AAE) :
Catégorisation des systèmes dont le cycle de vie est rapide avec des mises à jour fréquentes et légères, offrant plus de flexibilité mais nécessitant une gestion continue pour maintenir la stabilité. Ces systèmes sont nativement en adéquation aux modèles de données interne ou ne dispose simplement pas de base de données (SPA, etc...).
Ce framework nous a permis d’aligner les besoins de l’architecture d’entreprise sur les exigences concernant la nouvelle plateforme d’intégration. Il nous a servi de boussole en orientant nos choix et arbitrages entre solutions technologique concurrentes.
La plateforme d’intégration, identifiée précédemment comme l'« API Integration Layer » et baptisée ici « MOeX Platform », joue un rôle central dans notre SI. Elle est organisée en trois couches hiérarchisées, chacune ayant un rôle spécifique :
API Gateways [IBM API Connect] :
Rôle : Point d'entrée unique et sécurisé pour les intégrations par APIs, garantissant uniformité et conformité aux données en transit.
Lien avec l'API First : Assure la première étape du découplage en isolant les systèmes métiers des détails techniques, tout en offrant une vue unifiée des échanges « système à système ».
Enterprise Service Bus [IBM ACE] :
Rôle : Responsable de la transformation et de l'orchestration des données en transit, accessible uniquement via les API Gateways.
Lien avec l'API First : Maintient la cohérence entre les « maîtres de données » et leurs consommateurs, tout en gérant les transformations de données entre modèles spécifiques et le modèle interne des différents domaines métiers.
Message Queues [IBM MQ] :
Rôle : Critique pour les échanges « Event Driven », il assure la sécurité des données en transit, garantissant leur livraison fiable et sécurisée.
Lien avec l'API First : Dernier maillon de la chaîne de transformation, assurant la livraison fiable des données aux systèmes souscripteurs d'events particulier.
Cette architecture hiérarchique garantit des échanges de données fluides, sécurisés et optimisés. Elle minimise les dépendances directes et assure résilience et flexibilité, de plus, elle s'aligne parfaitement avec notre stratégie API First.
API Gateways [IBM API Connect] :
Rôle : Point d'entrée unique et sécurisé pour les intégrations par APIs, garantissant uniformité et conformité aux données en transit.
Lien avec l'API First : Assure la première étape du découplage en isolant les systèmes métiers des détails techniques, tout en offrant une vue unifiée des échanges « système à système ».
Enterprise Service Bus [IBM ACE] :
Rôle : Responsable de la transformation et de l'orchestration des données en transit, accessible uniquement via les API Gateways.
Lien avec l'API First : Maintient la cohérence entre les « maîtres de données » et leurs consommateurs, tout en gérant les transformations de données entre modèles spécifiques et le modèle interne des différents domaines métiers.
Message Queues [IBM MQ] :
Rôle : Critique pour les échanges « Event Driven », il assure la sécurité des données en transit, garantissant leur livraison fiable et sécurisée.
Lien avec l'API First : Dernier maillon de la chaîne de transformation, assurant la livraison fiable des données aux systèmes souscripteurs d'events particulier.
Cette architecture hiérarchique garantit des échanges de données fluides, sécurisés et optimisés. Elle minimise les dépendances directes et assure résilience et flexibilité, de plus, elle s'aligne parfaitement avec notre stratégie API First.
L'approche API First se matérialise au sein de la plateforme au travers du pattern MOeX Services. C'est aussi un guide qui structure toutes les interactions "système à système" depuis la conception jusqu'au déploiement. Voici brièvement comment ce pattern est un gage de garantie en terme de cohérence, flexibilité, et efficacité dans la plateforme.
Deux Types de Services :
MOeX Services de type "Consumed" :
Scope : Gère les requêtes entrantes.
Rôle : Exposer des API basées sur un modèle de données standardisé, sous la gouvernance du domaine métier.
Fonction : Permettre aux consommateurs de respecter les standards métiers.
MOeX Services de type "Provided" :
Scope : Gère les requêtes sortantes.
Rôle : Traduire les requêtes du modèle standardisé vers les modèles propriétaires des systèmes fournisseurs.
Fonction : Assurer la compatibilité avec les systèmes sources tout en masquant les complexités techniques.
Cas d'usage :
Par exemple, un système du domaine A (CRM) qui nécessite des données du domaine B (Policy Center) enverra sa requête via un MOeX Service "Consumed". Cette requête sera ensuite acheminée àl'intérieur de la plateforme au MOeX Service "Provided" approprié, assurant ainsi une interaction fluide mais découplée entre les deux domaines.
Développement et Déploiement :
Les MOeX Services jouent aussi un rôle crucial dans le développement et le déploiement en tant que :
Contrats Déclaratifs de Release Management : Chaque service est défini par un contrat standardisé, facilitant la mise en œuvre de ses composants.
Enveloppes de livraison : Les services suivent des release coordonnées sans risques d'incohérences et de conflits entre versions.
Le pattern MOeX Services est la clé de voûte de notre stratégie API First. Il garantit des interactions systèmes standardisées, une maintenance simplifiée, et une évolution agile de notre SI. Enfin, et surtout, il permet à nos projets de se concentrer sur la création de valeur métiers qui est leur raison d'être en fait !
Nota Bene: Si jamais j'ai suscité de la curiosité, je me tiens à disposition pour fournir plus d'explications de vive voix :-)
Deux Types de Services :
MOeX Services de type "Consumed" :
Scope : Gère les requêtes entrantes.
Rôle : Exposer des API basées sur un modèle de données standardisé, sous la gouvernance du domaine métier.
Fonction : Permettre aux consommateurs de respecter les standards métiers.
MOeX Services de type "Provided" :
Scope : Gère les requêtes sortantes.
Rôle : Traduire les requêtes du modèle standardisé vers les modèles propriétaires des systèmes fournisseurs.
Fonction : Assurer la compatibilité avec les systèmes sources tout en masquant les complexités techniques.
Cas d'usage :
Par exemple, un système du domaine A (CRM) qui nécessite des données du domaine B (Policy Center) enverra sa requête via un MOeX Service "Consumed". Cette requête sera ensuite acheminée àl'intérieur de la plateforme au MOeX Service "Provided" approprié, assurant ainsi une interaction fluide mais découplée entre les deux domaines.
Développement et Déploiement :
Les MOeX Services jouent aussi un rôle crucial dans le développement et le déploiement en tant que :
Contrats Déclaratifs de Release Management : Chaque service est défini par un contrat standardisé, facilitant la mise en œuvre de ses composants.
Enveloppes de livraison : Les services suivent des release coordonnées sans risques d'incohérences et de conflits entre versions.
Le pattern MOeX Services est la clé de voûte de notre stratégie API First. Il garantit des interactions systèmes standardisées, une maintenance simplifiée, et une évolution agile de notre SI. Enfin, et surtout, il permet à nos projets de se concentrer sur la création de valeur métiers qui est leur raison d'être en fait !
Nota Bene: Si jamais j'ai suscité de la curiosité, je me tiens à disposition pour fournir plus d'explications de vive voix :-)