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