Mais elle est appréciée pour son adaptabilité, là où une modélisation en étoile perd de son agilité en cas d’évolution de l’organisation. Le Data Vault a ses défenseurs et ses passionnés. Mais alors, comment combiner une gouvernance des données orientée métier, et une architecture data vault forcément gérée par une équipe informatique experte ?
Data Vault ou pas, les principes fondateurs de la gouvernance des données, la connaissance, la qualité et la conformité, ne changent pas. Dans une architecture data vault, les données sont dupliquées et modélisées en plusieurs étapes : les données brutes, puis les données modélisées suivant l’architecture de Daniel Linstedt, puis les données prêtes à être consommées par les analystes métier, suivant leur vocabulaire.
En cela, l’ensemble du data vault ressemble à un data lake collectant les données brutes, puis un data warehouse les harmonisant, et enfin des data marts les spécialisant par métier. Mais le data vault propose de réaliser l’ensemble dans un même entrepôt. En cela, il nous facilite la traçabilité entre les différentes étapes ; cela explique sans doute la popularité de cette architecture dans des environnements où le suivi du cycle de vie des données est règlementairement important.
La version 1.0 de l’architecture data vault n’abordait que peu les aspects liés à la gouvernance. Mise en œuvre par une équipe informatique, les départements métiers n’étaient pas vraiment parties prenantes, pas plus que l’idée de gouvernance.
La version 2.0 de cette architecture, introduite en 2013, ajoute de nouveaux concepts, permet le traitement de données en temps réel, de données non structurées, et enrichit les métadonnées, facilitant ainsi l’implémentation et le contrôle automatisé des politiques de gouvernance.
La mise en œuvre d’un catalogue de données unique, regroupant les métadonnées métier et les métadonnées techniques, reste conseillé. Un tel catalogue n’est pas inclus dans le data vault, et devra être mis en place en parallèle. Le data vault étant moins populaire que les autres architectures décisionnelles, il sera sans doute plus difficile de trouver un éditeur de catalogue de données capable de lire automatiquement les Hubs, Links, et Satellites du data vault pour y récupérer les métadonnées. Un travail important de mise en correspondance devra sans doute être réalisé manuellement.
Le suivi du cycle de vie des données à l’intérieur du data vault sera en revanche facilité par le stockage des métadonnées, automatisé dans le data vault 2.0.
Il faudra cependant faire très attention à l’impact des fonctions d’écriture sur la traçabilité des données. Le data vault permet en effet aux utilisateurs d’écrire dans l’entrepôt de données. Si ces droits sont accordés trop largement, et sans mémorisation des modifications unitaires, c’est toute la traçabilité des données qui peut être mise en péril, rendant les phases d’audit inopérantes. Les data owners métier devront être impliqués dans les processus de collecte et de référencement des données dans le catalogue. Ils devront également apprendre à l’utiliser pour identifier les données disponibles dans l’entrepôt.
Côté qualité, le data vault permet d’appliquer des contrôles et des transformations sous forme de règles de gestion, techniques et métier. Il faudra veiller à la bonne documentation de ces règles, afin de rendre le processus auditable par les data stewards.
Enfin, vu sous l’angle de la conformité, le suivi du cycle de vie dans le data vault sera très utile aux équipes d’audit. Le DPO devra également se plonger dans l’architecture, avec l’aide des équipes informatiques, afin de s’assurer de la continuité des protections mises en œuvre autour des données personnelles. Il faudra s’assurer que les données personnelles brutes, collectées en entrée de l’architecture, conserveront bien cette propriété lors des phases de transformations, et que les données publiées dans les data marts en sortie, hériteront des mêmes protections. Les métadonnées du data vault l’aideront à réaliser les analyses d’impact obligatoires.
En résumé, le data vault est une alternative intéressante aux modélisations traditionnelles des entrepôts de données. Il est cependant opposé à la tendance du data mesh qui décentralise et donne plus de contrôle aux utilisateurs. Le data vault est une architecture centralisée, qui nécessite une expertise technique permanente. Elle conviendra aux départements informatiques qui souhaitent garder le contrôle.
Mais comme la gouvernance des données n’est plus une option, ces experts techniques devront apprendre à travailler avec les équipes de gouvernance et de conformité, même si le langage technique du data vault leur est pour l’instant inconnu.
Data Vault ou pas, les principes fondateurs de la gouvernance des données, la connaissance, la qualité et la conformité, ne changent pas. Dans une architecture data vault, les données sont dupliquées et modélisées en plusieurs étapes : les données brutes, puis les données modélisées suivant l’architecture de Daniel Linstedt, puis les données prêtes à être consommées par les analystes métier, suivant leur vocabulaire.
En cela, l’ensemble du data vault ressemble à un data lake collectant les données brutes, puis un data warehouse les harmonisant, et enfin des data marts les spécialisant par métier. Mais le data vault propose de réaliser l’ensemble dans un même entrepôt. En cela, il nous facilite la traçabilité entre les différentes étapes ; cela explique sans doute la popularité de cette architecture dans des environnements où le suivi du cycle de vie des données est règlementairement important.
La version 1.0 de l’architecture data vault n’abordait que peu les aspects liés à la gouvernance. Mise en œuvre par une équipe informatique, les départements métiers n’étaient pas vraiment parties prenantes, pas plus que l’idée de gouvernance.
La version 2.0 de cette architecture, introduite en 2013, ajoute de nouveaux concepts, permet le traitement de données en temps réel, de données non structurées, et enrichit les métadonnées, facilitant ainsi l’implémentation et le contrôle automatisé des politiques de gouvernance.
La mise en œuvre d’un catalogue de données unique, regroupant les métadonnées métier et les métadonnées techniques, reste conseillé. Un tel catalogue n’est pas inclus dans le data vault, et devra être mis en place en parallèle. Le data vault étant moins populaire que les autres architectures décisionnelles, il sera sans doute plus difficile de trouver un éditeur de catalogue de données capable de lire automatiquement les Hubs, Links, et Satellites du data vault pour y récupérer les métadonnées. Un travail important de mise en correspondance devra sans doute être réalisé manuellement.
Le suivi du cycle de vie des données à l’intérieur du data vault sera en revanche facilité par le stockage des métadonnées, automatisé dans le data vault 2.0.
Il faudra cependant faire très attention à l’impact des fonctions d’écriture sur la traçabilité des données. Le data vault permet en effet aux utilisateurs d’écrire dans l’entrepôt de données. Si ces droits sont accordés trop largement, et sans mémorisation des modifications unitaires, c’est toute la traçabilité des données qui peut être mise en péril, rendant les phases d’audit inopérantes. Les data owners métier devront être impliqués dans les processus de collecte et de référencement des données dans le catalogue. Ils devront également apprendre à l’utiliser pour identifier les données disponibles dans l’entrepôt.
Côté qualité, le data vault permet d’appliquer des contrôles et des transformations sous forme de règles de gestion, techniques et métier. Il faudra veiller à la bonne documentation de ces règles, afin de rendre le processus auditable par les data stewards.
Enfin, vu sous l’angle de la conformité, le suivi du cycle de vie dans le data vault sera très utile aux équipes d’audit. Le DPO devra également se plonger dans l’architecture, avec l’aide des équipes informatiques, afin de s’assurer de la continuité des protections mises en œuvre autour des données personnelles. Il faudra s’assurer que les données personnelles brutes, collectées en entrée de l’architecture, conserveront bien cette propriété lors des phases de transformations, et que les données publiées dans les data marts en sortie, hériteront des mêmes protections. Les métadonnées du data vault l’aideront à réaliser les analyses d’impact obligatoires.
En résumé, le data vault est une alternative intéressante aux modélisations traditionnelles des entrepôts de données. Il est cependant opposé à la tendance du data mesh qui décentralise et donne plus de contrôle aux utilisateurs. Le data vault est une architecture centralisée, qui nécessite une expertise technique permanente. Elle conviendra aux départements informatiques qui souhaitent garder le contrôle.
Mais comme la gouvernance des données n’est plus une option, ces experts techniques devront apprendre à travailler avec les équipes de gouvernance et de conformité, même si le langage technique du data vault leur est pour l’instant inconnu.
