Dans ce chapitre nous avons introduit le concept de gravité des données, en tant que contrainte non fonctionnelle, pouvant influencer la conception d’architecture des lacs de données, notamment la relation donnée-traitement. A partir de travaux de MacCrory[46] et [3], qui incluaient le volume et la sensibilité comme facteurs compris dans la gravité, nous avons proposé d’y inclure l’évaluation du coût du déplacement des données.
Après avoir évalué l’impact de ce que ces trois facteurs pouvaient induire sur l’architecture des lacs de données, nous avons proposé un scénario d’architecture alternative, où toutes les données ne sont pas dupliquées physiquement dans le lac de données mais où certaines peuvent rester sur le système source qui les produit.
Cette proposition entraîne une architecture non plus mono technologique, mais hybride, dans laquelle d’autres zones de stockage, virtuelles, car non matérialisées dans le même environnement techniques mais référencées dans le catalogue de métadonnées, peuvent être englobées dans le lac de données au sens logique.
Nous avons étayé cette proposition par une étude de l’influence de la gravité des données, sur un lac de données industriel. L’étude que nous avons faite a démontré qu’effectivement, si la gravité des données est importante, pour certaines données sur certains serveurs, il faut envisager une alternative au scénario d’architecture en place. La duplication systématique des données pour alimenter le lac de données ne doit pas être la méthode systématique pour constituer un lac de données.
Au travers de cette étude, nous avons remis en cause la conception des lacs de données, qui repose sur certains postulats, qui s’avèrent défaillants. Cette étude fait apparaître le manque de conceptualisation dans la constitution des lacs de données.
Notre intérêt s’est donc porté sur l’exploration des approches de conceptualisation ou représentation pouvant s’appliquer aux lacs de données.
Nous nous sommes intéressés au méthodes de représentation qui s’affranchissent des produits logiciels, comme l’approche MDA (Model Driven Architecture), qui semble correspondre à notre recherche.
Le chapitre suivant est dédié à l’amorce de cette approche pour tenter de proposer une représentation des lacs de données.
Contribution à une démarche de
formalisation des lacs de données via
une approche ligne de produits
Nous souhaitons explorer une approche de formalisation constituant une aide à la mise en place de projets d’architecture (s’inscrivant dans une stratégie de développement d’architecture des systèmes d’information, conduisant à des produits pour un usage donné).
L’ingénierie des lignes de produits constitue une approche qui permet la formalisation d’une série de produits ou systèmes logiciels semblables qui ne différent que par des composants optionnels. Elle s’affranchit des logiciels1 mais prend en compte les principaux composants ou fonctionnalités que nous
avons identifiés (voir chapitre 4) et par suite la formalisation obtenue permet un gain considérable en termes de coût, de temps et de qualité.
6.1
Nos attentes
Le concept de lac de données est né de la mouvance des données massives et de la technologie Apache Hadoop. Sa conception est partie des logiciels présents sur le marché industriel, et s’est donc focalisée sur une technologie essentiellement. Nous avons vu dans les précédents chapitres que l’association lac de données - Apache Hadoop était très limitative et ne correspondait plus vraiment aux attentes des organisations, ainsi qu’au concept de lac de données. Nous avons vu ses évolutions en terme d’architecture avec l’apparition des architectures hybrides.
L’idée des lignes de produits logiciels vient de la perception que dans beaucoup de domaines, les applications ne sont pas des systèmes isolés, mais partagent entre elles des besoins, des fonctionnalités et
des propriétés. L’idée générale des lignes de produits logiciels est de profiter de ces points communs pour définir une architecture de base à partir de laquelle de nouvelles applications pourront être construites plus facilement, plus rapidement et avec un meilleur niveau de qualité.
A ce jour, il n’y a pas eu de travaux sur la formalisation des lacs de données, dans la littérature scientifique. Les industriels ont posé la problématique, proposé essentiellement des solutions logicielles mais n’ont jamais abordé la formalisation des lacs de données [10].
Dans le cadre de nos travaux, nous voulons expérimenter une approche ligne de produit et évaluer la pertinence de cette approche pour une formalisation des lacs de données.
Nos attentes autour de cette approche ligne de produit sont donc de :
— proposer une liste de composants minimum à mettre en place pour faire fonctionner un lac de données sans que ce dernier soit transformé en marécage ;
— d’amorcer une démarche de formalisation pour les lacs de données.
Notre objectif dans cette approche ligne de produits est d’arriver à la production d’un feature model (FM) (ou modèle de caractéristiques ).
Les feature models sont des modèles de variabilité [8]. Leur but est de caractériser quels éléments d’une LPL sont communs à tous les produits, lesquels peuvent varier d’un produit à un autre et comment ces éléments peuvent varier. En d’autres termes, ils modélisent les exigences communes et variables dans la LPL. Les FMs sont utilisés comme support pour plusieurs tâches de l’ingénierie des LPLs, principalement pour la représentation d’informations, mais aussi pour définir le périmètre de la LPL, son évolution et sa maintenance, la réalisation d’opérations de conception ou bien la dérivation de produits. La figure 6.1
représente le FM que nous avons obtenu lors de nos travaux.
L’obtention des FMs peuvent permettre d’indiquer le caractère obligatoire ou optionnel (par exemple) de certaines fonctionnalités et donc faciliter la tâche de l’architecte qui pourra ainsi indiquer le caractère obligatoire ou optionnel (par exemple) de certaines fonctionnalités des composants à mettre en oeuvre pour les lacs de données
Afin d’obtenir ce "FM", nous utilisons nos connaissance industrielles, sur plusieurs lacs de données industriels, pour constituer une base de connaissance nécessaire à la formalisation ligne de produit, pour cela un référentiel des fonctionnalités d’un lac de données doit être créé, ce que nous expliquons dans la section suivante.
Figure6.1: Feature Model de la fonctionnalité cataloguer