Documentation Technique

Transcription

1 Ellipsys openaudit Documentation Technique

2 Ellipsys openaudit Les différents niveaux d information La construction et le stockage de l information dans les entreprises s effectue techniquement à différents niveaux : Dans les «core systems» : il s agit d applications transversales répondant à un besoin métier unique. Pour une banque de détail, il s agira par exemple de la gestion des prêts immobiliers, des assurances, des opérations. Pour une institution comme Pôle Emploi, ce sera plutôt la collecte des offres, des demandeurs, de la demande. Ces applications se regroupent généralement dans des ERP (Enterprise Resource Planning) pour la gestion quotidienne des tâches ou des EAI (Enterprise Application Integration), voire dans des applications surmesure telles que les applications en COBOL exécutées sur Mainframe. Dans les systèmes décisionnels : ils collectent les informations opérationnelles émanant des «core systems» mais également en provenance de l extérieur pour constituer la mémoire de l entreprise. Cette information est fortement travaillée, consolidée, pour fournir des vues moins complexes et plus synthétiques aux utilisateurs. Dans les systèmes de gestion du contenu : il peut s agir de CMS (Content Management System) ou GED (Gestion documentaire) ou plus globalement les EIM (Enterprise Information Management) lorsque ces deux premiers se combinent avec les systèmes décisionnels. La particularité de ces systèmes est la nature de l information qui est globalement non structurée. Nous retrouverons plus particulièrement des documents, feuilles Excel, différents médias (audio, vidéo, web). La plupart de ces systèmes s appuie sur des EAI à l instar des core systems. Ce type d information non structurée évolue rapidement (dans le sens versioning) mais n est pas transformé par des processus internes automatisés. Avec l avènement du Big Data, de nombreuses bases ont émergé pour stocker ces données non structurées. Elles peuvent être orientées document (MongoDB, CouchDB), de type «key-value» comme Redis, de type graph-db comme Neo4j (pour accélérer les relations entre entités) ou plus simplement des bases distribuées comme hadoop, hypertable pour ne citer que les plus connues. Dans les Business Process Management : ces systèmes d informations héritent des traditionnels workflows. La modélisation des processus métiers offre une mine d information encore largement inexploitée dans les systèmes décisionnels traditionnels. Tant que ce type d information n est pas réellement exploité par les systèmes décisionnels, elle reste souvent cloisonnée. Son évolution dépend alors largement de la solution propriétaire. Nous pourrions ajouter à ces différents grands systèmes toute l information éparpillée dans les files systems des entreprises, messageries, annuaires, firewall, etc. Cependant, ces informations sont souvent traitées par les CMS et les BPM ou représentent une forme déstructurée non significative pour l entreprise. Les transformations de données L information évolue rapidement au sein des entreprises. En effet, la modélisation de l information sous forme de tables ou de fichiers (pour les bases de données), d objet (pour les CMS, BPM, par exemple), de vecteurs (cubes multidimensionnels) est différente en fonction du besoin et de l utilité de l application. Page 2 sur 10

3 Les systèmes décisionnels ont pour objectif principal de créer une mémoire centrale de l information d entreprise puis de créer des silos pour simplifier son accès, sa consultation et sa compréhension. Dans d autres systèmes, cette même information peut essentiellement être technique, i.e. encapsulée dans des processus ou sous des formats particuliers (XML, JSON, VESAM, LDAP, etc) pour faciliter les échanges et son intégration dans d autres applications, processus, bases de données. Dans tous les cas, l information est constamment manipulée, modifiée, enrichie, combinée pour produire d autres informations techniques ou métiers. Pour manipuler ces données, il existe trois grandes familles d outils : Des langages procéduraux fournis par les principaux acteurs du marché pour le stockage des données : Oracle PL/SQL (également repris par d autres acteurs Open Source), Transac-SQL (Microsoft, Sybase SAP), SAS, scripting Qlikview, langage MDX pour l analyse multidimensionnelle, SQOOP, PIG, HIVE pour les solutions Big Data de type Hadoop, etc. Des ETL (Extract Transform and Load) ou ELT (lorsque le progiciel s appuie sur le moteur de la base de données). Ces outils offrent des composants qui permettent de manipuler d énormes quantité de données. Chaque composant répond à un besoin spécifique tel que le SCD (Slow Changing Dimension), le CDC (Change Data Capture), des jointures entre différentes sources, agrégations, consolidations, filtres, switch, pivots, etc. Généralement, les ETL offrent nativement des outils d analyse d impact. Malheureusement ces derniers deviennent rapidement aveugles avec la prolifération de user exit ou hooks. Ces morceaux de code qui délèguent une transformation à un tiers telle qu une base de données (exécution de scripts SQL, procédures stockées, macros) cassent la chaîne d analyse. Par ailleurs, les outils d analyse d impact restent cloisonnés à la solution propriétaire et ne permettent pas de dégager une vision globale du cheminement de l information. En d autres termes, l ETL Datastage ne sait pas analyser des flux PL/SQL ni les jobs Informatica ou les procédures SAS. D autres langages objets, interprétés utilisés par les applications pour répondre à des besoins métiers. Les plus connus sont java, dot net, cobol, mais aussi pour de plus petites entreprises php, python, node js, etc. Le stockage de l information Le stockage de l information est tout aussi hétérogène que les processus d alimentation. Avec l'avènement du Big Data et du No/NewSQL arrive de nouveaux modes de stockage qui perturbent largement le marché actuel. Cela va à de simples gestionnaires de fichiers distribués (comme l architecture Hadoop) à de véritables bases de données qui peuvent être aussi bien distribuées, wide column store, in-memory, document store, etc. Si les acteurs historiques s accordent pour conserver un modèle d'interrogation de ces données (SQL, MDX), les nouveaux acteurs ne répondent pas nécessairement à cette exigence. Ainsi, une grande partie de ces nouveaux mode de stockage de l information est accessible depuis des connecteurs java,.net ou bien à partir de langage natif parfois propriétaire (SQOOP, HIVE, PIG, Qlikview). L accès à l information se retrouve donc généralement disséminée dans du code source éparpillé dans des serveurs d application. Page 3 sur 10

4 L analyse et la publication de l information En bout de chaîne, que ce soit pour de l analyse pure de type datamining ou plutôt exploratoire (multidimensionnelle par exemple) ou pour des besoins de reporting, dashboarding voire de la simple publication de l information, les solutions offrent également une grande panoplie d outils statistiques, de recherche, de consolidation, de mapping. En somme, pour retracer le cheminement complet de l information depuis le tableau de bord diffusé à l utilisateur finale jusqu aux différentes sources opérationnelles, il est nécessaire d explorer puis de traduire dans un langage ou des interfaces simples et intuitives une grande quantité de langages, de référentiels de méta données. Ceci implique d avoir de solides connaissances dans ces domaines ou de s appuyer sur des parsers / triggers qui permettront de collecter automatiquement ce type d information. Origine et devenir de l information Dans cette jungle technologique, suivre le cheminement de l information devient rapidement un enjeu complexe mais également crucial. En effet, l origine et le devenir de l information est soit dans les mains d experts (développeurs ETL, java, sql,.net, etc) soit éparpillée dans des repositories propriétaires de manière incomplète en raison des hooks. Pourtant, la simple méconnaissance de ces systèmes engendre des problèmes systémiques: augmentation inconsidérée du volume de données, des temps de traitement de l information, des temps de consultation qui peuvent se répercuter sur les autres systèmes, dans les autres services. La simple approche technique consistant à fournir d avantage de ressources machines ou humaines présentent très rapidement ses limites en coût mais également en énergie (au sens propre et figuré). Les réponses apportées à la paralysie d un système se concrétisent le plus souvent dans un audit des services concernés. Malheureusement, ces audits analysent une situation à un instant précis. Or, c est l évolution des systèmes et le manque de visibilité sur ces évolutions qui bloquent les services. Par ailleurs, ces audits aboutissent généralement à des refontes onéreuses qui se justifient la plupart du temps mais qui ne traitent pas nécessairement du mal profond : la traçabilité de l information. En effet, même en repartant sur un système sain, propre, bien construit, le manque de visibilité sur les flux de transformation de l information conduira systématiquement vers la duplication de règles de gestion, de tables, de rapports et par extension engendrera rapidement une redondance d information plus complexe à maintenir, à faire évoluer bref une inertie forte et incontrôlée. Retour à la case départ. Ce gaspillage de temps et d énergie peut largement être évité. En début de projet, le bon sens amène généralement à centraliser et mutualiser les grandes règles de gestion pour simplifier la maintenance. Mais ces règles de bon sens sont malheureusement très vite abandonnées avec la multiplication des acteurs / intervenants qui n ont pas forcément une bonne connaissance de la gouvernance globale du projet. En d autres termes, miser sur la simple bonne gouvernance d un projet pour établir une maintenance saine et pérenne du système ne suffit pas à écarter un projet du risque de paralysie dans le temps. Automatisation de la traçabilité de bout en bout sans rupture Des capteurs et des parsers. OpenAudit offre actuellement plusieurs catégories de parseurs (code) et de capteurs (repository) qui s emploient à analyser les transformations qui ont lieux au niveau de l ETL mais également dans tous les «user exits». Ainsi, à la différence des analyses d impact classiques, il n y a pas de rupture dans la chaîne permettant également un vrai data lineage. Page 4 sur 10

5 Les parsers d ores et déjà mis en œuvre chez des clients sont les suivant : PL/SQL Ce parser va beaucoup plus loin que les tables de métadonnées d Oracle qui permettent uniquement de détecter les dépendances entre packages. Il permet de chaîner les tables sources et cibles qu elles soient temporaires, physiques ou montées en mémoire (pipeline table). Le parser détecte également le SQL dynamique et permet d analyser le code généré en fonction des données d une table de pilotage. A titre d exemple, 100 Mo de lignes de code (plus d un million de lignes) sont analysés, décomposés puis organisés en moins d une minute. En fin de parsing, toutes les transformations sont chaînées entre elles. Cet enchaînement ouvre la voie à des représentations graphiques très conviviales pour naviguer dans l information (data lineage) ou à une analyse tabulaire pour mesurer les impacts. SAP BODI & Business Objects (BO) Le repository de cet ELT et de cet outil de reporting ne gère pas les dépendances vers le SQL natif. A l instar de la plupart des ETL/ELT, BODI rompt sa chaîne d analyse dès lors que le développeur écrit lui-même son propre script. Il en est de même pour Business Objects, l outil de reporting de SAP (Free Hand SQL). Le parsing des flux BODI et du repository de BO sont extrêmement rapide. Par ailleurs, des modules supplémentaires ont été ajoutés dans le parsing de BO pour évaluer les données réellement utilisées par les utilisateurs. D autre part une introspection fine des rapports BO (qu ils aient du free hand SQL ou non)permet de détecter tous les objets du rapport qui ne sont pas utilisés pour ne pas fausser la première analyse. Cela présente un double avantage : 1. La possibilité de nettoyer des rapports complexes, de retrouver rapidement où sont utilisés les objets ou les variables dérivées d un objet dans la structure du rapport. 2. D évaluer très rapidement la pertinence d un objet BO et de son impact dans le système existant. Datastage Aussi bien pour les versions Server que Parallel Extender, ce parser ne s appuie pas sur le repository de datastage mais sur le code dsx généré par le designer. Cela représente l avantage de récupérer les scripts exacts passés par les utilisateurs (user exits) et de détecter les jobs en mode RCP (Runtime Column Propagation). Ce mode permet aux développeurs de factoriser leurs jobs mais génère une rupture dans l analyse d impact. Un autre avantage d intervenir depuis le code DSX (à l instar du code ATL de SAP BODI) est de pouvoir utiliser également la grammaire du parser pour générer automatiquement du code DSX (ou ATL pour BODI). Ainsi, il peut être envisagé de générer automatiquement l ensemble des flux d un Data Warehouse en gérant aussi bien l historisation par SCD (Slowly Changing Dimension) que la création d événements sur une table. Le schéma ci-dessous représente le type de job très élaboré généré pour datastage : Page 5 sur 10

6 Informatica PowerCenter Le parser d Informatica est l un des plus accessibles car «la grammaire» est fournie par un fichier DTD (structure XML) qui permet de retrouver aisément l information clé dans le code. Par ailleurs, Informatica est l un des ETL/ELT les plus ouverts et les plus intuitifs du marché. Il est également possible, à l instar de SAP BODI, de retrouver facilement une partie des métadonnées depuis le repository de PowerCenter. Cependant, cette démarche présente deux inconvénients : Elle ne permet pas de générer du code automatiquement (ce qui ferme la porte au futur module d OPENAUDIT). Elle n est pas complète, elle nécessite de parser dans tous les cas tous les hooks (pushdown SQL, SQL override, etc). Analyser et communiquer Pour les utilisateurs, OpenAudit se matérialise par un portail Web qui offre de nombreux points d accès en fonction du type de population. L objectif de ce portail est de permettre une vue de bout-en-bout de l ensemble de la chaîne de transformation de données. Page 6 sur 10

7 De cette manière, si l utilisateur est plutôt fonctionnel, il partira essentiellement des informations qu il retrouve habituellement dans ses rapports, dans sa couche sémantique (pour Business Objects, Cognos, SAS) pour naviguer ensuite dans les différentes couches des systèmes d informations. A l inverse, les développeurs partent plus facilement des différentes sources opérationnelles pour remonter ensuite vers les données propres aux utilisateurs (datamarts, rapports, cubes, couches sémantiques, etc) pour analyser les différentes transformations, mesurer les impacts et les évolutions pour simplifier, rationaliser et mutualiser les développements existants. Analyser et casser la complexité Que la population soit technique ou fonctionnelle, la complexité apparaît à différents niveaux : Dans les termes techniques et métiers employés : chaque métier possède son propre vocabulaire très pointu qui rend toutes les discutions hermétiques aux néophytes. Ce vocabulaire, qui est aussi souvent utilisé pour justifier une expertise ou creuser volontairement un fossé, est à la base de très nombreux problèmes de communication. C est d autant plus vrai lorsque l interaction entre les services métiers et l IT est très forte. Les systèmes décisionnels illustrent parfaitement cet exemple. Enchevêtrement de technologies (mille-feuille) : il n est pas rare de retrouver dans les processus de transformation ou de stockage de données l emploi d un très grand nombre de technologies qui sont encapsulées entre elles. Par exemple un job ETL qui appelle un batch UNIX qui exécute une macro Teradata qui fait appel à une procédure stockée qui manipule des fichiers pour insérer et mettre à jour des tables. L architecture applicative peut rapidement dégouter les experts les plus motivés. Profusion de données (tables, fichiers, cubes, rapports, etc) : la richesse, l abondance d information est également un risque majeur pour entrer dans un cercle non vertueux : duplication de l information, des règles de gestion, augmentation de la volumétrie, des temps de consultation et de chargement. Ce risque est d autant plus fort lorsque l architecture fonctionnelle est mal définie, i.e. présentation et utilité des différentes couches logique de données. Abondance des règles de gestion, de calculs (transformations de données) : ce point rejoins fortement le précédent. Le manque de visibilité et d information sur l architecture fonctionnelle et la gouvernance globale d un projet peuvent rendre la gestion du système totalement anarchique. Il est essentiel de partager les grandes règles et l utilité des différentes couches logiques et physiques pour éviter la multiplication des règles identiques à des niveaux différents. La mutualisation et la factorisation des règles sont le principal levier de simplification d un système d information. Partager la connaissance pour mieux communiquer Partager la connaissance entre les différents partis permet de réduire les bras de fer entre services et de restaurer un bon niveau de confiance dans les projets. Seulement, la transparence du système ne doit pas se limiter à un instant précis mais elle doit suivre son évolution. C est pour cette raison essentielle qu il est primordial d organiser le portail autour d une vision objective de la réalité, en d autres termes du résultat du parsing des différents moteurs de transformation (ETL, scripts) et des différents fournisseurs d informations (reporting, analyses, etc). Page 7 sur 10

8 Par ailleurs, partager la connaissance s est également partager une gouvernance. La multiplication des acteurs et des intervenants multiplie les risques de dérapage. Sans une vision claire, formalisée et organisée, les nouveaux intervenants ne pourront comprendre la logique du système et retrouver l information essentielle pour continuer à avancer dans le cadre défini. Avec une vision de bout-en-bout du système, les transferts de compétences et de connaissances sont très largement réduis et l interactivité du portail sous forme de zoom pour affiner sa compréhension limite la léthargie des acteurs (qui se retrouve avec de la documentation papier). Enfin, partager la connaissance permet également de cerner les difficultés et donc de communiquer promptement sur les incertitudes rencontrées. La résolution des problèmes passe par les compétences de tous les acteurs. Les réponses d openaudit Pour casser cette complexité et partager la connaissance, openaudit apporte plusieurs solutions : Création d un langage commun : en liant graphiquement les définitions métiers et techniques et en permettant d enrichir les définitions et les commentaires sur des objets, des règles de gestion, des transformations par l ensemble des partis concernés (métiers et techniques), un dictionnaire commun compréhensible de tous se met en place naturellement. Ce langage commun accélère significativement par la suite les cycles de spécification du besoin et les développements. Par ailleurs, la complexité étant alors partagée et simplifiée, les parties de ping-pong entre services sont tout simplement anéanties. Décomposer la complexité : le portail représente graphiquement toutes les transformations ainsi que les données organisées par couches logique et physique réellement en place dans les différents environnements (développement, intégration, production et autres) avec notamment tous les commentaires, définitions écrits par les différents partis. La possibilité d enrichir le portail permet de suivre l évolution d un projet depuis la définition souhaitée d un besoin et la traduction technique engendrée. A l instar des problèmes de communication liés aux différents langages, la perception de la complexité est souvent liée à une incompréhension des mécanismes et processus de transformations ainsi qu au cycle de vie des données (gestion temporelle de l information). Cette appréhension de la complexité se retrouve à tous les niveaux, il suffit de compter le nombre de fois où les termes «usine à gaz», «blackbox» sont employés. La transparence d un système se fait plus rapidement lorsque sa présentation est fluide et cohérente : navigation simple et intuitive entre les différentes couches fonctionnelles, explication de l articulation entre ces différentes couches, cohérence des termes et des concepts. La possibilité de zoomer sur un domaine pour extraire les définitions à la fois métier et technique des transformations permet de décomposer la complexité et de «digérer» des concepts trop lourds. Une vision globale partagée : casser la complexité passe également par la classification des principaux domaines d information. L objectif est d organiser et de gouverner le système autour des transformations et informations existantes. De cette manière, le portail offre une première vision synthétique par couche par exemple (sources opérationnelles, ODS, Data Warehouse, Datamarts, couche sémantiques) ou par grand domaine fonctionnel (marketing, contrôle de gestion, RH ). Il ne reste plus qu à l utilisateur de zoomer pour affiner sa recherche et apprendre, comprendre la logique générale du projet. Le système devient rapidement beaucoup plus intelligible. Des interfaces simples, très rapides et intuitives : construites sur la base de la plateforme d Ellipsys Mosaïc, le portail délivre l information instantanément quel que soit le nombre d utilisateurs. Les interfaces du portail se construisent dynamiquement à partir du Layout Manager. Il s agit d un module qui permet de dessiner au sens propre du terme les interfaces graphiques web pour les différents utilisateurs. Page 8 sur 10

9 L exploration des métadonnées sous forme tabulaire ou de flow charts s appuie également sur le moteur d Ellipsys Mosaïc pour associer automatiquement les axes d analyses entre eux et surtout pour faire apparaître intuitivement les combinaisons d axes inexistantes. Pour illustrer ce dernier concept, il suffit d imaginer le filtre d un utilisateur sur une table d une base de données : il visualise en un seul coup d œil tous les univers BO utilisant cette table (les univers sont alors surlignés) mais également tous ceux qui ne l utilisent pas. Les bénéfices d openaudit Retrouver de l information sur un système en place se réduit généralement à lire des documents Word, Excel et quelques graphiques ou modèles de données. L intervenant aguerri aura la possibilité d effectuer du reverse engineering pour extraire, collecter et synthétiser cette information. Seulement, cette procédure est lourde, onéreuse, et son espérance de vie extrêmement limitée. Par ailleurs, cette information est également confidentielle dans le sens où elle n est pas nécessairement intelligible pour le plus grand nombre. Page 9 sur 10

10 Construire et organiser le projet autour d une analyse factuelle et objective de l existant. C est le pilier d une bonne gouvernance. Les capteurs et les parsers ne se trompent pas, ils restituent une image exacte de ce qui a été mis en place. La vision duale métier/technique de ces faits fait le reste : Validation partagée ; Réactivité accrue aussi bien pour la maintenance (accessible au plus grand nombre) que pour les évolutions ; Des itérations courtes, de plus en plus rapides ; Une solution non intrusive qui permet de redresser une situation en simplifiant / factorisant les bases de données, en mutualisant les transformations, ou mettant en évidences les dérives actuelles. Page 10 sur 10