Pourquoi les technologies SQL et NOSQL ont failli à libérer tout le potentiel des données Analytics ?

Pourquoi les technologies SQL et NOSQL ont failli à libérer tout le potentiel des données Analytics ?

Historiquement, les données de pilotage ont pris naissance dans le Data Warehouse mis en œuvre dans des bases de données de type SQL, dans les années 1980.

Les bases de données SQL étant fragiles au changement (ajout de colonnes SQL, ajout de relations SQL, contraintes relationnelles SQL), l’augmentation de périmètre des données de pilotage coute cher. Ce risque a provoqué un frein dans la mise en œuvre de nouveaux indicateurs de pilotage par les données. La valeur apportée par ceux-ci étant mise en balance face au risque de mise en œuvre.

Ces limitations ont amené les plateformes de données Analytics à se figer dans le temps à la façon d’une « statue de sel ». Le potentiel des données se trouvait restreint sans réellement pouvoir envisager une porte de sortie.

La nouvelle technologie NOSQL a émergé dans les années 2005 pour faire « exploser la statue de sel ». Cette technologie faisant table rase des contraintes SQL, elle portait la promesse d’une expansion de la valeur métier sans limitation technique.

La technologie NOSQL a favorisé l’alimentation de données de façon massive et anarchique.

Les concepts métier et leurs liens ne pouvant plus être modélisés, la valeur métier de ces grands puits de données devenait insaisissable.

Des effets indésirables sont rapidement apparus. Plusieurs indicateurs manipulant les mêmes concepts métier pouvait produire des valeurs en écart du fait de la réinterprétation par les développeurs des données d’alimentation. Plusieurs indicateurs manipulant les mêmes concepts métier pouvait utiliser une terminologie différente donnant l’illusion de concepts flous, difficilement interprétables et surtout difficilement corrélables avec d’autres indicateurs. Autre point, la mise en œuvre d’un nouvel indicateur coute le prix total car il n’y a pas de recyclage de tout ou partie des données déjà présentes sur la plateforme.

La Cloud-ification de ces plateformes a souvent sonné le glas des pratiques d’alimentation massive NOSQL.

Durant les années 2010 est apparue la nouvelle technologie Datavault (même si les concepts étaient déjà posés depuis plus de dix ans)., Cette technologie promet la représentation des concepts métier avec leurs liens tout en permettant une expansion sans limite. En somme tous les avantages des technologies SQL et NOSQL sans aucun de leur inconvénient.
La technologie Datavault s’appuie sur la modélisation physique SQL tout en séparant les tables et les colonnes. Le résultat est un schéma SQL complexifié et couteux à mettre en œuvre.

Certaines solutions du marché proposent l’automatisation de ces aspects de modélisation pysique.

Les vertus du Datavault automatisé sont donc les suivants :
•    Concepts métier et leurs liens clairement matérialisés de façon centralisé (modèle Datavault), qualité améliorée
•    Les flux d’alimentation étant déversés dans le modèle Datavault, les valeurs des différents indicateurs sont cohérentes entre elles, qualité améliorée
•    La création d’un nouvel indicateur profite des données déjà modélisées et alimentées dans le modèle Datavault, time to market réduit
•    Le paramétrage de tous ces éléments étant automatisé (drag/drop à la souris et very low code), le dispositif des développeurs peut de réduire jusque moins 80%, réduction du budget

En conclusion, la nouvelle technologie Datavault réussira là ou SQL et NOSQL ont échoué.