À la lecture de ce titre, vous vous demandez certainement dans quelle campagne de gestion de données je vais encore vous embarquer ? Si, pour l’instant, votre data base ressemble à Waterloo, j’espère pouvoir vous mener vers Austerlitz ! Explications.
For my English-speaking friends, the English translation is at the bottom of the page.
Flash back
À l’occasion d’une visite au Rijksmuseum d’Amsterdam, j’ai pu admirer une des premières règles « mètre » de référence, celle d’Étienne Lenoir, mise au point après la Révolution française. Dans ce même musée, j’ai observé aussi une reproduction d’une carte représentant les pertes humaines de la tristement célèbre campagne napoléonienne de Russie (réalisée par Charles Minard). De fil en aiguille, d’association d’idée en association d’idée, la sortie prochaine du film de Ridley Scott sur l’empereur a définitivement fini de me convaincre de vous parler normalisation, à la sauce Napoléon.
Courte histoire du système métrique
Pour rappel, en 1789, quelques mois avant La Bastille, les Français sont invités à rédiger « leurs cahiers de doléances ». On y lit que le peuple réclame des mesures universelles qui permettraient de s’affranchir des unités de mesures féodales et territoriales, telles que la toise, la perche ou l’arpent, qui rendent difficiles les échanges et le commerce. En 1795, des scientifiques français parviennent donc à mettre au point, à force de calculs complexes, LE système métrique dit MKpS (mètre,kilogramme-poids,seconde) que nous connaissons aujourd’hui. Pourtant, certains contemporains auraient préféré garder leurs habitudes et sa mise en pratique prit du temps. Quand Napoléon prend le pouvoir en 1799, il est lui-même assez réservé quant à l’usage de ce nouveau système métrique, le jugeant comme un inutile « tourment du peuple ». À partir de 1812, il encourage l’utilisation des « mesures usuelles », un savant compromis entre les unités traditionnelles anciennes et le système métrique innovant. Ainsi, la toise traditionnelle gagna 50 centimètres pour équivaloir à deux mètres. Vous suivez ? En 1837 finalement, Louis Philippe, soucieux d’asseoir son pouvoir sur les acquis de la Révolution, rétablit le système métrique unique pour mener le pays sur la voie de la modernisation. En 1875, la Convention du mètre est signée par dix-sept états, soucieux d’homogénéiser les unités de mesure et leur usage.
Pourtant, au XXIe siècle encore, bien que le système métrique soit globalement admis et utilisé, d’autres unités perdurent, principalement en Amérique du Nord. C’est pourquoi, afin de faciliter la communication autour de cette question, des tables de correspondance ont été mises en place.
Pour une vision napoléonnienne de la normalisation de données
Tout comme au XVIIIe et XIXe siècles pour la généralisation du système métrique, dans le monde de la donnée, professionnels et utilisateurs sont tiraillés entre les usages et le besoin d’interopérabilité, c’est-à-dire la nécessaire capacité des systèmes et des produits à fonctionner « ensemble ». Dans nos systèmes de plus en plus interconnectés, il est indispensable de posséder les mêmes normes pour utiliser des données externes en confiance. Cependant, la complexité desdites normes et leur diversité peut largement devenir une source de perturbation, notamment dans des organisations habituées à des codes « faits maison », hérités de l’histoire et du savoir-faire de l’entreprise.
Et c’est là que je me fais empereur… car selon moi, normer à tout prix est une erreur. Des approches plus nuancées sont possibles.
- Dans les cas simples, il est envisageable d’introduire dans les données de référence des tables de correspondance qui permettent de faire le lien entre les codes propres à l’entreprise et l’environnement extérieur.
- Si des notions de hiérarchie doivent être modélisées, les taxonomies, disons les classifications, permettent de créer ces relations plus complexes.
- En cas de relation sémantique complexe, les ontologies, sous-type de taxonomie qui ressembleraient à des cartes mentales, peuvent permettre de représenter ces liens sous forme de schéma RDF.
- L’architecture Datamesh introduit une notion de sidecar qui peut permettre, pour un domaine donné, de manipuler les données indifféremment dans une norme issue du domaine et dans une norme permettant l’interopérabilité. Le sidecar est un composant logique qui permet à chaque produit data d’exécuter des tâches transversales standardisées et permet un couplage lâche, c’est-à-dire une certaine indépendance, entre produits.
D’un point de vue technique, plusieurs possibilités vous sont offertes :
- La solution ETL (Extract-Transform-Load) possède cette capacité à changer le format, la structure, la sémantique des données qu’il manipule d’une source de données vers une autre.
- L’utilisation d’API (interface de programmation d’application) peut outiller facilement car elle offre la connexion entre des logiciels ou des services en facilitant les échanges de données et de fonctionnalités par la mise en oeuvre de documentations, versions, protocoles fonctionnels, code, tests, bouchons.
En revanche, le processus de réplication, et sa technologie avancée Change Data Capture, ou l’Event Driven Architecture (EDA) sont peu adaptés à la transformation de données visant l’interopérabilité.
Quelle que soit la solution retenue, on n’oubliera pas d’intégrer l’information et de la partager via son dictionnaire de la data !
Vous souhaitez discuter de l’intérêt de normaliser votre gouvernance ? Appelez-moi Napoléon !
— English
Data Standardization in Napoleonic Sauce
As you read this title, you’re probably wondering what kind of data management campaign data management campaign I’m about to embark you on? If, for the moment, your data base resembles Waterloo, I hope to lead you towards Austerlitz! Here’s how it works.
Flash back
During a visit to Amsterdam’s Rijksmuseum, I admired one of the first reference « metre » rulers, Étienne Lenoir’s, developed after the French Revolution. In the same museum, I also saw a reproduction of a map showing the loss of life during Napoleon’s infamous Russian campaign (by Charles Minard). One thing led one idea led to another, and the upcoming release of Ridley Scott’s film about the emperor finally convinced me to talk to you about normalization, Napoleon-style. Napoleon sauce.
A short history of the metric system
As a reminder, in 1789, a few months before the Bastille, the French were invited to draw up their « cahiers de doléances ». In them, the people called for universal measures that would free them from feudal and territorial units of measurement, such as the toise, the perche or the arpent, which made trade and commerce difficult. In 1795, a group of French scientists succeeded in developing, through complex calculations, THE metric system we know today. However, some of our contemporaries would have preferred to keep to their own ways, and it took a long time to put the system into practice. time. When Napoleon came to power in 1799, he himself had reservations about using the new metric system, deeming it a useless « torment to the people ». À 1812, he encouraged the use of « mesures usuelles », a clever compromise between the old traditional units and the innovative metric system. As a result, the traditional toise gained 50 centimetres to equal two metres. Do you follow? Finally, in 1837, Louis Philippe, anxious to consolidate his power on the achievements of the Revolution, re-established the single metric system to lead the country along the path to modernization. In 1875, the Metre Convention was signed by seventeen states, anxious to homogenize units of measurement and their use.
However, even in the 21st century, although the metric system is generally accepted and used, other units are still used, mainly in North America. This is why, to facilitate communication on this issue, correspondence tables have been set up.
- A Napoleonic vision of data standardization
Just as in the 18th and 19th centuries when the metric system became widespread, in the world of data, professionals and users are torn between usage and the need for interoperability, i.e. the ability of systems and products to work « together ». In our increasingly interconnected systems, it is essential to have the same standards in order to use external data with confidence. However, the complexity and diversity However, the complexity and diversity of these standards can be a source of considerable disruption, particularly in organizations accustomed to « home-grown » codes inherited from the company’s history and know-how.
And this is where I become an emperor… because in my opinion, standardizing at all costs is a mistake. More nuanced approaches are possible.
- In simple cases, correspondence tables can be introduced into the reference data, linking the company’s own codes to the external environment.
- If notions of hierarchy need to be modeled, taxonomies, say classifications, can be used to create these more complex relationships.
- In the case of complex semantic relationships, ontologies, a sub-type of taxonomy that resembles a mind map, can be used to represent these links in the form of an RDF schema.
- The Datamesh architecture introduces the notion of a sidecar, which, for a given domain, can be used to manipulate data both in a standard derived from the domain and in a standard enabling interoperability. The sidecar is a logical component that allows each data product to perform standardized cross-domain tasks, and enables loose coupling, i.e. a degree of independence, between products.
From a technical point of view, there are several possibilities:
- The ETL (Extract-Transform-Load) solution has the ability to change the format, structure and semantics of the data it manipulates from one data source to another.
- The use of APIs (Application Programming Interfaces) can be an easy tool to implement, as they provide a connection between software or services, facilitating the exchange of data and functionalities through the implementation of documentation, versions, functional protocols, code, tests and plugs.
On the other hand, the replication process, with its advanced Change Data Capture technology, or Event Driven Architecture (EDA), are poorly suited to data transformation aimed at interoperability.
Whichever solution you choose, don’t forget to integrate the information and share it via your data dictionary!
Would you like to discuss the benefits of standardizing your governance? Call me Napoleon!