Dernière modification le 1 décembre 2023
La stratification historique des S.I. a conduit à hériter d’une équation complexe quant au support des données.
Cette complexité a de nombreuses conséquences dès lors que l’on cherche à exploiter les données en dehors de leur cadre d’origine (données enfouies) et dans une vision globale patrimoniale.
Elle est un frein pour toute intention data driven et data centric (cf https://www.datassence.fr/2023/06/02/data-centric-data-driven-data-hub-data-warehouse-data-lake-data-fabric-data-mesh-sauriez-vous-situer-ces-differents-paradigmes-data/ ).
Les termes de l’équation
1) Le nombre de sources (points) de données à considérer et leur emplacement / nature :
Progiciels, SGBD – d’applications ad hoc, ODS/DW/DM, Stack big data, Data Lake, Clouds (multi), Fichiers : csv, tableurs – xls…, Data market place – datasets.
Ces sources peuvent être internes, externes, actives, oubliées (dark data), archivées, répliquées, backupées.
2) Le nombre de structures différentes des données représentées, de formats utilisés :
Données structurées – modèles – schémas : client, produit, transaction, personne morale, contrat… (modèles : relationnel, graphes, multi-dimensionnel, vault…)
Données non structurées : documents, texte, images, vidéos, sons
Formats : XML, JSON, Parquet… web sémantique
3) Le nombre de techniques d’accès aux données à partir des sources de données :
Query language – SQL, Extraction : ETL, ELT, API – Graphql, web services, Messages, Fichiers, Data connectors (ODBC, JDBC…) et le cas échéants les modes d’indexations.
4) Le mode de distribution des données : mise en relation des sources de données avec des consommateurs et les contraintes associées de sécurité et de SLA :
Automatisés (protocoles), point à point, via un hub/bus d’échange, par API management, en mode message, à la demande, shadow extraction, push-pull, synchrone / asynchrone, gestion de caches, colonnes de type JSON et de proxy pour les optimisations.
5) Les lieux de consommation des données
Dans des systèmes physiques : Desktop, mobiles, systèmes embarqués jusqu’à des logiques de type BYOD (Bring Your Own Device).
Et également parfois cachées dans des systèmes logiciels : dans des data visualisation / tableaux de bord (pour des fonctions de drill / zoom sur les données), dans les paramètres des moteurs d’IA.
6) Le nombre de formats de métadonnées mises à disposition soit directement par les sources, soit par des solutions de catalogage des données.
Exemples de métadonnées : formats des données, structures des données, définitions (dictionnaire), lineages, éléments de data management (sensibilité, statut, certification…des données, paramètres de sécurité – autorisations sur les données), logs techniques.
7) Les caractéristiques en termes de contenu : volumes des données, portées des données contenues dans la source (périmètres présents, catégories présentes).
Avec pour chacun de ces termes un facteur d’évolution continu à tenir compte (nouvelle source, décommissionnements, versions, variantes, ajout de types de données, nouveau formats, nouvelle catégorie de données prise en compte…).
Ensuite à partir de ces éléments, un certain nombre d’usages vont être fait des données. Usages qui vont amener à manipuler les données (nettoyage, filtrage, enrichissement…) :
Exemples d’usages : données embarquées (process, services, canaux, calculs, jumeaux numériques…), EDA, vues (360°), décisionnel, data science, IA.
Sans oublier les situations de copies (plus ou moins maîtrisées) des données dans les environnements de développement, de test, d’intégration.
Finalement on est face à l’équation suivante dès lors que l’on cherche à avoir une vision des données dans les S.I. :
Et à cette équation, il faut rajouter la contrainte « humaine » sur les données : freins au partage, luttes de chapelles, déresponsabilisation, choix politique.
Les conséquences de la complexité de l’équation
La complexité résultante se traduit par : des silos de données, de l’hétérogénéité, des écarts (sémantique, contenus), du recouvrement – de la redondance (overlap, multimodalité), des couplages plus ou moins forts (dépendances entre sources, données … rigidité), des ruptures dans les SLA -moyens de supervision de bout en bout.
Les conséquences de la complexité :
- En premier lieu un cout important,
- Une difficulté de contrôlabilité des données : fuites, encadrement – gouvernance, confiance, catalogage – lineages structurels et d’exécution, monitoring,
- La difficulté à répondre aux besoins holistiques : visions de bout en bout, ensembliste, patrimonial (connaissance, réglementaires, sensibilité des données), observabilité des données, traçabilité.
Certains parlent de « chaos data » – de data entropy ! (voir : https://www.datassence.fr/2023/06/08/revue-data-du-mois-mai-2023/#_ftn8 )
Et aussi
- Facebook ne sait pas où sont les données personnelles dans ses systèmes (https://www.datassence.fr/2022/09/12/maman-jai-perdu-les-donnees-data-lineage-et-data-observability-episode-1/ )
- Le burn out des profils data : chief data officer, data engineer, data scientist, data manager, data architect (https://www.datassence.fr/2023/05/11/revue-data-du-mois-avril-2023/#_ftn1 et https://www.datassence.fr/2023/06/08/revue-data-du-mois-mai-2023/#_ftnref8 )
Bon courage donc à tous ces acteurs !
Et si cette équation peut leur servir à justifier l’achat de cachets d’aspirine 😉
A suivre, les initiatives pour résoudre l’équation : indexation globale – central data repository – data discovery, data mesh, data fabric, révolution data centric… IA (forcément !).
Tous droits réservés – datassence.fr. Cet article a été publié originellement sur www.datassence.fr.
Les commentaires sont fermés.