| | | | Migrations massives, et automatisées d'outils de dataviz |
|
|---|
|
|
|
|
| | Migrer une plateforme de dataviz, un projet à haut risque ! |
|
|---|
| | |
|
|
| | Comment décommissionner une technologie de dataviz dépassée car trop statique, chère, incompatible avec l'architecture cible, en particulier dans le Cloud ? Comment aller sereinement vers les outils de demain, plébiscités aussi par les métiers, souvent dans le Cloud ?
{openAudit} permet des migrations quasi automatisées entre différentes technologies de dataviz, pour gagner un temps infini et pour éviter des régressions dommageables, en particulier au niveau des règles de gestion.
|
|
|---|
| | |
|
|
|
| | De fortes similitudes entres plateformes | | | La plupart outils de dataviz ont pour la plupart deux points communs : - Une couche sémantique qui fait l’interface entre l'IT et le métier,
- Un éditeur de dashboard.
|
|
|---|
|
|
|
| | Ces similitudes théoriques nous ont permis d’établir une cinématique d’ensemble permettant d’aller vite à la cible. |
|
|---|
| | |
|
|
|
| | 3 étapes majeures se détachent : | |
|
|---|
|
|
|
| | 1 - Récolter dynamiquement les métadonnées de la plateforme source avec des sondes et parsers. |
|
|---|
| | |
|
|
| | - {openAudit} va directement parser les fichiers pour récupérer l'intelligence, la structure des dashboards et la couche sémantiques s’il y en a une ;
- {openAudit} va accéder également au référentiel de la solution source pour garder la cohérence des ID entre les différents « objets » (couche sémantique, queries, dashboards, instances, autres) ;
- Une sonde d’{openAudit} va récupérer certains logs des différents outils de dataviz, pour identifier les usages, leur fréquence, leur population.
|
|
|---|
| | |
|
|
| | Exemple d'output : data lineage dans la couche dataviz : (1') | |
|
|---|
|
|
|
|
|
| | 2 - Harmoniser la plateforme source |
|
|---|
| | |
|
|
| | {openAudit} permettra de connaître un certain nombre d'éléments sur la plateforme en place : - Combien il y a de requêtes ?
- Quelles sont les requêtes le plus utilisées ?
- Quelles sont les données réellement utiles ?
- Quels sont les dashboards volumineux, complexes ?
- Combien sont répliqués ?
- Combien y a-t-il de folders, avec combien de documents associés ?
- Combiens d’instances ?
- Quels sont les dashboards les plus lourds qui ralentissent la plateforme,
- Combien il y a de sources de données, sont-elles toutes exploitées ?
- …etc.
Cet inventaire permettra de "cleaner" la plateforme source préalablement, de l’optimiser pour ne pas propager inutilement l’hypertrophie du système source vers le système cible.
Cela permettra de prioriser aussi, pour essentialiser la plateforme cible. |
|
|---|
| | |
|
|
| | Exemple d'output : cleaning d'une platforme dataviz (1') | |
|
|---|
|
|
|
|
|
|
| | 3 - Migrer : passer par un modèle pivot |
|
|---|
| | |
|
|
|
| | 1. {openAudit} va créer une couche d’abstraction supplémentaire (couche sémantique, template du dashboard...), agnostique, qui servira de pivot, et qui pourra mutualiser plusieurs technologies.
2. Au départ de cette couche pivot, {openAudit} reconstruira dynamiquement les templates, les queries, la couche sémantique, etc., dans la technologie cible.
|
|
|---|
| | |
|
|
|
| | Conclusion 90 % de la migration peut être réalisée de façon automatisée, pour permettre aux équipes d’ingénieurs de ne s’attacher qu’à ce qui finalement est important : l’intelligence renfermée dans les dahboards, i.e. les règles de gestion. Ce processus a été implémenté chez un de nos clients grand compte. N'hésitez pas à nous solliciter pour un partage d'expérience. |
|
|---|
| | |
|
|
|
|
|
Commentaires
Enregistrer un commentaire