Partir d’une feuille blanche pour construire son modèle d’entreprise objet ou son entrepôt de données en Data Vault est un luxe que peu de structures ont. En effet, toutes les entreprises et notamment les plus grosses « subissent » leur existant en termes de flux de données (extractions fusionnant et/ou agrégeant des données unitaires …) à partir des systèmes opérationnels vers leur(s) système(s) BI.
Alors mettons les pieds dans le plat tout de suite : on ne construit pas un système Data Vault dans le but de décommissionner son legacy BI car on ne « remplace » pas un (des) système(s) BI existant(s) par un système Data Vault !!!
Pourquoi : tout simplement parce que les 2 sujets, bien que complémentaires, sont très différents en termes d’usages et d’objectifs !
- Le système BI, par essence, est orienté « besoins en reporting / pilotage métier »
- Le système Data Vault (cf. nos autres articles à ce sujet), est orienté objets d’entreprise et processus métiers
On peut cependant (et c’est la bonne démarche à adopter), commencer à construire son système Data Vault et, au fur et à mesure de l’intégration des objets métiers, on va pouvoir construire l’étage supérieur « Information Mart » qui *lui*, étant l’étage orienté besoins métiers, va nous permettre de remplacer/décommissionner les systèmes BI Legacy.
Il y a 2 pièges majeurs dans lesquels il faut éviter de tomber quand on veut faire concomiter la mise en œuvre d’un système Data Vault et le décommissionnement de son legacy BI :
- Rester dans une vision silotée « flux » / « application source » et donc vouloir migrer/décommissionner système BI après système BI en migrant les flux vers le système Data Vault. Ceci ne pouvant mener qu’à la répétition d’éventuelles erreurs passées et distordre ce qui aurait dû être un modèle global.
- Vouloir à tout prix éviter d’impacter les systèmes « sources » opérationnels sur leurs extractions alors que les extractions existantes ont été produites dans un contexte et une logique ne correspondant pas forcément à la mise en œuvre de règles transverses.
Quand on a un peu d’expérience sur Data Vault, le 1ier point est logique, lié aux basiques même de la mise en œuvre de Data Vault : on ne réfléchit pas à la définition d’un objet et de sa clé métier uniquement dans le contexte d’une seule application de gestion mais bien dans le contexte global de l’entreprise.
Exemple :
- dans le monde de l’assurance, la notion de client d’un contrat peut varier en fonction des types de contrat (collectifs, personnels…) dans les systèmes de gestion dédiés. Ainsi, dans certains, le client sera le client souscripteur (relation 1..1 en partant du contrat) et dans d’autres le client sera le client bénéficiaire (en relation 1..N en partant du contrat) ;
- de plus potentiellement les notions de contrat, pourtant proches, n’auront pas les mêmes clés métiers : dans certains cas, le numéro de contrat sera le seul élément de la clé et dans d’autres on pourra intégrer une notion complémentaire de sous-type de contrat, sans parler du fait qu’un même numéro de contrat pourra exister dans 2 systèmes de gestion différents (IRD et Vie par exemple) donc il faudra bien mettre en place un discriminant complémentaire…
Conclusion :
Que l’on soit *ou pas* dans le cadre d’une volonté de décommissionner un existant, la mise en œuvre d’un système Data Vault garde les mêmes préceptes :
- Remettre au cœur de l’équation une gouvernance de la donnée :
- Quels sont mes objets métiers ?
- Quels sont les systèmes « maitres » (création, modification, suppression) de la donnée et quels sont les systèmes consommateurs ? Quelle est la transmission de la donnée entre les différents services et donc sa propagation dans les différents systèmes opérationnels ?
- Travailler avec l’ensemble des métiers qui utilisent les objets métiers pour détailler avec eux les processus et la définition de ces objets métiers (ou les définitions car souvent il y a divergence entre les différents métiers…)
Concernant le 2e piège (et je dis bien le 2e et non pas le 2nd car il y en a d’autres 😉), remettons encore une fois les pieds dans le plat : à moins de disposer déjà d’extractions des systèmes de gestion non filtrées (en ligne et en colonne), non agrégées, non mergées, il faut prévoir des budgets pour les systèmes opérationnels afin qu’ils recréent des extractions en cohérence avec le système Data Vault à construire.
En synthèse :
- Il ne faut pas confondre système BI et système Data Vault : on ne remplace pas l’un par l’autre
- Le design Data Vault est et restera pour longtemps la modélisation la plus pertinente pour mettre en place un modèle d’entreprise objet
- Un système BI se caractérise lui par une modélisation plutôt en étoile/flocon voire des vues « à plat » (ces dernières pouvant à présent être plus efficaces sur certaines analyses basées sur des données brutes) …
N’hésitez pas à nous contacter pour en savoir plus 😉
Commentaires récents