A notre niveau de cabinet de conseil et d’architecture des SI, il nous paraît indispensable d’ajouter notre pierre à cet édifice. D’autant que les précités n’ont pas tout dit…
Le Numérique Durable: pourquoi faire ?
On le dit et le redit et c’est bien le sous titre de notre travail : L’architecture est “Green by design”. En effet, depuis longtemps les architectes construisent des SI solides, non redondants donc sobres en fait…
Sans compter le temps passé à challenger les métiers sur leurs besoins. Et à éviter les travaux inutiles… Faire et défaire c’est du travail inutile et si on peut éviter c’est toujours ça d’économisé…
4 grands thèmes qui ne sont pas propres à l’architecture
Nous avons voulu que notre travail puisse être adapté en tant que guide à beaucoup d’expertise en plus de l’architecture :
Gouverner et former : qu’est ce que votre expertise / discipline / domaine de compétences peut mettre en place dans sa gouvernance et dans la formation des personnes pour intégrer les dimensions de responsable et de durable ?
Mesurer et montrer : que va-t-on pouvoir mesurer dans votre discipline et quels résultats va-t-on pouvoir montrer ?
Challenger : quels sont les thèmes ou autres domaines sur lesquels vous allez pouvoir challenger pour aller vers la diffusion des bonnes pratiques ?
Concevoir : quelles sont les bonnes pratiques lors de vos travaux de conception qui peuvent permettre d’aller vers plus de durabilité ?
Les architectes au coeur du Système d’Information
Le travail des architectes est on le rappelle ci-dessous :
L’Architecture d’Entreprise organise le dialogue entre les différents corps de métier pour définir une vision commune de l’entreprise de demain et de son SI, ainsi que la trajectoire pour y parvenir. Elle met en œuvre les approches nécessaires pour assurer la connaissance, la gouvernance et le pilotage opérationnel du SI.
A ce titre, les architectes sont au coeur des SI et des transformations et doivent donc jouer un rôle d’influenceur dans la direction du Numérique Durable. Ce guide est là pour fournir des clés à cette population particulière.
J’ai pu constater régulièrement que beaucoup de gens s’emmêlent les pinceaux quand il est question de définir et d’expliquer les différences entre Service Mesh, Event Mesh et Data Mesh.
Ces trois concepts, au-delà de l’utilisation du mot “Mesh”, n’ont pas grand chose de semblable. Quand d’un côté, nous avons :
Le Service Mesh qui est un pattern technique pour les microservices, qui se matérialise par la mise en place d’une plateforme qui aide les applications en ligne à mieux communiquer entre elles de manière fiable, sécurisée et efficace
L’Event Mesh, qui est un pattern technique d’échanges, afin de désiloter les différentes technologies de messaging
Et le Data Mesh qui lui, est un pattern général d’architecture de données, qui se matérialise par toute une série d’outils à mettre en place, et qui pousse le sujet de la productification de la donnée
On se dit déjà que comparer ces trois patterns ne fait pas sens ! Néanmoins, il y a peut-être un petit quelque chose, une évidence naturelle, qui peut découler de la comparaison.
Mais commençons donc d’abord par présenter nos trois protagonistes !
Le Service Mesh, ou la re-centralisation des fonctions régaliennes des microservices
Historiquement, l’approche microservice a été motivée, entre autres, par cette passion que nous autres informaticiens avons souvent, pour la décentralisation. Adieu horrible monolithe qui centralise tout, avec autant d’impacts que de nouvelles lignes de code, impossible à scaler en fonction des besoins fonctionnels réels. Sans compter qu’on peut quasiment avoir autant d’équipes de développement que de microservices ! A nous la scalabilité organisationnelle !
Cela a abouti, de manière simplifiée bien sûr, au schéma suivant :
Chaque microservice discute avec le micro service de son choix, indépendamment de toute considération. La liberté en somme ! Mais en y regardant de plus près, on voit bien une sous-brique qui est TRÈS commune à tous les microservices, ce que j’appelle ici la “Technical Logic”. Cette partie commune s’occupe des points suivants :
La découverte de services
La gestion du trafic
La gestion de tolérance aux pannes
La sécurité
Or quel intérêt à “exploser” cette partie en autant de microservices développés? Ne serait-ce pas plutôt une horreur à gérer en cas de mise à jour de cette partie? Et nous, les microserviciens (désolé pour le néologisme…), ne serions nous pas contradictoire dans nos souhaits de décentralisation? Oui! Car autant avoir une/des équipes dédiées à cette partie, qui travaillerait un peu de manière décentralisée, mais tout en centralisant sur elle-même ce point?
C’est ainsi qu’est apparu le pattern de Service Mesh, décrit dans le schéma suivant :
Dans ce pattern, les fonctions techniques sont définies de manière centralisée (Control Plane), mais déployées de manière décentralisée (Data Plane) afin de toujours plus découpler au final son architecture. Et cela se matérialise par des plateformes comme Consul ou Istio, mais aussi tout un tas d’autres plus ou moins compatibles avec votre clouder, voire propres à votre clouder.
Maintenant que nous avons apporté un premier niveau de définition pour le service mesh, allons donc voir du côté de l’Event Mesh !
L’Event Mesh, ou la re-centralisation pour désiloter
L’histoire informatique a eu l’occasion de voir tout un ensemble de solutions de messaging différentes, avec des origines différentes. Qu’on retourne à l’époque des mainframes, ou qu’on regarde de côté des technologies comme Kafka qui ont “nourri” les plateformes Big Data, les solutions se sont multipliées. Et c’est sans compter le fait de faire du messaging par dessus du http!
On obtient donc assez facilement des silos applicatifs qui sont freinés dans leur capacité à échanger, comme montré sur le schéma suivant :
Certes, les solutions de bridge existaient, mais elles permettaient souvent de faire le pont entre seulement deux technologies en même temps, le tout avec des difficultés à la configuration et l’exploitation.
Et si on rajoute le fait qu’un certain nombre d’entreprises se sont dit qu’il serait intéressant d’utiliser les technologies propriétaires de chacun de leurs clouders, on imagine bien les difficultés auxquelles elles font face.
Est donc apparu le pattern Event Mesh, imaginé entre autre, implémenté et popularisé par l’éditeur Solace, qui permet de centraliser sur une solution unique, capable entre autres d’avoir des “agents” locaux aux SI (selon la zone réseau, le datacenter, le clouder, le domaine métier, etc…). Digression mise à part, on notera que le terme Event Mesh a été repris aussi bien par le Gartner que par des solutions open-source.
Indépendamment des architectures de déploiement, cela nous donne l’architecture simplifiée suivante :
Son intérêt vient qu’on peut ainsi relier tout le monde, y compris du Kafka avec du JMS, ou avec des API.
Le Data Mesh, décentralisation ou relocalisation des compétences ?
Le Data Mesh, de son côté, vient de son côté en réaction d’une précédente architecture très centralisée, faite de Data Lake, de Datawarehouse, de compétences BI, d’intégration via ETL ou messaging, le tout géré de manière très centralisée.
En effet, il était coutume de dire que c’est à une même équipe de gérer tous ces points, faisant d’eux des spécialistes de la data certes, mais surtout des grands généralistes de la connaissance de la data. Comment faire pour être un expert de la donnée client, de la donnée RH, de la donnée logistique, tout en étant un expert aussi en BI et en intégration de la donnée?
Ce paradigme d’une culture centralisatrice, a du coup amené un certain nombre de grosses équipes Data à splitter leur compétences, créant toujours plus de silos de compétences. De l’autre côté, les petites équipes pouvaient devenir très tributaires des connaissances des sachants métiers. Si cela vous rappelle les affres de la bureaucratie, ce serait évidemment pur hasard!
Ci-joint une représentation simplifiée de l’architecture dont nous avons pu hériter :
C’est ainsi qu’est apparu le pattern Data Mesh. Dans ce pattern, ce sont aux équipes Domaine de :
Collecter, stocker, qualifier et distribuer les données
Productifier la donnée pour qu’elle ait du sens à tous
Fédérer les données
Exposer des données de manière normée
Ce qui impose en l’occurrence de :
Mettre en place un self-service de données
Participer activement à la gouvernance globale
Et d’avoir un nouveau rôle de Data Engineer, qui doit mettre en place la plateforme de données pour justement faciliter techniquement, et proposer des outils.
Nous avons donc en schéma d’architecture le suivant :
Mais alors quid des points communs ?
Et en réalité, le gros point commun de ces trois patterns, c’est leur histoire !
Les trois proviennent de cette même logique centralisatrice, et les trois cherchent à éviter les affres d’une décentralisation dogmatique. A quoi cela sert de décentraliser ce que tout le monde doit faire, qui est compliqué, et qui en vrai n’intéresse pas tout le monde?
Et à quoi cela sert de forcément tout vouloir centraliser, alors même que les compétences/appétences/expertises/spécialisations sont elles-même “explosées” en plusieurs personnes ?
Certes, la centralisation peut avoir comme intérêt de mettre tout le monde autour de la même table, ce qui peut être intéressant pour de gros projets qui ne vivront pas, ou quand on est dans des phases d’une maturité exploratoire…
Et cela pousse tout un ensemble de principes, dont entre autre (liste non exhaustive):
Découvrabilité : Il faut pouvoir retrouver les services et les données simplement, en les exposants via des « registry » dédiés simples d’accès
Flexibilité et évolutivité : Il faut qu’une modification dans l’infrastructure ou dans un domaine puisse être accueilli sans douleur
Sécurité : Les politiques de sécurité sont propres aux champs d’actions de ces patterns, et sont donc inclus dans ces patterns
Distribution et autonomie : On distribue les responsabilités, les droits et les devoirs, afin de construire un système robuste organisationnellement
Alors oui, je vous entend marmonner “Et oui, c’est toujours la même chose! C’est comme ça”.
Mais en fait pas forcément ! En ayant en tête :
Ces éternels mouvements de yoyo,
Le Domain Driven Design qui est aussi un point commun au Data Mesh et à l’Event Mesh,
Face aux différentes évolutions réglementaires, un programme a été constitué au sein de la filiale d’Affacturage, intégrant :
Le nouveau moteur de calcul de provisions IFRS9 et le calculateur d’assiette (RWA)
La nouvelle méthode de calcul (IRBF/Standard)
L’alimentation des plateformes groupe cibles :
Assiette fournie au calculateur Bâlois du groupe
Alimentation des outils de reporting groupe
Contrôle de cohérence entre filiale et groupe
Simulation par la filiale de son niveau de Risque.
Solution
La mission de Direction de Programme consiste à assurer la cohérence, maîtriser les adhérences, les chevauchements de plannings et les échéances imposées.
L’intervention a mobilisé un profil Senior Manager :
Forte expérience de pilotage de programme
Capacité de dialogue avec tous les acteurs, métier (Risques, Clientèle…) et IT
Expertise pour sécuriser les chantiers à forte compétence métier : garanties, notation tiers, défaut client/acheteur, FBE/NPE, grappage…
Liaison Groupe : Schéma Directeur Finance Risque, calculateur groupe…
Bénéfices
Livraison des chantiers Notation et Défaut Client
Solution transitoire de prise en compte des garanties
Gain en RWA
Respect des recommandations de l’audit interne et validation des normes BCE
Les autres success stories qui peuvent vous intéresser
Dans le cadre de la mise en œuvre de la nouvelle norme IFRS 9, BPCE a initié dès 2015 le programme qui prend en charge les impacts sur l’ensemble des métiers du Groupe (Finances, Risques, Comptabilités et Consolidation…) :
Classification des instruments financiers au niveau de chaque établissement ;
Révision des plans et schémas comptables ;
Définition et simulation des modèles de dépréciation, avec spécification d’un moteur centralisé.
Missions
Accompagnement de la Direction des Risques Groupe et de la Direction des Comptabilités Groupe dans la formalisation des expressions de besoins sur :
Les Tests SPPI & Business Models ;
La Gestion des Dépréciations ;
La structuration des annexes, en lien avec les évolutions du FINREP ;
Le chronogramme de production et son insertion dans les processus existants ;
Structuration modulaire des fonctionnalités de l’outil centralisé de gestion des dépréciations : segmentation IFRS 9, fonctions de calcul, affectation des provisions, restitutions aux établissements au niveau détail contrat et agrégé comptable (production CRE) ;
Définition des échanges de flux entre les communautés informatiques et le Groupe, et au sein des SI de l’organe central (COREP, FINREP, Consolidation…) ;
Formalisation des dossiers d’architecture fonctionnelle et applicative ;
Animation des comités d’architecture fonctionnelle Groupe et communautés IT.
Bénéfices
Contenu fonctionnel partagé entre les différents acteurs du Groupe ;
Architecture cible définie et partagée aux différents niveaux du Groupe, intégrée à la stratégie d’évolution des SI et alignée sur les exigences BCBS 239 ;
Meilleure maîtrise des enjeux et des risques des projets de la filière SI ;
Définition d’une trajectoire réaliste pour le démarrage du 1er janvier 2018.
Les autres success stories qui peuvent vous intéresser
Au sein de l’équipe Risk Solutions / Risk Monitoring & Synthesis, participer à des chantiers d’évolutions liés à la mise en place des reporting des données risques de crédit pour les besoins réglementaires (programme Filière Unique) et de monitoring (application Global Vision).
Et ce dans le contexte du système de Core Banking ATLAS 2, utilisé par CIB International et par de nombreuses entités « Retail » du Groupe.
Missions
Recueillir les besoins sur les évolutions de monitoring et de reporting des risques de crédit en organisant des séances d’entretiens utilisateurs ;
Elaborer une priorisation des demandes (planification et suivi) ;
Rédiger la documentation fonctionnelle en adéquation avec les besoins exprimés et les solutions proposées (note d’initialisation, expression des besoins) ;
Etudier les solutions susceptibles de répondre aux besoins exprimés en collaboration avec la MOE et valider ces solutions ;
Préparer et exécuter des tests fonctionnels (organisation de la recette et rédaction des cahiers de recette) ;
Organiser et suivre le déploiement des évolutions en collaboration avec les équipes support et déploiement ;
Assurer le support et la formation des utilisateurs (procédures et guides utilisateurs, accompagnement au changement).
Bénéfices
Apport d’expertise Risques de Crédit ;
Optimisation de la supervision et de la coordination des différents projets ;
Gain en efficacité au niveau du suivi et de la prise en charge des actions à mener ;
Renforcement du contrôle de la qualité des livrables.
Les autres success stories qui peuvent vous intéresser
