We are getting into semantics again. If we use words, there is a very grave danger they will be misinterpreted.
H. R. Haldeman
Récemment j’ai parlé avec une personne (intelligente) qui s’occupe d’un grand système informatique au juste milieu d’énorme société internationale… j’ai été positivement surpris jusqu’au moment où elle m’a dit qu’il n’y avait pas de raison de gérer l’état (cycle de vie) d’anciennes données (supprimées, inutiles).
En fait, les utilisateurs ont souvent la flemme de supprimer les lignes et de les recréer (les adresses, tiers, etc) – ils juste écrasent l’objet existant par le nouvel.
Mon visage à ce moment (« c’est une mauvaise blague ») :
Ce n’est pas pour la première fois que j’entends cet avis dans les contextes différents :
un « update » est équivalent à un « delete » plus un « insert »
A qui la faute que cette vision est tellement commune ?
C’est le CRUD (Create, Read, Update, Delete) – les interfaces que nous avons l’habitude d’utiliser. Quand on veut modifier les données de l’adresse, on a juste à cliquer sur le bouton « modifier ». Le système ne demande jamais pourquoi on veut modifier l’adresse : s’agit-il de l’ajustement, de déménagement, d’erreur de la saisie, du changement de nom de la rue. I.e. le système ignore le contexte.
Si vous avez entendu parler du concept BOOP (Back to Object-Oriented Programming) ou de la critique d’ORM, des POJOs ou des modèles anémiques, vous voyez où je veux venir…
Vos utilisateurs font ce qu’ils veulent avec les données sans expliquer le contexte ou la raison, mais ils ignorent complètement la sémantique cachée derrière ces modifications.
Ils ignorent également que derrière chaque système informatique utile il y a des consommateurs de données : systèmes automatiques, modules de remédiation, interfaces B2B, Business Intelligence, Data Hubs, etc. Ces consommateurs supposent que votre système ne fait pas « n’importe quoi », votre modèle respecte une certaine sémantique et que les changements sont prédictibles.
Exemples :
- Vous dites au système « il faut livrer X à l’adresse Y », puis vous prenez l’adresse Y et le modifiez.
- Que voulez-vous dire ?
- Est-ce que l’adresse a été vraiment modifié ou vous avez juste mis un accent sur le mot « bâtiment » ? Comment puis-je le savoir automatiquement ?
- Si l’adresse a été modifiée, faut-il que la commande de livraison de X se change ?
…et si le camion est déjà à Paris, alors que la nouvelle adresse est à Marseille ?
- Vous dites au système « il existe un client X, qui a signé les contrats C1, C2, C3 », puis vous rattachez ces contrats au client Y et supprimez le X.
- Comment faut-il interpréter le changement ?
- X a vendu ces contrats à Y ?
- X était le doublon de Y et on l’avait corrigé ?
- Si les contrats C1, C2, C3 sont des crédits ou des dérivés, comment allez-vous expliquer le changement au régulateur ?
- Certains régulateurs commencent demander la raison de changement… (voir European Market Infrastructure Regulation (EMIR)).
- Que doit faire le système BI derrière pour rétablir l’historique ?
- Si c’était une vente, il est important de garder cette historique.
- Si c’était juste un doublon, on peut corriger l’historique afin de proposer la vision plus propre.
- Que vont faire les SI si le nouvel client Z est saisi avec l’identifiant technique de X ?
- Comment faut-il interpréter le changement ?
En effet, tous les identifiants exposés aux SI externes (oui, vous allez le faire, bien évidemment) commencent à avoir le sens autre que « technique » malgré votre volonté. Le développeur ETL data engineer va considérer que la nouvelle ligne avec le même ID décrit le même objet qu’hier. Si vous n’êtes pas d’accord, il vous faudra expliquer au data engineer, comment faire autrement (i.e. comment déduire la sémantique des changements en observant juste le résultat des changements… ça commence à sentir l’Intelligence Artificielle).
J’espère que vous voyez l’ampleur du problème. Les IDs techniques portent de la sémantique. Les modifications de données aussi. Si votre SI ne trace pas des causes des changements de données (i.e. utilise le CRUD), formez vos utilisateurs qu’en cas de changement il faut définitivement supprimer l’ancien et créer le nouvel objet – il ne faut pas essayer de gagner 30 secondes en modifiant l’objet existant… surtout si votre SI est un MDM. 🙂
Bonne santé à vous et à vos données.
PS Random fact… Vous avez su que la ville natale d’Alan Kay est Springfield ?