Technical and massive
data lineage


{openAudit}, une fusion du data lineage
et de l'analyse des usages de l'information, pour
cartographier un système d'information,
et le transformer :
réduction de la dette IT, migrations Cloud.

Persistence

{openAudit} grâce à sa capacité d'introspection technique incomparable, nous permet d'atteindre ces objectifs : comprendre les usages des données, simplifier notre legacy et accélérer notre migration vers le Cloud.''

{openAudit} offre une analyse d'impact et d'excellentes capacités de data lineage avec un parser PL/SQL (notre techno phare pour notre processing), un parseur que nous n'avons jamais rencontré dans d'autres outils. Cela nous permet également d'opérer le nettoyage nécessaire dans notre code, avec d'excellents résultats.”

{openAudit}, un outil simple d'utilisation qui offre une vue rapide et claire de notre environnement SAP/Microsoft, mais fournit également un data lineage très utile pour l'analyse d'impact, un composant essentiel pour nos projets compliance.”






Méthodologie : analyse dynamique de 5 stacks

Inventaire des données :

Un "data catalog" avec des fichiers, des flux, des jeux de données : toutes les données physiques persistées ou in memory, vues, rapports...

Parsing et analyse des logs :

Pour la consommation et l'injection des données.

Introspection de la couche de dataviz:

> Connaître le lien entre les informations techniques et métier,
> Rassembler l'intelligence (les règles métier),
> Propager les termes métier dans les couches d'alimentation pour conserver une lecture "business" des process.

Reverse engineering du code :

Pour un data lineage technique, granulaire, de bout en bout, synchronisé avec le SI.

spécificités :

> Toute les analyses sont opérées quotidiennement, en mode delta, pour qu'{openAudit} soit continuellement synchronisé avec le Système d'Information.
> {openAudit}, c'est aussi des bases de données ouvertes et des interfaces web, on prem' ou en SaaS.
> Nous mettons à disposition des API's ou des micro composants web sur demande.

Parsing du scheduleur :

Pour comprendre l'ordonnancement et le relier au data lineage et aux usages de la donnée.




Notre partenaire "Dawizz" nous permet d'adresser également la partie
"data catalogue" avec une solution intégralement automatisée.

Dawizz



3 grands use cases

Use cases #1:

Cartographier un SI

Les équipes changent, les technologies s'empilent, les volumes explosent.
{openAudit} est un logiciel qui permet de démocratiser la data gouvernance : {openAudit} opère un reverse engineering exhaustif sur tous les processus internes pour partager à tous une lecture fine et objective du système d'Information.

Use cases # 2:

Effacer la dette IT

Pour baisser la maintenance, pour réduire les coûts de licence, pour faciliter les migrations techniques ou pour aller vers la green IT, {openAudit} permet les simplifications massives et itératives des systèmes d'information, en identifiant les éléments inutilisés, répliqués, inopérants, on premise ou dans le Cloud.

Use cases #3:

Migrer vers le Cloud

Les projets de migration sont récurrents dans les entreprises, que ce soit pour des migrations d'outil à outil, ou pour porter des systèmes d'information complets vers le Cloud.
{openAudit} permet de conduire ces migrations rapidement et précisément en automatisant les processus, tout en limitant les régressions.

Use case #1 - Cartographier un système d'information


1-1 Le data lineage et les usages de l'information

{openAudit} permet d'appréhender les flux de données multi technologiques de bout en bout, on premise et dans le Cloud, y compris dans la couche de dataviz qui agglomère d'innombrables règles de gestion.
{openAudit} permet de rentrer dans le détail des flux et d'avoir un apperçu du code, de l'ordonnancement, et surtout des usages de l'information (requêtes adhoc, outils de dataviz).
{openAudit} propose différents modes de représentation graphique pour son data lineage : un "bout en bout", sans les transformations, jusqu'à un data lineage ultra granulaire, au champ, qui détaille toutes les transformations.

Use cases :
Partager une compréhension détaillée de la construction des chaînes d'alimentation au sein des équipes data, identifier les ruptures et les corriger, BCBS 239 (Bâle III), RGPD…

data lineage

Le data lineage et les usages de l'information

Un véritable data lineage de bout en bout, 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 des journaux d'exécution.

> Autres : en cas de transfert d'informations par FTP, ou lorsque le schéma de base de donnée 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 :

> Data lineage dans la couche de dataviz : {openAudit} va présenter toutes les transformations du dashboard, depuis les couches d'alimentation jusqu'à la cellule, et va permettre de passer en revue l'ensemble des règles de gestion mises en oeuvre.

> Data lineage dans les couches d'alimentation : {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, le 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 défini d'un simple clic.

Use case #1 - Cartographier un système d'information


1-2 Une analyse d'impact multi technologique

{openAudit} permet d'appréhender l'ensemble des technologies de dataviz de l'entreprise sur une interface unique d'analyse d'impact : il s'agit d'une grille filtrée qui permet d’opérer des analyses rapides pour comprendre quelles sont les interractions entre chacun des éléments utilisés dans le dashboard, et le champ physique en source (ou la vue). Cela va de la cellule du dashboard, à la query qui interroge la base de donnée, à 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.

Use cases :
Définition instantanée des impacts d'une données dans l'ensemble des technos de dataviz, sourcing instantané d'une donnée d'un dashboard, etc.

data lineage

Une analyse d'impact multi-technologique

Certaines technologies de dataviz 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 dataviz interrogent souvent des vues, des vues de vues… ce qui complique encore une fois le sourcing.

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

Des réponses techniques :

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

> {openAudit} analyse le contenu des vues pour identifier les champs physiques qui sont en source des données d'une couche de dataviz, 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 dataviz. Simplement.

> En complément, {openAudit} permet de sur-administrer spécifiquement SAP BO, PowerBI et Qlik Sense : détection des tableaux de bord inutiles, des objets répliqués, inutilisés, pour ainsi redonner de la clarté aux utilisateurs, simplifier une plateforme, éventuellement la décommissionner.

Use case #2 - Effacer la dette IT


2-1 Optimiser/réparer les chaînes d'alimentation

{openAudit} analyse des logs du scheduleur et identifie dynamiquement les jobs qui sont opérationnels, ceux qui ne le sont pas, ceux qui sont lents, ceux qui décélèrent, etc.
{openAudit} propose un accès direct au contenu de tous les jobs ELT/ETL ou procédures déclenchés, de rentrer dans le détail du flux pour zoomer sur le code incriminé.

Use cases :
Monitoring dynamique de la qualité du run, fix de ruptures dans les chaînes d'alimentation, simplification massive du plan de production pour un run efficace et moins énergivore.

data lineage

Optimiser/réparer les chaînes d'alimentation

Les équipes informatiques schedulent d'innombrables procédures ou tâches qui surchargent le run. Il y a un risque toujours croissant d'exécution partielle du run, voir d'échec du run, et il est excessivement difficile de faire un mapping entre le plan de production et les chaînes d'alimentation elles-mêmes.

Des réponses techniques

> {openAudit}, grâce à l'analyse dynamique des journaux d'audit et de la couche dataviz, permet de savoir ce que les utilisateurs consomment réellement.

> {openAudit} met en lumière la myriade de tâches / procédures ETL/ELT schedulées, sans qu'il y ait d'usage des informations en bout de chaîne. Le run peut ainsi être simplifié.

> Ce monitoring permet de savoir en continu quels jobs du scheduleur sont dysfonctionnels (lents / inopérants), avec une analyse du contenu de la procédure / job ETL-ELT déclenché, une analyse d'impact granulaire de la procédure / job ETL-ELT, un drill through sur le code de la procédure / job ETL-ELT.
En quelques instants, il devient possible d'intervenir à la source du problème dans les chaînes défaillantes.

Use case #2 - Effacer la dette IT


2-2 Détection de la matière morte du système d'information

Grâce à une analyse permanente des logs d'audit, associée au data lineage, {openAudit} identifie tous les éléments inutilisés dans les couches d’alimentation (tables, fichiers, procédures, job ETL/ELT).
En moyenne, 50 % des informations du système d'information n'ont pas de valeur ajoutée (répliquées, obsolètes), ce qui a des impacts considérables : inertie du système, coûts inutiles, etc.

Use cases :
Décommissionnement en vue de la préparation à une migration, rationnalisation d'un système pour baisser la maintenance, réduction du licencing, projet green IT.

data lineage

Détection de la matière morte du système d'information

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.

Des réponses techniques :

> {openAudit} analyse les journaux des bases de données d'audit et la couche dataviz 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 dataviz, ou les requêtes adhoc (ODBC, JDBC), ou encore à partir de flux ETL/ELT spécifiques, {openAudit} identifie les flux d'information, les tables, 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 soint jamais exploitée.

> {openAudit} met en œuvre ces analyses de manière dynamique, et permet ainsi, en créant une profondeur d'historique importante, 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.

Use case #3 -
Migrer vers le Cloud


3-1 Traduire les langages procéduraux/objets

Les migrations technologiques des langages objets/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.

code-migration

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

Use case #2 -
Migrer vers le Cloud


3-2 Migrer les technologies de dataviz

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, Data Sudio ou PowerBI, migrer Qlik Sense vers Power BI, etc., de nombreux cas de figure sont possibles !

dashboard-migration

Migrer les technos de dataviz

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 dataviz à 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.

Un film de 6' pour découvrir quelques fonctionnalités





A propos d'Ellipsys:

Ellipsys a été fondée par Samuel Morin en 2013 au Luxembourg. L'idée de départ est que les Systèmes d'Information deviennent plus gros, plus complexes et plus hétérogènes au fur et à mesure que les technologies s'accumulent et que les utilisateurs se multiplient. L'ambition initiale d'Ellipsys était d'automatiser l'analyse de ces SI, de mettre les équipes techniques en capacité de les améliorer, de les rendre plus simples, plus faciles à migrer... Cela reste notre ambition.

Notre savoir-faire s'est fortement développé, notamment autour du data lineage technique, de sorte que nous pouvons désormais adresser l'essentiel des architectures techniques, on prem' ou Cloud : bases de données, ETL/ELT, outils de data visualisation
L'équipe est essentiellement composée d'ingénieurs IT, tous férus de recherche et développement... et d'impact client !

News

2022-09-27
Conférence : comment ADEO / Leroy Merlin transforme son SI grâce au Data Lineage technique !

Le groupe ADEO/Leroy Merlin a animé un workshop devant 150 personnes au Salon Big Data Paris 2022 pour expliquer comment il a opéré la transformation de son Système d’Information (simplification / migration GCP) en s’appuyant sur le data lineage, et pourquoi openAudit est indispensable au sein d’une architecture Data Mesh.

BDAIP2022

2022-14-09
La force et les limites du SQL ?

On retrouve du SQL absolument partout, y compris dans les couches métiers, encapsulé, ou « raccroché » aux bases de données, ou aux outils de dataviz. Mais pour les équipes en charge de la gouvernance des Systèmes d’Information, le reverse engineering pour déconstruire les flux d’information est souvent une gageure.

Les usages de la donnée

2022-09-09
BCBS 239, beaucoup de retard, la faute du « data lineage » ?

Un rapport du Comité de Bâle 2020 indique que malgré des progrès certains, les banques ne parviennent pas toujours à mettre en œuvre les 14 principes de BCBS 239. Et globalement, c’est bien ce sujet du « data lineage », donc du tracking de la donnée à travers les systèmes qui est bien souvent à la source de ces difficultés.

BCBS239

Contact

* These fields are required.