Bonjour,
Aujourd’hui je voudrais discuter avec vous sur le sujet qui me préoccupe actuellement – problèmes sémantiques liés aux données.
Tout le monde parle du data governance et des stratégies de gestion de données, mais ça reste la vision très-très globale. Je voudrais comprendre les mécaniques en détail car c’est ça, le travail que l’on fait tous les jours. J’ai préparé deux sujets pour vous et pour être franc, je n’ai pas trouvé beaucoup d’information concernant ces problèmes. Comme si ces problèmes n’existent pas…
Extension de définition
Prenons un exemple. Supposons que nous parlons d’un système de consolidation de données (tel que Data Hub ou Data Warehouse). Dans ce système nous pouvons assez certainement trouver des données historisées d’une manière un d’une autre.
Au début de projet, deux architectes décident qu’ils vont stocker des données en forme de « snapshots » réguliers. Autrement dit, chaque jour une nouvelle copie de données sera créée et pour garder les traces de cette historique, nos deux architectes prévoient d’utiliser un champ DATE_ETAT_DONNEES qui sera ajouté dans toutes les tables. Pour faire « bien », ils partitionnent les tables par ce champ.
Le temps passe et le système arrive au niveau quand il faut ajouter l’information comptable. Le problème est que la comptabilité est toujours en retard par rapport aux autres systèmes (exemple : le paiement reçu aujourd’hui ne sera lettré, i.e. lié à la facture, que dans quelques jours). En gros, tout ce que le SI comptable peut garantir, c’est qu’à la fin du mois suivant, les données du mois précédent seront complètes (si tout se passe bien et la lune est en bonne phase).
Les architectes décident alors, que le système comptable fonctionne par mois. Les tables reçues depuis ce système obtiennent aussi le champ DATE_ETAT_DONNEES « pour être homogène avec le reste ». Mais ce champ dans ces tables sera toujours positionné à la fin du mois précédent. Ça veut dire, que les flux de chargement quotidien du mois en cours mettent à jour « l’état » de la fin du mois précédent.
Vous voyez le problème ? Pas encore?
Dans quelques mois, il y a un nouveau besoin – il faut contrôler quotidiennement (et comparer avec les jours précédents) la progression de la clôture d’arrêté mensuel. C’est à ce moment-là, tout le monde a un circuit court dans la tête concernant les tables du compta : « c’est quoi exactement la progression (historique) d’un état qui lui-même est déjà l’historique du mois précèdent? ».
Il n’est pas possible d’historiser les données qui sont déjà historisées.
Dans la plupart des tables de notre système, DATE_ETAT_DONNEES signifie déjà la progression. Alors que dans les tables comptables ce champ est déjà occupé. Comment pouvons-nous stocker la progression ? Ajouter un champ VERSION_DE_DONNEES, DATE_DE_MISE_A_JOUR ?
Le problème est que les champs avec le même nom portent ici deux définitions sémantiquement différentes :
- pour la plupart des tables – date de « snapshot » (date de chargement),
- pour les tables comptables – date de fin du mois d’arrêté mensuel (i.e. contenu de données chargées).
Afin de comprendre cela, les architectes ont mis du temps. Mais c’est à cause du fait qu’ils sont habitués aux décisions déjà prises et ne peuvent pas avoir cette « vue de l’extérieur ».
Notre histoire se finira bien – ils vont corriger le problème. Par contre, ce n’est pas toujours un « happy end » qui attend tous les problèmes de ce type. J’ai une multitude d’exemples où les personnes « redéfinissent » la sémantique sans se rendre compte et cela leur pose des problèmes pour des processus métier complexes ou à l’intégration avec les systèmes externes (si vous travailles dans une banque – lisez « forçages de données » dans 80% des cas).
Drift de définition
Supposons que notre système de consolidation contient une table CONTRACTS et dans cette table il y a un champ CONTRACT_VALUE. Il existe depuis des années et contient l’information saisie au début de contrat en prévisionnel. Et vu que les prévisions se collent avec la réalité, personne ne fait vraiment attention jusqu’au moment quand les différences deviennent visibles.
Les nombreux tickets s’ouvrent et se ferment car il faut, par exemple, augmenter la valeur de contrats suite aux pénalités de retard de paiement, diminuer la valeur suite aux paiements en avance, gestes commerciales, etc… Et cela marche bien jusqu’au moment où l’audit interne trouve les incohérences entre ces valeurs corrigées et les informations précédentes.
Il semble que cela n’a rien en commun avec la sémantique, mais en fait si… Nous avons eu un champ défini vaguement en tant que « une valeur de contrat » qui était en réalité « valeur prévisionnelle du contrat au moment de la signature », alors que la nouvelle définition correspond plutôt à « la valeur prévisionnelle du contrat, réévaluée » (je fais des raccourcis et je ne vais pas définir « la valeur », alors qu’il le faut).
Le problème est que parfois, on n’est pas suffisamment précis dans nos définitions et chaque changement de règles doit se commencer par l’analyse de la sémantique avant/après la correction. Les demandeurs de changements aurait pu s’adapter à l’usage de nouveau champ UPDATED_CONTRACT_VALUE car le changement de flux pour l’ancien champ a causé des régressions chez les personnes non-concernées par les modifications… d’où le drift (dérive) de la définition.
Outro
- Les définitions sont rarement incorrectes. C’est le lien entre le terme (mot, objet, champ) et la définition qui peut être flou, se changer dans le temps ou même être multiplié.
- Je ne sais pas, pourquoi on n’en parle pas durant les formations BI… Je crois que la sémantique est le cœur du métier, mais nous apprenons plutôt les dimensions et les faits…
- Sinon, je n’ai pas vu de support de gestion de changement de définitions dans les « meilleurs systèmes de data governance ». On suppose que les termes une fois définies sont gravées en marbre. Est-ce que c’est le cas, à votre avis ?
Bonne santé à vous et à vos systèmes.