Règles d’Urbanisation des données

Les Architectures Data Centric sont souvent présentées comme associées aux nouvelles plateformes « Big Data ». En réalité, il s’agit d’un changement plus fondamental, qui embarque tout type d’Architecture Technique, du monde SQL, ou du No SQL, ou autre à venir.

L’Architecture Flexible est l’archétype d’une Architecture Data Centric, agnostique par rapport aux offres technologiques du marché.

Ce type d’Architecture implique un positionnement rénové, en rupture des pratiques référencées par les méthodologies, des Urbanistes et de leurs prescriptions :

  • Par rapport aux données de référence, qu’elles soient les données maîtres ou les « puits d’événements »
  • Par rapport aux projets, qui doivent être « mis sous contrôle » rigoureux pour la modélisation des événements (tridatation) et les interactions (APisation)
  • Par rapport aux progiciels, qui doivent respecter des normes strictes pour l’accès aux données maîtres et les interfonctionnements

 

Les nouvelles Règles d’Urbanisme « Data Centric » sont des règles d’Urbanisation des Données permettant la construction, au fil des projets, d’un SI plus fluide, événementiel et flexible.

Règle 1 : Echanges d’intérêt collectif – Piloter la réurbanisation par les échanges

Les échanges et interactions entre les différentes composantes du SI sont un levier majeur pour l’urbanisation, pour desimbriquer, rendre les composants autonomes, limiter la dépendance aux éditeurs, sécuriser, optimiser les plateformes, accélérer les processus, …

Parmi tous les échanges, interactions, invocations, appels de services, … l’Urbanisation distingue ceux qui sont d’intérêt collectif, des autres, plus privatifs.

Les échanges d’intérêt collectif sont obligatoirement sous contrôle de l’Urbanisme SI, qui en gère le catalogue, et valide leur usage (normes fonctionnelles, format pivot, implémentation technique, temporalité, …) et les implémentations. L’Architecture Technique et la Sécurité SI sont associés à ce contrôle.

L’Urbanisme SI peut dérouter, redéfinir, leurrer, tracer dans un Puits d’événements, de tels échanges.

Les évolutions de ces échanges, à l’occasion des projets, ou de changement de progiciel, suivent les prescriptions de l’Urbanisme SI, selon les temporalités et exigences fonctionnelles : mode d’échange recommandé, principe d’identification des messages (identification du flux, de l’événement, de l’objet).

Les échanges d’intérêt collectif peuvent être confiés à un centre de services, qui en assure la production, et applique des contrats entre les différentes parties prenantes.

L’Urbanisme SI est responsable des modèles de contrat entre les différentes parties prenantes internes ou externes à l’Entreprise.

Règle 2 : Respect par les progiciels des modèles d‘échanges et asservissement aux référentiels

Les principales interactions avec un progiciel ou composant externe sont classées en échanges d’intérêt collectif par l’Urbanisme SI. L’enjeu est de pouvoir substituer à un progiciel ou composant externe, un autre composant, sans avoir à modifier le reste du SI. Les montées de version d’un progiciel sont soumises à ces règles.

Par ailleurs, les éditeurs de progiciel et autres composants ont besoin d’embarquer dans leur système une gestion des données maîtres. Cependant il est préférable, pour accroître la flexibilité du SI, réduire le risque de dépendance, faciliter les transversalités, de placer cette gestion en dehors du composant contrôlé par l’éditeur. Concernant les Données maîtres désignées par l’Urbanisme SI, cela fait partie des exigences imposées à l’éditeur, qui doit prévoir les capacités d’interfonctionnement avec un système externe maître.

Règle 3 : Gouvernance centrale des statuts des référentiels et puits d’événements

Les statuts de référentiel et puits d’événements sont attribués par l’Urbanisme SI.

Les référentiels et puits sont invoqués par des échanges d’intérêt collectif.

Les règles d’Urbanisme peuvent être déclinées par niveau d’intérêt collectif, selon une organisation par domaine de maîtrise d’ouvrage.

Règle 4 : Obligation de recours aux référentiels et puits d‘événements

L’accès à une donnée maître, qui peut être fournie par un référentiel, doit se faire obligatoirement auprès de cette ressource, selon des modalités définies par l’Urbanisme SI.

L’accès à une donnée événementielle qui peut être fournie par un puits ou par le truchement d’un puits, doit se faire obligatoirement auprès de cette ressource.

Règle 5 : Identification et datation rigoureuses

L’Architecture Data Centric doit être fondée sur une identification et une datation rigoureuses :

  • Historisation des référentiels
  • Datation des événements (date de fait, date de vision, date de mise en qualité)
  • Identification des échanges d’intérêt général (catalogue des flux et interactions)

L’Urbanisme SI publie les règles d’identification et de datation, et peut imposer des pénalités à un projet qui ne respecte pas ces règles, par exemple en limitant ses possibilités d’interfonctionnement avec le reste du SI.