Migrate SAP BO to Looker with a real semantic layer

 


 

Migrate SAP BO to Looker (Google) 

-

Rebuild

a real semantic layer!

“  To name things badly is to add to the misfortune of the world  ,” said Albert Camus. Naming them well can also help ensure the success of a business!

 

This was the great success of SAP BO, which, with its "Objects", translated very abstract IT concepts into business information that could be manipulated by as many people as possible.

 

This goes back a long time now, and many companies are leaving SAP BO, which is starting to become obsolescent and which is poorly suited to the Cloud.

 

Leaving BO also means separating from its “Objects”, organized in its very popular semantic layer, the “Universes”. 

 

But not necessarily. Particularly if the migration takes place to Google's Looker, which natively provides a semantic layer.

 

We explain how. 

 
 
 

Step 1:

 

A migration from Universes to Explores Looker 

 
  1. Our migration engine {openAudit} will divide the BO Universes (Business Objects) according to each context and fact table actually used in the BO reports used. Our migration engine is based on real use of the source BO platform. 
  2. Each BO Universe will be transformed into several Looker Explores based on a star model centered on the fact table. {openAudit} will only include what is used in SAP BO.

 

Each Explore Looker will allow users to create ad hoc queries, explore and visualize data.

It is a faithful resumption of the semantic layer, but it will remain quite far from the original Universes due to the technical specificities of Looker vs SAP BO. 

 

To make life easier for the profession, it seemed necessary to add a device to our migration engine. 

 
 
 
 

2nd step : 

 

Adjust this migration to make it more usable by businesses 

 

We have enriched our migration engine by dynamically providing a “control table”. It will allow the output to be simply configured, to move towards an ideal semantic layer, potentially very close to that of SAP BO. 

 

  1. The first run of our migration engine will feed the control table and produce LookML (Looker modeling language). 
  2. The processing will thus be "controllable", which will allow the profession to "play" to modify the Explores to its convenience. 
  3. The LookML will be versioned. 
 
 

 

Conclusion

 

The release of SAP BO is perilous. In particular because the semantic layer generates strong support.

Google Looker is a solution that will allow you to reconstruct a very functional semantic layer. 

 

To make this semantic layer as "experiential" as it was in SAP BO, our migration engine will build a control table to produce an output that can be very exploited by the business lines, almost instantly. 

 

Our migration solution has just been validated by Google Cloud Marketplace!

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

La Data Observabilité, Buzzword ou nécessité ?

Image
    La Data Observabilité,   Buzzword ou nécessité ?   La qualité des données utilisées dans les opérations quotidiennes a un rôle prépondérant pour les entreprises.    Une étude du Gartner de 2022 suggère que les "mauvaises données" coûtent aux organisations environ 12,9 millions de dollars par an.  Le Data Quality Hub du gouvernement britannique estime que les organisations consacrent entre 10 % et 30 % de leurs revenus aux problèmes de qualité des données, ce qui peut représenter des centaines de millions de dollars pour des entreprises de premier plan.  Dès 2016, IBM estimait que la mauvaise qualité des données coûtait aux entreprises américaines 3 100 milliards de dollars par an. ... Tout le monde souhaite s’appuyer sur des données intègres pour éviter des erreurs simples liées à des problèmes d’alimentation dans des flux, ou à des données mal organisées, répliquées, etc. Mais comment ?    Les techniques d' "observabilité des données" sont une option.     
Lire la suite

BCBS 239 : L'enjeu de la fréquence et de l'exactitude du reporting de risque

Image
  BCBS 239 :    L'enjeu de la fréquence et de l'exactitude du reporting de risque.  La BCE a publié un guide en juillet 2023 pour repréciser ses attentes dans le cadre de BCBS 239. Elle prévoit de renforcer le dispositif de supervision en matière de qualité des données.   L'objectif global de la norme BCBS 239 est de renforcer les capacités d'agrégation des données de risques des banques, et les pratiques internes de reporting de risques, améliorant ainsi les processus de gestion des risques et de prise de décision dans les banques. « La bonne information doit être à disposition pour les bonnes personnes et au bon moment ».   La mise en œuvre de BCBS 239 n'est a priori pas simple.   Pourquoi ? Malgré cette surveillance prudentielle accrue,  la BCE n’a toujours pas constaté de progrès suffisants en 2023 :  "le dispositif data quality et reporting risques ne reçoit pas encore le niveau d’attention approprié de la part des banques".   Nous avons beaucoup écha
Lire la suite

Le data lineage, l’arme idéale pour la Data Loss Prevention ?

Image
  Le data lineage technique couplé à la détection des usages de l’information permet de savoir au départ de n’importe quelle donnée, qui y accède finalement, et dans quel contexte. Et si c’était un grand pas vers une véritable sécurité informationnelle, une réponse simple et efficace pour la Data Leaks/Loss Prevention ?  La DLP (Data Leaks / Loss Prevention), c’est quoi ?   _______________________________________ « Le terme Data Loss/Leaks Prevention (DLP) fait référence à un ensemble de techniques qui permettent d’identifier, de contrôler et de protéger l’information grâce à des analyses de contenu approfondies, que l’information soit stockée, en mouvement, ou traitée . L’objectif est de limiter la fuite de données sensibles.  Une solution DLP est capable d’identifier les données sensibles, de repérer l’endroit où elle est stockée, de contrôler qui doit avoir accès à ces données et enfin de les protéger, c’est-à-dire d’empêcher toute personne non autorisée à y avoir accès… » W
Lire la suite