Ce que vous économisez en coûts de stockage, vous le perdez en maintenance

” Oui, il semble financièrement intéressant de stocker les données des applications dans un data lake ou un data warehouse. Mais est-ce aussi efficace pour les sources disposant de données structurées, sémantiquement riches et sécurisées provenant de vos applications métier ? Ensuite, vous devez peser les coûts d’hébergement et de maintenance les uns par rapport aux autres. “

Stijn, vous êtes Analytics Solution Advisor chez SAP. En tant que passionné de données, vous êtes un adepte des data lakes et des data warehouses, où vous avez toutes les données à votre disposition, n’est-ce pas ?

Oui en effet, j’ai vu de nombreux cas d’utilisation intéressants où de grandes quantités de données sont collectées de manière structurée et non structurée dans, par exemple, un data lake. Et c’est utile pour un certain groupe d’utilisateurs avancés, comme les Data Scientists qui sont à la recherche de données brutes.

Stijn, expliquez-vous.

Un data lake est agnostique : vous pouvez y placer n’importe quel type de données : structurées, non structurées, en continu… Mais agnostique signifie également que lorsque vous extrayez des données de sources bien structurées comme les applications SAP Core, vos données sont dépouillées de tout contexte applicatif et commercial.

Supposons que vous vouliez analyser l’historique de facturation d’un certain client. En réalité, une facture dans un ERP SAP est composée de plusieurs tables avec des relations internes complexes, qui forment ensemble un objet de gestion : un ensemble sémantique riche et parfaitement compris par les comptables. Dans un data lake, vous ne pouvez plus voir toutes ces tables dans leur contexte métier et le contexte métier doit donc être reconstruit.

En fin de parcours, l’entreprise est à nouveau dépendante de l’IT pour le set-up, la maintenance et la disponibilité des données. Et l’IT doit être disponible pour toute nouvelle demande d’ajustement de la part de l’entreprise.

Il existe également des défis à long terme. Par exemple, si SAP décide de mettre à jour le système d’origine, cela peut avoir un impact majeur sur la structure des données. À chaque mise à jour de chaque application d’entreprise, le service informatique doit vérifier s’il y a des changements et comment les mettre en oeuvre – si nécessaire.

Un data lake ne résoudra pas tous les problèmes, mais le fait de disposer de toutes les données en un seul endroit dans le cloud est un grand pas en avant pour la plupart des organisations, n’est-ce pas ?

Une “one single source of truth” reste importante, mais je vois certaines entreprises s’orienter vers un “Data Mesh (maillage de données)”. Donc se connecter à l’endroit où se trouvent les données plutôt que de dupliquer toutes ces données. Un maillage offre également la possibilité de donner à différents départements la propriété de leurs données et de leur permettre de collaborer sur les données en mode libre-service.

Alors comment voyez-vous l’architecture idéale pour amener vos données dans le cloud ?

Partez de votre cas d’utilisation et de vos systèmes sources. L’intention est-elle de permettre aux utilisateurs finaux d’accéder aux données afin d’effectuer des analyses et d’obtenir des informations sur ces données ? Et vos données critiques sont-elles situées dans un système SAP ? SAP n’a pas son pareil pour accélérer la valorisation de ces données et de ces sources et pour enrichir ces données avec des données non SAP. Si vous vous penchez plutôt sur les cas d’utilisation Data Science sur des données non structurées et/ou en continu, alors il est certain que les hyperscalers avec leurs data lakes ont également leur rôle dans votre architecture de données.