Limitations
Un des postulats fondamentaux de cette méthodologie et donc un des points primordiaux dans les phases de conception réside dans la détermination des clés métiers (BK : Business Key) et de leur immutabilité dans l’ensemble des processus et des systèmes sources considérés : la définition de la BK (et les attributs la constituant) doit être la même et partagée entre tous les métiers de l’organisation et tous les processus.
Or dans certains cas, cette immutabilité peut être très difficile à déterminer (les différents métiers doivent tomber d’accord sur une définition d’une BK commune), voire aboutir à une impasse…
En effet, on peut considérer dans certains cas que la connaissance d’un objet métier s’améliore et s’affine au fur et à mesure de la captation des données qui y sont liées ; ainsi dans le cadre d’un processus d’acquisition et connaissance Client / Contact via les actions Marketing et Ventes. La consolidation des données et la vision 360° sur l’ensemble du cycle de vie des données peut se complexifier grandement dans un tel exemple, simplement parce que les informations recueillies au tout début du cycle de vie peuvent être très (trop…) fragmentaires pour garantir l’unicité de la définition d’un Client / Contact (ex : un seul mail est renseigné et change ensuite en tant qu’information de contact principale, les noms et prénoms sont renseignés sans date de naissance… et quand bien même cela suffit-il à garantir l’unicité d’un Contact ???).
Bref on peut se trouver dans certains cas sur une absence de définition de BK satisfaisante (concernant l’identification unique d’un objet et donc la garantie d’absence de doublons), le temps que la connaissance Client / Contact s’améliore au fur et à mesure de l’acquisition de données pour en garantir une unicité.
D’ici en arriver à ce point, quid des données historiques « incomplètes », mais pouvant pourtant constituer des informations de base vitales pour certains indicateurs (ex : efficacité Marketing sur les premiers points de Contact) ; ce qui nécessite de rapprocher les informations pour les agréger sur un objet unique afin d’en obtenir une vraie vision 360°.
Dans ces cas, si l’on s’en tient strictement à la notion de BK, qui doit être parfaitement définie, unique et partagée entre les différents secteurs, processus et systèmes métiers, on constate une limitation évidente dans le fait que le BK doit être figée pour adresser l’ensemble de la traçabilité d’un objet et son auditabilité.
Les possibilités d’amélioration
Il est cependant possible de contourner cette limitation et ce manque de souplesse. Et ce en s’appuyant sur des structures existantes de Data Vault, sans en détourner ou dévoyer la méthodologie et ses définitions de quelque manière que ce soit.
Rappelez-vous l’atout primordial de Data Vault en ce qui concerne la souplesse et l’évolutivité de la modélisation : ces facilitateurs reposent principalement sur les Links et leur capacité d’absorption à représenter des relations faiblement contraintes (N-N) et évolutives.
Ainsi un type de Link particulier peut être mis en œuvre : le « Same-As » Link ; il s’agit, comme son nom l’indique, d’un simple lien réflexif caractérisant le fait que 2 objets techniquement différents (2 BKs différentes) représentent finalement le même objet métier.
La mise en œuvre de ces Same-As Links particuliers peuvent représenter une complexité d’implémentation supplémentaire, mais très loin d’être insurmontable, pour peu que :
- L’on puisse se reposer sur des informations techniques partagées entre les systèmes traitant d’une donnée dont l’identification est enrichie au fur et à mesure de sa propagation : transmission des identifiants techniques d’un système amont vers un système aval.
- Resynchronisation vers l’amont des identifiants techniques, notamment utile où des processus de dédoublonnage existent dans un système aval. L’avantage de conserver l’historique des données au niveau d’un EDWH est que ce point est optionnel, car l’historisation conservera de toute manière les évolutions à un instant T et les relations entre BK et identifiants techniques dans chaque système.
- Détermination d’une BK de référence unique, basée notamment sur la précédence des systèmes et la date de création des objets. Ceci afin de conserver toujours les mêmes identifiants techniques au final dans les dimensions ou axes d’analyse.
Ce processus d’utilisation des Same-As Links peut évidemment être renforcé par des processus de Data Quality pour fiabiliser et améliorer le dédoublonnage des objets autrement que par des synchronisations d’identifiants techniques entre systèmes sources, au niveau du Business Data Vault, afin de rajouter des critères secondaires de rapprochement, même s’ils ne font pas partie intégrante de la BK.
Et ce tout en conservant la définition des objets de base du Data Vault et les contraintes de traçabilité faisant partie des exigences de la méthodologie !
Commentaires récents