Réinventer la dataviz : La migration intelligente de la couche sémantique, pour un modèle "Self BI"

 

Réinventer la dataviz :   La migration intelligente de la couche sémantique, pour un modèle "Self BI"  L'idée géniale des créateurs du concept de "couche sémantique" a été de permettre un accès aux données (presque) à tous .   L'un des effets positifs de cette approche a été aussi la standardisation des règles métier : une seule version des indicateurs garantissait que tout le monde utilisait les mêmes définitions, sans avoir à comprendre l'architecture IT.   Cependant, la transition vers le Cloud a bouleversé cet équilibre, avec un taux de "move to Cloud" du stack analytique très important.  Bien souvent, cette migration est l'occasion de moderniser la totalité du stack, y compris par une changement d'outil de dataviz. En effet, certaines solutions, comme Cognos ou SAP BO, sont aujourd'hui perçues comme rigides et coûteuses en maintenance. D'autres, comme Tableau ou Qlik Sense, exigent des modèles sous-jacents très structurés et restent onéreuses.   Dans une logique "Self BI", on considérera que la couche sémantique source est un socle de grande valeur qui doit être reconduit dans la cible.  Ce, de façon à ce que les équipes puissent construire rapidement et qualitativement les réponses analytiques de demain, sans traîner la lourdeur du passé.    Mais on se rend vite compte que chaque outil "legacy" possède sa propre logique (Univers BO, Framework Manager Cognos, Data Model Qlik...), souvent assez complexe, difficile à reproduire et à faire évoluer.    Sauf à changer d’approche technique. On vous explique ça.  Option 1 : Une migration "as is" : Reproduire les rapports (template, intelligence)  La promesse d’une migration "clef en main" est séduisante. Malheureusement, une migration "as is", lorsque la plateforme source est très ancienne, implique d'embarquer toute l'inertie passée : des règles de gestion aussi nombreuses qu'abstraites ou mal documentées, des dashboards inutiles ou répliqués, etc.   Cette approche, qui a l'avantage de limiter théoriquement la conduite du changement ultérieure, reste coûteuse en raison de la charge de travail qu'elle représente. Et l’adhésion n’est pas toujours au rendez-vous. Et puis à quoi bon se "remarier" de façon quasi définitive avec un autre éditeur en ces temps d'incertitude ?  Option 2 : Une migration "Self BI" :  Reconstruire une couche sémantique avec un modèle en étoile Cette stratégie "de rupture" consiste à sortir de la plateforme source sans recréer une plateforme cible de manière immédiate, mais plutôt progressivement et en adéquation avec les priorités du moment, en mode Self BI. Il s'agira aussi de créer les conditions de l’interopérabilité.  Comment migrer la couche sémantique ?  Il faudra segmenter la couche sémantique de la solution source en fonction des contextes et des tables de faits réellement exploitées. Cette approche repose sur l'usage réel de la plateforme d'origine : on constate souvent qu’il n’y en a qu’une fraction qui est réellement utilisée par rapport à l’ensemble. Il faudra transformer chaque ensemble d’informations sémantiques en données sémantiques granulaires selon un modèle en étoile centré sur la table de faits : on va segmenter la complexité de la couche sémantique source en éléments simples. "À nous la liberté !"  Cette approche permet de construire une couche sémantique centralisée et optimisée au sein de l'outil cible, avec un fonctionnement indépendant de l'outil de dataviz propriétaire cible.  ....Cette couche sémantique est donc beaucoup plus simple à transposer vers une autre solution de dataviz.  Migrer quelques rapports "as is" quand même ? Dans ce contexte, il nous paraît cependant stratégique de migrer certains rapports "as is" : Pour conserver l’intelligence et les templates existants pour certains rapports stratégiques. Pour créer un petit référentiel technique pour les équipes chargées du déploiement. Pour créer un environnement de formation. CONCLUSION   Migrer une couche sémantique vers une architecture moderne est un défi stratégique. Une migration "as is" permet de limiter les perturbations mais peut s’avérer complexe.   En revanche, une migration ciblée de la couche sémantique (ce qui sert), basée sur une segmentation pertinente et un modèle en étoile, offre une architecture plus agile et évolutive. Cette approche assurera une compatibilité simplifiée avec différents outils modernes de dataviz. Il sera utile de conserver certains rapports stratégiques en l'état pour faciliter la transition. Notre logiciel {openAudit} permet de mettre en œuvre cette stratégie. Et au forfait !