Les visions 360

Objectifs

Dans les entreprises et organisations, les SI se sont construits en silos, et les visions transverses aux silos ne sont pas natives.

Pour restituer une vision transversale, reprenant les données disponibles sur une entité du monde réel, il faut créer une « vision 360« .

Il s’agit de regrouper par exemple les données sur le client, dispersées au sein du patrimoine SI. Ces données, en effet, sont « enfouies » dans les différents domaines du SI (commercial, services opérationnels, comptabilité, juridique, décisionnel, …). Certaines sont issues de retraitements, d’analyses et profilages produits par la Business Intelligence et les algorithmes d’Intelligence Artificielle ou de « machin learning ».

Bien sûr, une vision 360 s’appuie sur l’identification de l’ « objet » concerné : le client, le partenaire, … Il est préférable de mettre ce référentiel en qualité, et de faire en sorte qu’il soit bien à jour. Mais la vision est associée à un cycle de vie autonome, et doit donc être située « ailleurs ».

Pour des raisons de modularité, de performance, ou, plus fondamentalement de gouvernance de données, on crée plusieurs domaines de vision 360 chargés de restituer les regroupements de données sur chaque objet des transformations opérées par l’Entreprise.

La question posée, dans le cadre d’une volonté d’Architecture Flexible, est de ne pas créer un cadre rigide, et d’éviter de complexifier le système global.

Principes de construction

Dans cet esprit il faut appliquer des principes de construction simples :

  • La ou les visions 360 devront, en priorité, accéder aux données dynamiquement, au cas par cas, auprès des systèmes qui en sont la source : données de meilleure qualité de fiabilité et de fraîcheur. De ce fait la vision 360 ne gère ni ne stocke ces données, sauf optimisation technique (cache,…).
  • Pour accéder aux données on utilise de préférence l’indirection par les Puits, qui sont à jour des événements concernant l’objet mis en vision (à noter que le « passage par le Puits » ne signifie pas forcément que l’échange transite par le Puits, mais qu’il soit orchestré par le Puits).
    • Selon le cas la publication de certaines données sera attribuée au puits, le SI source lui ayant délégué cette fonction.
    • Ou la publication demeurera de la responsabilité du SI source.
  • Au cas où l’accès ne peut se faire via le puits, il se fait auprès des systèmes source : données de meilleure qualité de fiabilité et de fraîcheur.
  • Suite à la création d’un nouveau puits, il convient de « débrancher » les visions 360 des SI fédérés par le puits, pour que l’interaction se fasse via le puits. Les évolutions d’architecture des SI spécifiques et subsidiaires sont ainsi masquées par le puits.
  • Quand l’accès dynamique n’est pas possible, si par exemple la donnée est fournie par messages au travers d’un « hub », ou par un batch, il faut que la migration vers un accès dynamique soit anticipée et puisse se faire sans difficulté.
  • Certaines données élaborées par la Business Intelligence, ou par moteur de recherche, sont soit disponibles auprès de bases spécialisées (base d’indexation, Data Mart, …), soit obtenues par abonnement via le Hub.
  • On évitera de créer un niveau de stockage, permanent et historisé, de données dédiés aux visions 360, les données disponibles étant toujours des données « de seconde main » destinées à être remplacées dès qu’obsolètes.
  • La cinématique de mise à jour des données de vision 360 doit être flexible et adaptable à différents scénarios, et le changement de scénario doit être facile :
    • données « poussée » par le système source dès que disponible,
    • accès à la donnée source à la demande,
    • abonnement à un flot de diffusion,
    • abonnement à des alertes prévenant de la disponibilité d’une nouvelle donnée,
    • abonnement à alerte prévenat de l’ouverture d’une nouvelle API,…
  • Les visions 360 désimbriquent les sources et consommations en gérant la noria de flux et d’API et les éventuels formats pivots, en particulier par une gestion des meta-données.
  • Pour ces fonctions de vision 360, on fera aussi appel de préférence à des routines génériques pilotées par les meta-données, pour réduire les frais de développement, et disposer de composants de vision 360 adaptables facilement à n’importe quel domaine,
  • Les visions 360 sont vecteurs de l’APIsation, et doivent montrer l’exemple en publiant des accès par API et en se sourçant par API.
  • Les visions 360, alias API 360, s’appuient sur l’API Management,
  • Les visions 360, pour leurs fonctions d’alimentation et de diffusion asynchrone, peuvent s’appuyer sur les routines d’intégration de données.

A noter que les visions 360 peuvent exploiter le mécanisme fonctionnel de tri-datation, en distinguant nettement les visions à date anticipée, ou différée (prévisions, post-visions), sans pour autant nécessiter la multiplication de puits, la gestion de ces dates étant native dans les puits. La vision pourra aussi filtrer selon le niveau de qualité, en se calant sur la codification de la qualité organisée autour du puits (Puits et DQM).

Les visions 360 contribuent ainsi à la composition du « Lego » d’architecture, elles constituent une « figure de style » typique de l’Architecture Flexible.

Ci-dessous un exemple de positionnement des visions 360 :

 

 

Les visions 360 sont ainsi clairement placées en cohérence une politique globale de gestion du cycle de vie de la donnée, non seulement par rapport à la mise en qualité tracée par les puits, mais aussi en relation avec les entrepôts et résultats du décisionnel (voir la synergie entre les puits et les ODS, voir aussi puits et Data Lake).

Cette architecture globale doit bien sûr s’appuyer sur une architecture technique garantissant performance et sécurité.