Reinventing dataviz: Intelligent migration of the semantic layer, for a “Self BI” model

 

Reinventing dataviz:

 

Intelligent migration of the semantic layer,

for a “Self BI” model 

The brilliant idea of ​​the creators of the concept of "semantic layer" was to allow access to data (almost) to everyone  😊.

 

One of the positive effects of this approach was also the standardization of business rules: a single version of the indicators ensured that everyone used the same definitions, without having to understand the IT architecture.

 

However, the transition to the Cloud has upset this balance, with a very high rate of "move to Cloud" of the analytical stack. 

Very often, this migration is an opportunity to modernize the entire stack, including by changing the dataviz tool. Indeed, some solutions, such as Cognos or SAP BO, are now perceived as rigid and costly to maintain. Others, such as Tableau or Qlik Sense, require very structured underlying models and remain expensive.

 

In a "Self BI" logic, we will consider that the source semantic layer is a high-value base that must be carried over to the target. This is so that teams can  quickly and qualitatively build tomorrow's analytical responses, without dragging the heaviness of the past. 

 

But we quickly realize that each "legacy" tool has its own logic (BO Universe, Cognos Framework Manager, Qlik Data Model, etc.), often quite complex, difficult to reproduce and develop. 

 

Unless you change your technical approach. We'll explain it to you. 

 

Option 1:

An “as is” migration:

Reproduce reports (template, intelligence) 

The promise of a “turnkey” migration is attractive.


Unfortunately, an "as is" migration, when the source platform is very old, involves taking on board all the past inertia : management rules that are as numerous as they are abstract or poorly documented, useless or replicated dashboards, etc.

 

This approach, which has the advantage of theoretically limiting subsequent change management, remains costly due to the workload it represents. And buy-in is not always there.

And then what is the point of "remarrying" almost definitively with another publisher in these times of uncertainty? 

 

Option 2:

A “Self BI” migration: 

Reconstructing a semantic layer with a star model

This "disruption" strategy consists of exiting the source platform without immediately recreating a target platform, but rather gradually and in line with the priorities of the moment, in Self BI mode.

It will also be a question of creating the conditions for interoperability. 

How to migrate the semantic layer? 

  • The semantic layer of the source solution will need to be segmented based on the contexts and fact tables actually used . This approach is based on the actual usage of the original platform : we often see that only a fraction of it is actually used compared to the whole.
  • Each set of semantic information will need to be transformed into granular semantic data according to a star model centered on the fact table: we will segment the complexity of the source semantic layer into simple elements.

"Freedom is ours!" 

  • This approach allows to build a centralized and optimized semantic layer within the target tool, with operation independent of the target proprietary dataviz tool. 
  • ....This semantic layer is therefore much simpler to transpose to another dataviz solution. 
 

Migrate some "as is" reports

anyway ?

 

Commentaires

Posts les plus consultés de ce blog

Migrer de SAP BO vers Power BI, Automatiquement, Au forfait !

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

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