close

1) {oA.Lineage}-DataFlows : data lineage dans les DataFlows

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 sont disponibles, 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).

Cas d'usages :

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.

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 data point 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 data point (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 data point 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é.

---

2) {oA.Lineage-viz} : data lineage dans la couche de data visualisation

{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 a 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.

Cas d'usages :

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.

Pourquoi c'est utile

• 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.

• Les technologies de data visualisation permettent maintenant de faire de la "data prep" dans des proportions importantes, ce qui créé une forte opacité.

Techniquement

• {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.

close

1) {oA.Harmony}-DataFlows : détecter les branches mortes dans les DataFlows

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 impact considérable : inertie des systèmes, coûts de maintenance, des factures Cloud insoutenables, et de forts impacts environnementaux (GES).

Cas d'usages :

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

Techniquement

• {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.

• À 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’elle ne soit 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.

---

2) {oA.Harmony}-DataViz : 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.

Cas d'usages :

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

Techniquement

• {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.

close

1) {oA.Reverse}-DataFlows: migrer les technologies DataFlows

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.

Cas d'usages :

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

Le problème

• Les grandes entreprises accumulent les technologies de processing depuis toujours. On assiste à un empilement 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.

• À 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.

Techniquement

• {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 (par exemple 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,

• Éventuellement, 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.

---

2) {oA.Reverse}-DataViz : 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.

Cas d'usages :

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

Cinématique d'ensemble

• 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 permet de l'adresser à nouveau 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 œuvre peuvent l'être dans un temps record !