Cartographier un système d'information

1) oA-Data-lineage-system : data lineage dans les bases de données

Au départ de n’importe quelle « data point » (un champ d’une table, une table, un fichier, un schéma), {openAudit} permet d'appréhender son origine et ses usages, on-premise et dans le Cloud, à travers un data lineage technique, multi technologique. Les analyses sous-jacentes sont rejouées quotidiennement de façon automatisée.

Les informations relatives à l’ordonnancement des chaînes est disponible, et les usages de chaque « data point » est défini au survol : qui consulte quelle information, quand, via quels outils, ce qui est d’un intérêt majeur dans un cadre « compliance ».

{openAudit} propose différents modes de représentation graphique pour son data lineage (métier / IT)

Use cases :
Partager une compréhension détaillée de la construction des flux, identifier les ruptures et les corriger, la Data Loss Prevention (DLP), BCBS 239 (Bâle III), RGPD, etc.

Le data lineage dans les bases de données

Un véritable data lineage dans les alimentations, exhaustif et totalement automatisé, qui présente de multiples vues en fonction des besoins.

Résoudre les ruptures dans le data lineage

> Vues : si elles sont stockées, {openAudit} les lira, même si elles sont empilées (vues de vues de vues...).

> Dynamic SQL : si {openAudit} ne parvient pas à le résoudre directement, le dynamic SQL est résolu avec des paramètres d'exécution, ou avec les journaux d'exécution.

> Autres : en cas de transfert d'informations par FTP, ou lorsque le schéma de base de données n'est pas précisé (c'est le cas dans de nombreux ETL), {openAudit} résout ces ruptures par reconnaissance structurelle, ou {openAudit} lit le Batch / le Shell.

Associer dynamiquement différentes technologies de transformation de données

> {openAudit} analyse toutes les technologies de processing (langage objet/procédural, ELT/ETL), on-premise ou Cloud, et les associe dans un seul data flow, au niveau le plus fin. Le drill through permet d'accéder au code.

> Le process est dynamique, opéré en mode delta, quotidiennement, et donc synchronisé au système d'information.

Différents niveaux d'analyse pour les alimentations

> Nuage de points : cette vue permet de connaître instantanément les usages d’un datapoint en faisant abstraction des transformations. Il est également possible à partir d’un usage (un dashboard, une donnée d’un dashboard, une requête), d’identifier instantanément ses sources opérationnelles.

> Cartographie : cette vue permet à partir de n'importe quel datapoint (champ, table) d’afficher une cartographie complète du flux amont ou aval, c'est à dire depuis les sources opérationnelles jusqu'à l'exposition des données (dataviz, requête). Les informations utilisées sont mises en lumière, et les usages de l’information sont précisés au survol (qui consulte la donnée, quand, comment).

> Data lineage granulaire : cette vue permet de suivre de façon progressive le déploiement d’une donnée dans le système d’information à partir d’un datapoint par des clics itératifs, ou a contrario de remonter jusqu'aux sources opérationnelles. Chaque transformation (job ELT/ETL, code procédural/objet) peut être analysée avec le « drill through ». Le détail précis des usages des données (qui la consulte, quand, comment…) est précisé.

Cartographier un système d'information

2) oA-Data-lineage-viz : data lineage dans la couche de reporting

{openAudit} permet d'appréhender l'ensemble des technologies de data visualisation de l'entreprise sur une interface unique d'analyse d'impact : il s'agit d'une grille qui permet de comprendre l'étagement entre les chacun des éléments constitutifs du dashboard et le champ physique en source (ou la vue) : de la cellule du dashboard, à la query qui interroge la base de donnée, en passant par la couche sémantique s'il y en une, etc.
Le data lineage dans le dashboard ou dans les couches alimentation peut être déclenché depuis cette interface.

Ainsi, l’ensemble des règles de gestion internes aux technologies de data visualisation sont mises en lumière et partagées à tous. Ce data lineage dans la couche de data visualisation peut être rattaché à celui des alimentations.

Use cases : Faire la lumière sur des règles de gestion complexes, faire de l’analyse d’impact entre un champ physique et une donnée du dashboard…etc.

Data lineage dans la couche de reporting

Certaines technologies de data visualisation utilisent des couches sémantiques pour créer de l'intelligibilité pour le métier, et ainsi lui donner de l'autonomie. Ces couches sémantiques créent de l'abstraction : les champs physiques sous-jacents sont difficiles à identifier, ce qui rend le sourcing complexe.

De plus, les technologies de data visualisation interrogent souvent des vues, des vues de vues… ce qui complique encore une fois le sourcing.

Les technologies de data visualisation se multipliant, de véritables analyses d'impact (ou sourcing) multi-technologiques sont complexes à opérer.

Par ailleurs, les technologies de data visualisation permettent maintenant de faire de la data préparation dans des proportions importantes, ce qui créé une forte opacité.

Des réponses techniques

> {openAudit} opère un data lineage dans la couche de data visualisation, dans les expressions, dans les variables, etc., pour identifier les champs directement ou indirectement en source d'un data point.

> {openAudit} analyse le contenu des vues pour identifier les champs physiques qui sont en source des données d'une couche de data visualisation, même si les vues sont empilées.

> {openAudit} combine les analyses des différentes technologies de dataviz dans une même grille, ce qui permettra aux métiers et à l'IT de réaliser des analyses d'impact entre toutes les couches d'alimentation et tous les outils de data visualisation. Simplement.

Optimiser un système

1) oA-Optimization-system : détecter les branches mortes dans les alimentations

Grâce à une analyse des usages de l'information, associée au parcours de l'information (data lineage), {openAudit} identifie les flux inutiles et les « data points » qui y sont associés (tables / fichiers).

En moyenne, 50 % de ce qui est stocké dans le système d'information n'a pas de valeur ajoutée. Ce sont d'innombrables « branches mortes » composées de code, de tables, de vues, de fichiers, qui sont maintenus à tort dans les systèmes avec un impacts considérables : inertie des systèmes legacy, coûts de maintenance. Et pour les systèmes Cloud, des factures insoutenables, et de forts impacts environnementaux.

Use cases :
Décommissionnement des branches mortes avant migration, rationalisation d'un système pour baisser la maintenance, FinOps, GreenOps pour une IT plus vertueuse.

Détecter les branches mortes dans les alimentations

Une large partie du contenu des systèmes d'information n'a pas de valeur ajoutée (répliqué, obsolète), avec des impacts importants : maintenance, licences, migrations techniques rendues impossibles, coûts, etc.

Des réponses techniques

> {openAudit} analyse les journaux des bases de données d'audit et la couche de data visualisation pour découvrir quelles données sont réellement utilisées.

> A partir des champs utilisés dans les bases de données pour alimenter les outils de data visualisation, ou les requêtes adhoc (ODBC, JDBC), ou encore à partir de flux ETL/ELT spécifiques, {openAudit} identifie les flux d'information, les tables qui sont en source, i.e les "branches vivantes" du système d'information. Par opposition, {openAudit} identifie les "branches mortes", i.e les tables, procédures, jobs ETL/ELT qui construisent de l'information sans qu’elles ne soient jamais exploitée.

> {openAudit} met en œuvre ces analyses de manière dynamique, et permet ainsi, en créant une profondeur d'historique conséquente, d'identifier formellement les branches qui sont continuellement inutilisées, avec tout ce qu'elles concentrent : tables, fichiers, procédures, jobs ELT/ETL. Des décommissionnements de masse peuvent avoir lieu dans des temps records.

> Dans le Cloud, via une analyse de certains logs, {openAudit} identifie ce que coûte la conservation des branches mortes dans le système. La ressource machine économisable est également mise en lumière. L’entreprise peut rentrer dans une logique FinOps et GreenOps.

Optimiser un système

2) oA-Optimization-viz : détecter les dashboards inutiles, répliqués

La couche de data visualisation renferme également inutilement de la complexité. Les équipes utilisatrices ont naturellement tendance à faire du copié coller en apportant des nuances mineures.

{openAudit} va analyser les sources, les queries, les expressions, les variables, les données finalement affichées, pour permettre des optimisations. Les dashboards obsolètes, cassé, répliqués sont détectés et peuvent être archivés ou écartés.

Nous avons développé des fonctionnalités pour SAP BO qui permettent d’opérer certaines actions en masse de façon automatisée pour retrouver quasi instantanément une plateforme essentialisée.

Use cases :
Rationalisation massive de la couche de data visualisation pour baisser les coûts, faire reculer le risque d’erreurs, en améliorer l’intelligibilité.

Détection des dashboards inutiles, répliqués

La couche de data visualisation est bien souvent d’une complexité insondable, car on empile les technologies, mais aussi on modifie les règles de gestion, on réplique, on surcharge des formules, etc. A la toute fin, c’est la qualité même des indicateurs qui en souffre, l’objectivité même d’un dashboard !

Des réponses techniques

> {openAudit} va directement parser les fichiers de la solution de data visualisation pour récupérer l'intelligence, la structure des dashboard et la couche sémantique s’il y en a une ;

> {openAudit} va accéder également au référentiel pour garder la cohérence des IDs entre les différents objets du dashboard (couche sémantique, query, dashboard, autres) ;

> Une sonde d’ {openAudit} va récupérer certains logs des bases d’audit qui sont associées aux solutions de data visualisation.

A partir de là, {openAudit} va permettre :

> De comparer les dashboards les uns avec les autres et détecter la réplication sur différents critères ;

> De détecter l’obsolescence des dashboards ;

> D’identifier les formules cassées ;

> De détecter les requêtes inutiles, etc.

(Ce en plus des grilles d’analyse d’impact, et du data lineage)

Migrer vers le Cloud

1) oA-Migration-system : migrer le code procédural

Les migrations technologiques des langages procéduraux sont souvent si délicates que les entreprises préfèrent empiler les technologies plutôt que de les décommissionner.
Cependant, elles peinent à maintenir ces langages faute d'experts capables de faire du reverse engineering.
De nos jours, l'engouement pour le Cloud est en train de changer ce paradigme, et de plus en plus d'entreprises cherchent à se départir de ces langages hérités dans des délais rapides, sans autres solutions que d'entamer des migrations hasardeuses et coûteuses.

Use cases :
Changement de SGBD, migration Cloud, maintenabilité d'un système legacy, etc.

Traduire les langages procéduraux/objets

Les grandes entreprises accumulent les technologies de processing depuis toujours. On assite à un empillement continu, car la suppression d'une technologie présente souvent trop de risques. Mais les compétences qui y sont associées se raréfient, et la retro-documentation est rarement en place.
A un moment, les entreprises doivent se lancer ! Ce peut être des projets en consultance, longs, onéreux, et hasardeux. Nous pensons qu'il est préférable d'automatiser le process.

Des réponses techniques

> {openAudit} va « parser » le code en source, il va décomposer toute la complexité du code grâce à une grammaire permettant des analyses exhaustives et ultra granulaires. Toutes les subtilités vont être prises en considération,

> {openAudit} en déduit la cinématique d’ensemble et l’intelligence, qui sera reconstruite dans un arbre algorithmique, agnostique. Sur cette base, {openAudit} va produire du « SQL standard »,

> Puis l’intelligence va être reconstruite a minima dans le SQL spécifique de la base de données cible (e.g. BigQuery pour Google, Redshift pour Amazon, Azure SQL pour Microsoft, etc.),

> Tous les traitements complexes non reproductibles en SQL simple, seront pilotés par un exécutable NodeJS ou autre. Typiquement les curseurs « Boucle For », les variables, le code conditionnel « If Else », les « Switchs », les appels à procédure, etc.,

> {openAudit} produit des fichiers "Yaml" (fichiers intuitifs). Ainsi, la compréhension de la complexité est partagée avec le plus grand nombre,

> Eventuellement, de nouveaux mécanismes d'orchestration peuvent être mis en place, pour déconstruire les curseurs de curseurs (les boucles de boucles) pour optimiser les chaînes de transformation.

Migrer vers le Cloud

2) oA-Migration-viz : migrer des dashboards vers le Cloud

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 ?

{openAudit} permet des migrations quasi automatisées entre différentes technologies de dataviz, pour gagner un temps infini et éviter des régressions dommageables.

Use cases :
Migrer SAP BO vers Looker ou PowerBI, migrer Qlik Sense vers Power BI, etc., de nombreux cas de figure sont possibles !

Migrer les technos de data visualisation

La plupart des outils de dataviz ont deux points communs : une couche sémantique qui fait l’interface entre l’IT et le métier, et un éditeur de dashboard.
Nous nous appuyons sur le reverse engineering automatisé de {openAudit} pour déconstruire la complexité en source, ce qui nous premet de la ré-adresser dans la technologie cible.

Méthodologie

> {openAudit} pourra alimenter la technologie cible à partir de la couche sémantique unique, une sorte de modèle pivot. Ce modèle aura été généré automatiquement au départ des outils de data visualisation à décommissionner,

> La structure du dashboard initial aura été également analysée par {openAudit}, et elle pourra également être retranscrite dans la technologie cible,

Ainsi des projets de migration tentaculaires, difficiles, ou impossibles à mettre en oeuvre peuvent l'être dans un temps record !

{openAudit}

Laurent Ostiz

Dominique Lhermitte

Christophe Jacri

Partenaire data catalogue :

3 cas d'usages, 6 features, pour transformer un système

Use case #1: Cartographier un système

Use case #2: Optimiser un système

Use case #3: Migrer vers le Cloud

Cartographier un système d'information

1) oA-Data-lineage-system : data lineage dans les bases de données

Le data lineage dans les bases de données

Cartographier un système d'information

2) oA-Data-lineage-viz : data lineage dans la couche de reporting

Data lineage dans la couche de reporting

Optimiser un système

1) oA-Optimization-system : détecter les branches mortes dans les alimentations

Détecter les branches mortes dans les alimentations

Optimiser un système

2) oA-Optimization-viz : détecter les dashboards inutiles, répliqués

Détection des dashboards inutiles, répliqués

Migrer vers le Cloud

1) oA-Migration-system : migrer le code procédural

Traduire les langages procéduraux/objets

Des réponses techniques

Migrer vers le Cloud

2) oA-Migration-viz : migrer des dashboards vers le Cloud

Migrer les technos de data visualisation

Méthodologie

découvrir quelques fonctionnalités

News

2022-04-07Ellipsys était au FIC 2023 !

2022-12-01{openAudit} fait partie du catalogue UGAP !

2022-09-27Conférence : transformer son système d'information grâce au Data Lineage !

Méthodologie : analyse dynamique de 5 stacks

Inventaire des données :

Inventaire des données :

Parsing et analyse des logs :

Parsing et analyse des logs :

Introspection de la couche de dataviz:

Introspection de la couche de dataviz:

Reverse engineering du code :

Reverse engineering du code :

{openAudit} ?

spécificités :

Parsing du scheduleur :

Parsing du scheduleur :

Contact

3 cas d'usages, 6 features,
pour transformer un système

Use case #1:

Cartographier un système

Use case #2:

Optimiser un système

Use case #3:

Migrer vers le Cloud

2022-04-07
Ellipsys était au FIC 2023 !

2022-12-01
{openAudit} fait partie du catalogue UGAP !

2022-09-27
Conférence : transformer son système d'information grâce au Data Lineage !

{openAudit}
?