Pourquoi Datavault Builder est le meilleur choix pour SAP sur la Plateforme de Données

La mise en oeuvre des données SAP dans la plateforme des Données d'Entreprise peut sembler une tache complexe. L'Architecture Datavault automatisée par Datavault Builder permet de supprimer les risques tout en réduisant les délais.

Le Modèle

SAP ECC est basé sur des lignes comptables selon le modèle ci-contre. Le modèle natif SAP est encodé avec acronymes en Allemand.

Ces acronymes semblent incompréhensibles au néophyte. Cependant ils sont parfaitement compréhensibles par nos clients  opérationnels au département Finance.

Sur le projet de ce REX, le client a exigé l'implémentation avec la terminologie ci-contre.

 

Cet autre modèle ci-contre a été élaboré à partir de métadonnées SAP. Le référentiel d'Entreprise  Modelio permet la traduction du Modèle donc il est possible de l'implémenter au choix.

 

L'Architecture fonctionnelle Datavault centrée sur le Modèle Métier

Ce Modèle Métier est alimenté par des données sources et par des Business Rules (règles métier).

L'architecture Datavault évite un étirement incontrôlé de la pipeline grâce à son architecture de recyclage des Business Rules dans son modèle incrémental. Ainsi, les Business Rules sont centralisées dans une zone clairement définie.

De plus, cette architecture définit l'historisation qui se construit à tous les étages tout en intégrant les pratiques modernes.

 

Les Données SAP pas prêtes à l'emploi

Les données SAP ECC semblent pouvoir être requêtées nativement (suivant le modèle démontré ci-dessus), cependant elles ne sont pas prêtes à l'emploi.

De nombreuses défaillances sont redressées par la partie logicielle de SAP pendant son utilisation opérationnelle.

De ce fait il est nécessaire de redresser des données, des relations et de créer des indicateurs. Toutes ces actions permettront de fournir un modèle de données instancié pour rendre sont utilisation de façon intuitive à nos clients du département Finance.

La suite de cet article va démontrer tous les types de Business Rules (règles de transformation) à implémenter.

 

Certains redressements de données sont techniques et ne nécessite pas de solliciter l'architecture Datavault.

Dans ce type de scénario, il est possible d'implémenter des opération d'ETL-isation de la source avant l'étape de staging.

Ici, on a 2 transformations:

  • Rotation des langues en lignes vers colonnes (la Business Intelligence organise la sémantique en colonnes et les occurrences en lignes)

  • Par opportunité, le reconstruction de la colonne de jointure vers la taxonomie parent.

 

Dans cette étape pré-staging, il est possible de marquer les colonnes d'horodatage du Datalake comme référence CDC (Change Data Capture). Ce marquage est réalisé en utilisant le renommage cdc_incription_time.

Le compportement par défaut de Datavault Builder est de construire une colonne supplémentaire d'horodatage pour inscrire tous les changements identifiés à chaque chargement, conformément au standard 2.0.

 

Les Business Keys

Comme indiqué précédemment, l'Architecture Datavault favorise la flexibilité par des relation en liaison tardive (late binding). C'est ainsi que la définition des colonnes de relations est découplée de la modélisation.

Chaque concept métier/hub doit définir une business key. Dans cet exemple, il s'agit de la table BSEG (écritures comptables).

La clé permet d'identifier chaque enregistrement de façon univoque.

La clé sert également a ségréguer l'historisation SCD (Slowly Changing Dimensions) par instance d'enregistrement.

 

Les colonnes des tables sources sont instanciées dans des Satellites autour du Hub, on nomme cette zone Raw Datavault.

Dans l'exemple ci-contre, on voit le satellite des données de la table SAP BSEG (lignes comptables)

 

Les Business Rules

On rappelle que les règles métier permettent de reconstruire:

  • Des indicateurs

  • Des relations

Dans l'exemple ci-contre, on va ajouter des colonnes indicateurs OPEX_CAPEX et  PERIMETER_ACCOUNTING_ENTRY sur la table des écritures.

Note : le cas d'usage implémenté dans ce REX concerne l'analyse des dépenses (Spend Analysis)

 

La recyclage des Business Rules dans le Modèle Datavault

Datavault Builder fournit un connecteur de données permettant le recyclage des règles métier.

Les indicateurs produits sont recyclés dans un satellite autour du Hub portant le concept.

Dans le cas ci-contre, on a ajouté les indicateurs:

  • Opec/Capex

  • Perimeter Accounting Entry

sur le concept BSEG ou ligne comptable.

 

Les Business Rules au service des relations en liaison tardive

Certaines relations entre concepts peuvent être définies de façon chaotique dans le système source ce qui empêche l'utilisation d'une colonne FK (clé étrangère).

SAP présente ce type de malformation dans le cas de l'écriture comptable qui s'applique à un centre de cout (CSKS Cost Center) sur plusieurs colonne en fonction de la configuration de l''écriture.

L'exemple ci-contre montre la reconstruction de la relation BSEG-CSKS.

La règle métier produit la liste des Business Keys de BSEG et CSKS.

 

La centralisation des Business Rules

Comme vu précédemment, l'Architecture Datavault recycle les règles métier dans le modèle Datavault ce qui évite un étirement chaotique de la plateforme des données.

Datavault Builder centralise celles-ci dans un écran dédié. La barre de recherche permet de retrouver rapidement une règle.

De cette façon, l'intelligence de transformation des données est regroupé dans un endroit centralisé ce qui permet un audit très accessible de celle-ci.

 

Le Data Product Spend Analysis

Après que le Modèle a été défini, alimenté et augmenté (par les Business Rules), celui-ci est prêt à être utilisé pour produire des données.

Dans le cas présent la Big Table Spend Analysis produite dans la base de données dans une vue (matérialisée) prête pour la connexion avec PowerBI, Qlik, ...

 

Le Lineage du Data Product

 

Ci-contre apparait le lineage des centres de couts CSKS et les libellées en Français et Anglais CSKT. En vertical apparaissent les étapes dans la pipeline et en vertical apparaissent les sources.

 

Quelle valeur pour quel coût de la plateforme Data ?

Les couts ont de la valeur et certains autres couts n'ont pas de valeur pour l'Entreprise

  • Les couts à valeur ajoutée : la Modélisation, les Business Keys et les Business Rules

  • Les couts sans valeur ajoutée : design de l'Architecture, codage des flux de données dans la pipeline, ...

Datavault Builder permet d'apporter la valeur avec les seuls couts à valeur ajoutée.

Où est le code de la plateforme des données ? Il n'y en a tout simplement pas. Datavault Builder impémente ce code de façon générique selon le standard 2.0.

 

Combien de temps nécessaire ?

Pour implémenter l'ensemble de cette plateforme de données SAP, la charge a été de moins de deux jours/homme.

Note : cette charge n'inclut pas les travaux à valeur ajoutée, la Modélisation (dédiée à l'Architecte Data), les règles métier et les Business Rules (dédiées au Product Owner).