Témoignages croisés d’un architecte SI et d’un consultant sur les démarches d’architecture et de data lineage

Comment mettre en place une démarche de data lineage ?

Toutes les entreprises sont maintenant conscientes des enjeux autour de la donnée. Cependant, la mise en place de projets et d’une organisation dédiée est un autre défi !

Nous accueillons deux Quentin pour une interview croisée autour de l’architecture data et plus précisément du Data Lineage. Quentin Lemaire, architecte des systèmes d’information chez NHOOD et Quentin P, consultant en architecture data nous font part de leurs retours d’expérience sur la mise en place de projets concrets autour des enjeux data.

Quentin Lemaire, tu es architecte des systèmes d’information au sein d’une DSI internationale. Comment cela s’organise au quotidien ? 

Quentin Lemaire : Mon quotidien est de maintenir à jour le référentiel d’architecture des solutions et des flux inter-applicatifs pour l’ensemble des pays NHOOD. D’un point de vue terrain, le premier impératif est d’être systématiquement informé de chaque sujet qui a trait à un changement au niveau des solutions informatiques. Et cela, autant pour de futures solutions que pour des évolutions de solutions déjà en place. En tant qu’architecte Solutions et Données,mes principales préoccupations sont sur les impacts fonctionnels et les impacts liés au traitement de la donnée de ces projets de transformation.

Nous avons établi un processus au sein de NHOOD : chaque partie prenante de l’organisation, et en particulier IT, remonte au PMO les sujets qui sont à adresser dans le cadre de projet de transformation. L’équipe PMO demande au responsable du changement de me solliciter pour faire un accueil d’architecture. 

De par ma mission d’architecte Application et Données, je dispose d’une vision transverse du système d’information avec une connaissance des interactions inter-applicatives. J’ai aussi une connaissance de l’architecture technique de NHOOD. Comme tous les membres de la DSI, j’ai été sensibilisé sur la facette RGPD. Grâce à cela, dès que je ressens une adhérence dans un projet de transformation sur l’un des items précédents, je peux impliquer la personne concernée : architecte technique, RSSI, service juridique ou contractuel, DPO, ainsi que le service production et le service support du futur chantier de transformation. 

L’objectif de ces accueils est de connaître toute nouvelle solution ou évolution d’une solution existante afin de référencer et suivre les risques potentiels induits par le changement au niveau du Système d’Information  et émettre des préconisations d’architecture et partager les retours d’expériences sur les projets précédemment réalisés sur le même sujet.  L’objectif des instances d’Architectures est d’accompagner le métier pour mettre en œuvre les outils informatiques dont il a besoin.

Avoir un bureau unique de récupération des projets permet de centraliser dans un référentiel l’ensemble des solutions présentes et à venir du Système d’information avec une définition fonctionnelle des solutions . Ce référentiel permet de ne pas démultiplier les solutions avec les mêmes fonctions : si une application existe déjà sur étagère par exemple. On peut s’apercevoir que, malgré tous les systèmes de communications et avec la crise sanitaire à laquelle nous sommes confrontés, les collaborateurs ne partagent pas toujours les solutions qu’ils utilisent !

 

Ainsi, pour chaque nouvelle solution, je la cartographie et la partage avec l’ensemble des parties prenantes de l’entreprise. Il ne s’agit pas de faire de l’architecture pour l’architecture, mais pour partager ce patrimoine avec toute l’entreprise.

 

Quentin P : Je te rejoins complètement sur ce point. Dès qu’il y a une gouvernance autour de l’architecture, le premier objectif est de s’assurer de la cohérence de toute solution proposée avec le SI. Sans passage par l’architecte, la solution sera développée indépendamment, sans réflexion globale, avec toutes les dérives que cela entraîne !

J’ai l’exemple d’un retailer où les solutions étaient développées de manière empirique. Les architectes se sont rendus compte que des applications avaient été déployées de manière spécifique alors que les solutions existaient déjà ailleurs ! Prévenir dès le début et récolter les informations pour remonter les alertes en cas de souci et les double-emplois apportent des gains pratiques à toute l’organisation.


Pourquoi concrètement la maîtrise de la data est un défi important pour NHOOD ?

Quentin Lemaire : Nhood est connu comme étant un opérateur immobilier mixte ayant pour rôle de gérer, animer, développer et transformer les sites existants en nouveaux lieux de vie.

Pour réaliser ces ambitions, Nhood s’appuie sur de multiples solutions informatiques qui doivent dialoguer ensemble et se transmettre des informations les unes aux autres. Cela s’effectue au travers de traitements informatisés et sécurisés, afin de limiter au maximum les re-saisies utilisateurs.

Au-delà des applications métiers, d’autres sources externes (type capteurs comptages client, utilisation du Wifi, …)  fournissent les données à nos datastores (Data Lake, et Datawarehouse). 

Les datastores permettent de structurer et consolider des informations de l’entreprise quels que soient leur provenance. Cela nous permet d’effectuer des contrôles des données et nous permet de remonter les anomalies rencontrées au métier propriétaire sur celles-ci. 

Le fait de centraliser les informations dans les datastores permet d’avoir d’autres leviers pour générer de la valeur pour l’entreprise : avoir une connaissance plus fine des clients enseigne ou des fournisseurs, connaître l’impact d’une action marketing sur le flux de clients dans une galerie marchande, contrôler des pics de consommation sur les sites (eau, électricité…)…

Quentin P: Dans mes différentes expériences, l’enjeu premier est souvent au niveau stratégique et décisionnel. Il repose aussi sur la compréhension des données et des processus opérationnels, avec des impacts terrains.

La traçabilité des données au niveau de la commande est par exemple essentielle dans le retail. Beaucoup de données, beaucoup de systèmes, avec en plus un fort impact sur l’image de marque !

 

Tout le monde utilise les données et est impacté dans son quotidien. Chacun a des besoins à son niveau, et les demandes redescendent souvent sur l’IT… qui n’a pas toujours les réponses.

 

Quels sont plus précisément vos enjeux au niveau du Data Lineage chez NHOOD ?

Quentin Lemaire : NHOOD se positionne autour de 3 métiers : le développement & la promotion immobilière, la gestion des Actifs et la gestion locative. 

Tous ces métiers génèrent de la donnée au cours des différentes phases du projet. Ces différentes phases permettent de donner une temporalité aux coûts générés par les projets, et les recettes qui vont en découler. Il est important de connaître la chronologie de production de la donnée, afin de pouvoir mieux l’organiser dans les datastores.

Nous disposons de nombreux systèmes sources pour lesquels nous devons être en capacité de réconcilier les données entre elles, quelle que soit leur provenance. Connaître la provenance de tel ou tel attribut, qui sera utilisé dans tel ou tel reporting ou application, est nécessaire pour valoriser au maximum l’information.

Le retour sur investissement n’est pas uniquement réalisé par une valorisation directe de l’exploitation de ces données. Mieux appréhender la donnée et son parcours, c’est focaliser son énergie sur la récupération de l’information le plus simplement et de façon optimum, cela aussi fait partie des retours sur investissement attendu par le Data lineage.

Le Data Lineage nous assure qu’à chaque transfert d’informations nous maîtrisons le cycle de vie de la donnée, par où elle est passée, et chaque micro-transformation qui a été opérée, jusqu’à la restitution finale. Cela dépasse la supervision des flux.

Le lien du Data lineage avec le dictionnaire de données n’est pas à négliger. Les différents métiers d’une même entreprise parlent des mêmes choses, avec un vocabulaire différent dans la réalité. La complémentarité du dictionnaire de données et du data lineage permet d’associer la définition des  champs métiers avec les champs techniques dans les différents datastores. 

C’est bien sûr la maîtrise des données dans le Système d’Information qui est en jeu ! Un changement d’outil au sein du système d’information par exemple. La connaissance des flux est un accélérateur : à partir du moment où nous contrôlons l’exhaustivité des informations qui transitent dans les flux, si une brique applicative disparaît, j’identifie immédiatement les impacts et comment accompagner le changement. C’est d’ailleurs un de mes objectifs avec la mise en place d’Azure Purview.

 

Vis-à-vis de la qualité des données, les outils de supervision permettent d’avoir des sondes et d’adapter les actions selon la priorité  / la criticité de la donnée pour l’entreprise. Suivant le niveau nécessaire de qualité de la donnée, on peut ainsi définir des règles différentes pour corriger les données dans les systèmes sources ou modifier les traitements et sondes afin d’avoir des données plus qualitatives. 

 

Quentin P, cela fait-il écho à des vécus en lien avec le Data Lineage dans d’autres projets  ?

Quentin P : Le Data Lineage a besoin de s’appuyer sur le dictionnaire de données, et par extension la gouvernance des données également. Le glossaire métier est un input essentiel pour tracer le cycle de vie des données.

J’ai plusieurs retours d’expérience où les organisations avaient en première étape travaillé sur les objets métiers et leurs représentations dans le SI, puis, une fois ce socle en place, avaient poursuivi sur la traçabilité et le Data Lineage.

Au sein des retailers, et en particulier dans des contextes internationaux, tracer l’origine de chaque donnée est un objectif : d’où elle vient, comment elle se transforme, qui la consomme… Côté IT, comprendre comment circule l’information requiert un temps important. Cela peut rapidement devenir du temps perdu si on ne consolide pas la connaissance. Comment être certain que la donnée est à jour ? Où faut-il la chercher ? Et chaque projet applicatif va avoir un impact !

Quels gages de succès et bonnes pratiques pouvez-vous nous partager autour de ces projets de traçabilité des données ?

Quentin Lemaire : Un gage de succès, c’est qu’il faut être entouré par des personnes sensibles à l’importance du traitement et de la restitution des données. J’ai ainsi mis en place, avec des collègues, un comité autour de la donnée qui regroupe des compétences diverses et complémentaires : des connaissances fonctionnelles sur les flux, sur le reporting et sur l’architecture solutions (portée par moi-même en tant qu’architecte et animateur).

La donnée est importante pour nous, informaticiens, mais pas uniquement. C’est notre rôle de promouvoir la valorisation de celle-ci, de sensibiliser chaque chef de projet au traitement optimum de chaque donnée dans le SI Nhood. Mon objectif, en tant qu’architecte, c’est de leur apporter les informations qui vont les intéresser sur l’existant, dans le cadre de leur projet de transformation, et de co-construire avec eux la solution de traitement pour maximiser la production de valeur pour l’entreprise. 

Je me suis fixé une règle : une architecture définie en début de projet peut varier dans le temps à partir du moment où le changement est partagé. Si un chef de projet fait une évolution, ce n’est pas grave tant qu’on le sait. Le point essentiel, c’est de maîtriser tout ce qui est fait dans le Système d’Information afin d’avoir connaissance de l’exhaustivité des changements et de reporter ceux-ci dans le référentiel d’architecture.

Il ne faut pas négliger les réticences des nouveaux chefs de projet et leur volonté d’être autonomes. Le but de solliciter une instance d’architecture n’est pas de les brider, mais au contraire de leur permettre d’avoir des entrants sur le contexte de leur projet de transformation, et de leur donner une direction pour que les actions soient menées de la manière la plus cohérente possible. Nous nous aidons, pour accompagner les chefs de projets, des cartographies du système d’information, du référentiel d’architecture, des retours d’expériences et des cahiers de normes. 

Les cahiers de normes vont permettre à un développeur, qui arrive avec son expérience, de développer de la même façon que ses prédécesseurs. Sans cadre / sans normes, trois développeurs ont toutes les chances de développer une solution de manière différente, ce qui risque de complexifier l’intégration des nouveaux développements par les équipes du RUN.

Les normes atténuent ces différences. Tout nouveau chef de projet bénéficiera d’un cadre conçu avec une vision d’amélioration continue.

 

Étant présent depuis 2002, comme tout architecte, je suis un peu la mémoire vivante, en complément des référentiels. Pourquoi cela a été fait ainsi ? Pour quelle raison a-t-on choisi cette option ? Tout nouveau chef de projet a besoin d’avoir un historique sur le périmètre qu’il va adresser. Il est alors assez facile de percevoir les avantages à collaborer avec les instances d’architecture  pour faire aboutir plus sereinement le projet sur lequel il a été mandaté !

 

Quentin P: Oui, acculturer sur l’importance de la donnée fait partie de notre rôle… et de nos leviers ! Les aspects de glossaire métiers et de data lineage doivent être inclus dans les projets. Cependant, face aux impératifs de délais, ce n’est pas toujours évident. Solliciter les chefs de projets, les rencontrer, trouver des acteurs qui seront des porte-paroles de la data, diffuser les bonnes pratiques, instituer un comité autour de la donnée sont inhérents à notre mission si nous voulons avoir de l’impact sur l’organisation.

Si les chefs de projets viennent facilement voir les architectes pour identifier ou accéder aux données pour leur projet et poser des questions sur les applications en périphérie, c’est souvent à nous d’impliquer sur les sujets liés au dictionnaire des données, au glossaire métier et au data lineage. Le retour sur investissement est moins direct et donc moins perçu. Les métiers ont déjà la connaissance, et ouvrir sur la traçabilité permet de leur faire percevoir l’avantage, pour eux. Souvent, les projets intègrent des métiers différents. S’ils ne se sont pas accordés sur les définitions, cela peut alors rapidement dériver !

 

Dans le contexte d’un autre retailer, des personnes travaillent spécifiquement sur les indicateurs. Sans vision globale du SI, il leur est très difficile de connaître la qualité et l’exactitude des données. L’association du data lineage avec le glossaire métier est un accélérateur pour comprendre les données !

Quel outillage a t il été mis en place autour des enjeux d’architecture et de data lineage ?

Quentin Lemaire : Nous sommes une PME, et nos choix dépendent aussi de notre budget ! L’objectif est toujours de proposer des solutions à bas coût et quand on a prouvé leur efficacité, on peut ensuite déployer d’autres outils plus aisément. 

Pour toute la partie référentiel, j’utilise l’outil Archi® qui est aligné avec TOGAF, et basé sur le standard ArchiMate. Au niveau de la production, ils utilisent un outil de supervision des flux. Shinken, équivalent  Nagios. Pour l’ordonnancement de production, nous avons fait le choix de Visual TOM.

Nous avons ensuite des outils de types ETL pour lesquels nous avons mené plusieurs changements technologiques. Nous utilisons  maintenant  Azure Data Factory couplé à du Azure Databricks, pour ce qui est du traitement complexe de la donnée.

Au niveau du Data Lineage et du Data Catalog, je mène actuellement un POC sur Azure Purview. 

Je suis convaincu qu’il vaut mieux co-construire une solution entre métier et IT plutôt que d’imposer une solution. Il y a forcément des aspects qu’on ne perçoit pas. Confronter les idées permet de faire ressortir la meilleure stratégie. C’est pour cela que je cherche à travailler avec des profils qui ont des objectifs différents, mais complémentaires.

Cette diversité permet d’éviter les biais cognitifs. Le responsable des flux va chercher à ne pas transformer les données, le fonctionnel va avoir envie de disposer des mêmes données en sortie qu’au départ, le reporting préfère les champs que les données calculées… et l’architecte va vouloir répondre au client et s’assurer que cela soit fait en cohérence et bien imbriqué dans le SI. C’est-à-dire avoir une approche avec des éléments unitaires, remplaçables et interopérables. Si on retire une brique du système d’information, on doit savoir identifier les impacts simplement, et tout doit continuer à fonctionner  !

 

« Je ne suis pas le dernier à être challengé, j’ai aussi mes biais cognitifs d’archi ! »

 

Quelles sont vos convictions sur les méthodes pour accompagner l’organisation sur les changements autour des enjeux de la donnée ?

Quentin Lemaire : Ma préconisation, c’est de mettre en place des rôles de data owners. Des propriétaires de la donnée côté métier ! Comme ils auront une sensibilité métier, ce sera beaucoup plus simple de faire discuter ensemble deux data owners. Ils comprennent la nécessité de parler le même langage, d’avoir des définitions communes…

C’est en cours au sein de NHOOD, et je préconise le fait d’avoir des data owners par métier. Ils auront pour rôle d’être garants  de la qualité des données dans les systèmes sources. Je préconise  aussi de les inclure dans les remontées des sondes sur la qualité des données. Corriger la donnée dans le système source est essentiel pour que celle-ci soit diffusée rectifiée dans le reste du système d’information .

Je suis convaincu que pour avoir des données de qualités dans les outils sources,  la première étape est d’accorder une existence concrète à ces rôles / des missions autour de la donnée. C’est-à-dire un rôle / une mission avec du temps pour réaliser les  tâches, et des objectifs clairs sur le traitement de la donnée : correction, … . Nommer, au sein de l’organisation, un propriétaire de la donnée ou un data steward est l’occasion de prendre conscience pour l’entreprise qu’il y a une charge nécessaire pour mener ces missions à bien.

Quentin P: Ces changements reposent ainsi au départ sur l’implication de la direction ! C’est ainsi que ces sujets deviennent prioritaires dans la tête des employés. J’ai vraiment vécu la différence sur les enjeux de gouvernance des données : l’implication des métiers était faible au départ, et s’est fortement développée quand la direction a pris le sujet en main.

 

Avec des leaders qui ont eux aussi comme objectif de travailler sur la data, tout va plus vite !

 

Vous faites référence au Data Owner. Quel est pour vous le profil à rechercher pour ce rôle ? 

Quentin Lemaire : De mon point de vue, les entreprises gagneraient à s’appuyer sur des data owners expert dans leur métier et qui ont aussi mis une expertise dans les outils. C’est ainsi qu’ils peuvent comprendre et connaître les impacts des changements sur le système d’information, dialoguer facilement avec les autres membres de l’équipe et être pour la DSI des relais actifs !

 

Une donnée de mauvaise qualité peut très bien n’avoir aucun impact sur le quotidien métier de ton équipe… et pourtant entraîner des conséquences pour les autres métiers !

 

Quentin P : Exactement ! J’ajouterai qu’un des points cruciaux pour le Data Owner est de bien embrasser son périmètre et en maîtriser les processus métiers. C’est aussi une question de savoir se projeter dans la cible à atteindre et les évolutions à apporter en fonction de la stratégie de l’entreprise.

Et sur le rôle d’architecte, quelles sont tes convictions ?

 

Quentin Lemaire : Il y a deux profils : celui qui vient de la technique, et le théoricien. De par mon expérience, j’aurai tendance à dire que pour une PME, il est préférable de s’appuyer sur un architecte avec un profil plus technique. Celui-ci pourra traiter de manière plus pointue les aspects terrains. Cependant, dans les grands groupes, les deux profils sont importants et se complètent. Le technicien peut être trop proche de la technique, alors que le théoricien pourra prendre de la hauteur.

Dans tous les cas, créer une relation de confiance avec les métiers est un prérequis. Cela repose aussi sur l’écoute et la prise en compte des demandes même si l’architecte n’a pas de solution immédiate. J’ai l’exemple d’une sollicitation que j’ai reçue de la part d’un métier qui avait besoin de récupérer des données de type Open Data. Le métier ne disposait pas de budget et il n’était pas possible de mettre en place de solution dédiée tout de suite. Malgré cela, je suis resté en veille pour le tenir au courant des possibilités de récupération des informations, en autonomie avec les outils qu’ils avaient à disposition. Oui, nous n’avons pas apporté de réponse immédiate, mais nous avons pris en compte son besoin, et nous sommes rentrés dans un dialogue constructif.

 

Le concept d’économie de la connaissance s’adapte tout à fait au domaine de l’architecture. Partager la connaissance de l’architecture de l’entreprise, c’est enrichir l’organisation ! La veille, la curiosité, l’écoute, la méthode et leurs partages font ainsi partie intégrante du rôle des architectes. 

 

Vous participez d’ailleurs à la communauté Archis m’aident. Qu’est-ce que cela apporte de partager entre pairs ? Rencontrez-vous les mêmes défis ?

 

Quentin Lemaire : Quelle que soit la taille de l’entreprise, les enjeux sont les mêmes. C’est la manière d’adresser ces enjeux qui change. Chez NHOOD, je suis le seul architecte Solutions et données alors que dans d’autres entreprises les architectes se comptent en dizaine ! 

Ce que j’apprécie dans “Archis m’aident”, c’est qu’il s’agit d’une communauté avec des enjeux partagés. Je participe à des communautés similaires au sein du groupe Mulliez, mais “Archis m’aident” me permet d’avoir des points de vue hors du secteur du retail.

Les échanges se font avec beaucoup de bienveillance. Chacun a une maturité différente sur l’architecture. Avoir ces différents retours d’expériences me permet de confronter mes idées avec d’autres architectes et de les structurer beaucoup plus efficacement que si j’avais travaillé seul. ça permet aussi de maturer des axes de communication plus lisible, tant pour l’IT que pour le  métier.

 

J’ai une véritable conviction sur l’architecture. Tout comme pour la construction d’un bâtiment, si tout n’a pas été architecturé en amont de façon cohérente en ayant des fondations solides sur la base d’un référentiel, on pourrait  se retrouver avec des aberrations au niveau du SI, tout comme on les aurait sur un bâtiment.

 

Quentin P: Je ne connais pas un seul architecte qui dit avoir la solution à tout. Partager tout, le bon comme les difficultés au sein d’Archis m’aident nous fait bénéficier d’une vraie prise de recul !

Projexion est un cabinet de conseil en architecture (entreprise et SI) et d’accompagnement des organisations dans leurs transformations, en particulier autour de la donnée.

Nous mettons à votre disposition un collectif de consultants avec des compétences variées et complémentaires : architecture, Data Stewardship, accompagnement au changement…

 

Soyez averti(e) de nos prochains évènements et publications via LinkedIn !