Source unique de vérité

En sciences de l'information et en technologies de l'information , l'architecture à source unique de vérité ( SSOT ), ou architecture à point unique de vérité ( SPOT ), pour les systèmes d'information est la pratique consistant à structurer des modèles d'information et des schémas de données associés de telle sorte que chaque élément de données soit maîtrisé (ou édité) en un seul endroit, fournissant une normalisation des données sous une forme canonique (par exemple, dans la normalisation de base de données ou la transclusion de contenu ).

Il existe plusieurs scénarios concernant les copies et les mises à jour :

• Les données principales ne sont jamais copiées, seules des références à celles-ci sont effectuées ; cela signifie que toutes les lectures et mises à jour vont directement au SSOT.
• Les données principales sont copiées mais les copies sont uniquement lues et seules les données principales sont mises à jour ; si les demandes de lecture de données ne sont effectuées que sur des copies, il s'agit d'une instance de CQRS .
• Les données principales sont copiées et les copies sont mises à jour ; cela nécessite un mécanisme de réconciliation lorsqu'il y a des mises à jour simultanées.
  • Les mises à jour sur les copies peuvent être rejetées chaque fois qu'une mise à jour simultanée est effectuée sur le maître, de sorte qu'elles ne sont pas considérées comme entièrement validées tant qu'elles ne sont pas propagées au maître. (de nombreuses blockchains fonctionnent de cette façon.)
  • Les mises à jour simultanées sont fusionnées. (Si une fusion automatique échoue, elle peut recourir à une autre stratégie, qui peut être la stratégie précédente ou quelque chose d'autre comme une intervention manuelle, ce que font la plupart des systèmes de contrôle de version source.)

Les avantages des architectures SSOT incluent une prévention plus facile des incohérences erronées (comme l'oubli d'une valeur ou d'une copie en double quelque part) et un contrôle des versions grandement simplifié . Sans SSOT, la gestion des incohérences implique soit des algorithmes de consensus complexes et sujets aux erreurs, soit l'utilisation d'une architecture plus simple susceptible de perdre des données en cas d'incohérence (ce dernier cas peut sembler inacceptable mais c'est parfois un très bon choix ; c'est ainsi que fonctionnent la plupart des blockchains : une transaction n'est réellement définitive que si elle a été incluse dans le bloc suivant qui est miné).

Idéalement, les systèmes SSOT fournissent des données authentiques (et authentifiables ), pertinentes et référençables .

Le déploiement d'une architecture SSOT devient de plus en plus important dans les environnements d'entreprise où des éléments de données dupliqués ou dénormalisés incorrectement liés (conséquence directe de la dénormalisation intentionnelle ou non intentionnelle de tout modèle de données explicite) présentent un risque de récupération d'informations obsolètes et donc incorrectes. Les exemples courants (c'est-à-dire les exemples de classes d'implémentation) sont les suivants :

• Dans les dossiers médicaux électroniques (DME), il est impératif de valider avec précision l'identité du patient par rapport à un référentiel unique, qui sert de SSOT. Les représentations dupliquées des données au sein de l'entreprise seraient mises en œuvre par l'utilisation de pointeurs plutôt que de tables, de lignes ou de cellules de base de données dupliquées. Cela garantit que les mises à jour de données des éléments de l'emplacement faisant autorité sont distribuées de manière exhaustive à tous les groupes de bases de données fédérés dans l' architecture globale de l'entreprise. Les DME sont un excellent exemple de la façon dont l'architecture SSOT est à la fois particulièrement nécessaire et difficile à réaliser : elle est difficile car l'échange d'informations médicales entre organisations est intrinsèquement un obstacle à la compétence en matière de cybersécurité , et elle est néanmoins nécessaire pour prévenir les erreurs médicales , pour éviter les coûts inutiles liés à l'inefficacité (comme le travail en double ou le retravail) et pour rendre les concepts de soins primaires et de foyer médical réalisables (pour réaliser des transitions de soins compétentes ).
• La publication à source unique, en tant que principe général ou idéal dans la gestion de contenu, repose sur la présence de SSOT, via la transclusion ou (au moins, dans le cas contraire) la substitution. La substitution se fait via des bibliothèques d'objets qui peuvent être propagées sous forme de copies statiques qui sont ensuite actualisées lorsque cela est nécessaire (c'est-à-dire lorsque l'actualisation du copier-coller ou de l'importation est déclenchée par un événement de mise à jour plus important). Les systèmes de gestion de contenu de composants sont une classe de systèmes de gestion de contenu qui visent à fournir des compétences à ce niveau.

Une condition préalable reconnue (de la notion selon laquelle une source unique de vérité donnée peut exister) est qu'elle dépend de la condition ontologique qu'il n'existe pas plus d'une seule vérité (sur un fait ou une idée particulière), une affirmation qui est ontologique à la fois au sens informatique et au sens général de ce mot. Dans de nombreux cas, cela ne pose aucun problème (par exemple, au sein d'espaces de noms particuliers , ou même entre eux, tant que les collisions de noms ou les conflits de noms plus larges sont traités de manière adéquate). Les contextes les plus larges (et donc les plus épineux, concernant les divergences ontologiques) nécessitent une comparaison et une réconciliation adéquates des régimes épistémiques (ou au moins une négociation ou des échanges transactionnels). Un exemple archétypique de cette classe de réconciliation est que deux bibliothèques de séminaires théologiques , de deux religions différentes (X et Y), pourraient échanger des informations avec une architecture SSOT, mais l'unification de la vérité résiderait au niveau de l'affirmation selon laquelle « la religion X affirme que Dieu est violet tandis que la religion Y affirme que Dieu est vert », plutôt qu'au niveau de « Dieu est violet » ou « Dieu est vert ».

Une mise en œuvre idéale de SSOT est rarement possible dans la plupart des entreprises. En effet, de nombreuses organisations disposent de plusieurs systèmes d'information, chacun d'entre eux ayant besoin d'accéder aux données relatives aux mêmes entités (par exemple, le client). Souvent, ces systèmes sont achetés sous forme de produits commerciaux prêts à l'emploi auprès de fournisseurs et ne peuvent pas être modifiés de manière triviale. Chacun de ces différents systèmes doit donc stocker sa propre version des données ou entités communes, et donc chaque système doit conserver sa propre copie d'un enregistrement (ce qui viole immédiatement l'approche SSOT définie ci-dessus). Par exemple, un système de planification des ressources de l'entreprise (ERP) (tel que SAP ou Oracle e-Business Suite ) peut stocker un enregistrement client ; le système de gestion de la relation client (CRM) a également besoin d'une copie de l'enregistrement client (ou d'une partie de celui-ci) et le système d'expédition de l'entrepôt peut également avoir besoin d'une copie de certaines ou de toutes les données client (par exemple, l'adresse de livraison). Dans les cas où les fournisseurs ne prennent pas en charge ces modifications, il n'est pas toujours possible de remplacer ces enregistrements par des pointeurs vers SSOT.

Pour les organisations (avec plus d'un système d'information) souhaitant mettre en œuvre une source unique de vérité (sans modifier tous les systèmes sauf un maître pour stocker des pointeurs vers d'autres systèmes pour toutes les entités), certaines architectures de support sont :

• Gestion des données de base (MDM)
• Boutique d'événements et sourcing d'événements (ES)

Un système MDM peut servir de source de vérité pour toute entité donnée qui ne dispose pas nécessairement d'une « source de vérité » alternative dans un autre système. En général, le MDM sert de hub pour plusieurs systèmes, dont beaucoup peuvent permettre (être la source de vérité pour) les mises à jour de différents aspects des informations sur une entité donnée. Par exemple, le système CRM peut être la « source de vérité » pour la plupart des aspects du client et est mis à jour par un opérateur de centre d'appels. Cependant, un client peut (par exemple) également mettre à jour son adresse via un site Web de service client, avec une base de données dorsale différente de celle du système CRM. L'application MDM reçoit des mises à jour de plusieurs sources, agit comme un courtier pour déterminer quelles mises à jour doivent être considérées comme faisant autorité (le golden record) et syndique ensuite ces données mises à jour à tous les systèmes abonnés. L'application MDM nécessite normalement un ESB pour syndiquer ses données à plusieurs systèmes abonnés.

Dans les architectures orientées événements, il est devenu de plus en plus courant de trouver une implémentation du modèle Event Sourcing qui stocke l'état du système sous la forme d'une séquence ordonnée de changements d'état. Pour ce faire, vous avez besoin d'un Event Store , un type particulier de base de données conçu pour contenir tous les événements qui modifient l'état du système. Le magasin d'événements dans une architecture Event Sourcing + Command Query Responsibility Separation + Domain Driven Design + Messaging est en fait une « source unique de vérité », avec l'avantage supplémentaire qu'il peut également agir comme un bus de services d'entreprise car il peut écouter directement le magasin d'événements pour les changements d'état au fur et à mesure que tout passe. De plus, en sauvegardant tous les événements, il joue également le rôle d' entrepôt de données . Un dernier avantage est que grâce à ce système, le modèle de base de données partagée peut être implémenté, une autre technique non mentionnée pour obtenir une source unique de vérité.

Bien que l'objectif principal d'un entrepôt de données soit de prendre en charge la création de rapports et l'analyse de données combinées à partir de sources multiples, le fait que ces données aient été combinées (selon la logique métier intégrée dans les processus de transformation et d'intégration des données ) signifie que l'entrepôt de données est souvent utilisé comme un SSOT de facto . En général, cependant, les données disponibles à partir de l'entrepôt de données ne sont pas utilisées pour mettre à jour d'autres systèmes ; l'entrepôt de données devient plutôt la « source unique de vérité » pour la création de rapports à destination de plusieurs parties prenantes. Dans ce contexte, l'entrepôt de données est plus correctement qualifié de « version unique de la vérité » puisque d'autres versions de la vérité existent dans ses sources de données opérationnelles (aucune donnée ne provient de l'entrepôt de données ; il s'agit simplement d'un mécanisme de création de rapports pour les données chargées à partir de systèmes opérationnels).