Architecture des données

Le thème

L’architecture des données, dans la plupart des systèmes existants, présente de nombreux défauts :

  • un taux de redondance qui avoisine les 50% ;
  • la domination du style relationnel, peu accueillant à l’égard des formes “non structurées” que peut prendre l’information (documents, courriels…) ;
  • une centralisation qui peut nuire aux performances ;
  • des risques par rapport à la sécurité et à la protection des données ;
  • un couplage fort avec le logiciel (une partie des données étant enfermée dans des applications qui les communiquent difficilement ; une autre, au contraire, s’ouvrant à de nombreux composants logiciels, ce qui rend son évolution délicate).

Il importe de prendre conscience de ces défauts ainsi que des risques et impasses qu’ils entraînent pour l’avenir des systèmes. Il nous revient aussi d’analyser les causes historiques, culturelles, techniques qui ont conduit à cette situation. Un des facteurs entrant en jeu est l’approche fonctionnelle qui a présidé à la construction des systèmes informatiques. Découper le patrimoine de données en appliquant le critère de la fonction (domaines fonctionnels) est le meilleur moyen de produire de la redondance. On ne s’aperçoit pas que des notions comme client (application de CRM), employé (GRH), fournisseurs, etc. renvoient aux mêmes objets. De cet aveuglement résulte une redondance structurelle : les schémas de données, internes aux domaines fonctionnels, reproduisent des notions génériques que l’on aurait dû partager. Ceci entraîne une redondance fonctionnelle : des traitements comme le changement d’adresse, la définition des préférences de contact, la mise en relation… sont à refaire autour de chacune des notions spécialisées, avec les règles à respecter. Enfin, la redondance structurelle implique une redondance substantielle : une même personne peut assumer, à la fois, le rôle d’employé et le rôle de client, par exemple. Il faut donc inscrire ses informations aux deux endroits, ce qui garantit de créer des contradictions à un moment ou à un autre. Les préoccupations actuelles à propos des préférences de contact témoignent de ces difficultés.

Il est donc temps de reprendre, de fond en comble, l’architecture des données. Il ne s’agit pas d’un champ tout à fait autonome. En effet, l’architecture des données doit être déterminée par le style d’architecture adopté pour le système informatique. Aujourd’hui, il est évident que SOA, en tant que style d’architecture logique, offre une bien meilleure approche que le style fonctionnel. Une SOA bien menée élimine la redondance, et permet de maîtriser le couplage à l’intérieur du système. Cette approche favorise également l’interopérabilité : il s’agit, dès le départ, d’une approche multi-système.

Le discours actuel sur les “micro-services” réactualise les principes fondateurs de SOA, que l’on a un peu perdu de vue au fur et à mesure que l’étiquette se popularisait. Il encourage la révision des architectures de données, et retrouve un précepte formulé par la méthode Praxeme pour SOA, depuis le début des années 2000 :

Autant que faire se peut, la meilleure architecture des données taille les supports de persistance à l’échelle des ateliers logique.

 

On voit par là en quoi l’architecture des données dépend de l’architecture logique. Particulièrement dans une SOA, le plan des services surplombe et masque le plan des données.

Nos prestations

 

 

Nos expériences

 

 

Nos atouts

 

<<

Les commentaires sont fermés