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.