Dans leur volonté de mettre en œuvre les lacs de données, les organisations veulent gagner en agilité et apporter de la flexibilité à la valorisation de leurs données. De ce fait appliquer une démarche d’urbanisation à la conception des lacs de données prend tout son sens.
L’urbanisation permet, selon Servigne [70] de partager une vision commune entre les utilisateurs et le service information mais aussi de :
— faire évoluer le SI pour qu’il soutienne et accompagne de manière efficace les missions de l’organi- sation et leurs transformations,
— réduire les dépenses, — faciliter les évolutions,
— faciliter les changements de stratégies.
L’urbanisation est une discipline d’ingénierie informatique consistant à faire évoluer son système d’infor- mation pour qu’il soutienne et accompagne les missions de l’organisation et leurs transformations. Les avantages attendus de l’urbanisation sont de :
— rendre réactif par rapport aux projets métiers, — aligner le SI avec les objectifs stratégiques,
— gérer la cohérence globale des données et des processus, — Intégrer facilement des innovations technologiques,
— Capitaliser des données et des connaissances sur le système d’information, — diminuer le coût de la maintenance et d’exploitation,
— augmentation de la qualité fonctionnelle,
— améliorer la capacité à améliorer le service rendu, — fiabiliser des données,
— rendre le SI flexible.
Le terme "urbanisation" est utilisé par analogie avec les travaux d’architecture et d’urbanisme dans une ville en comparant une entreprise à une ville et à ses différents quartiers, zones et blocs.
Une telle démarche commence par le recensement et la capitalisation de l’ensemble des composants sur le système d’information de l’entreprise (bases de données, applications, services, etc.), en relation avec leur fonction, afin de les rationaliser et de permettre de valoriser le capital informationnel de l’entreprise. L’objectif d’une démarche d’urbanisation est donc d’aboutir à une structuration du système d’information permettant d’en améliorer ses performances et son évolutivité. Elle permet ainsi de donner les moyens à
Figure4.10: Démarche d’urbanisation du système d’information
l’entreprise de faire évoluer son système d’information en connaissance de cause. La démarche d’urba- nisation recentre le pilotage de l’évolution du système d’information sur la stratégie et les besoins des métiers de l’entreprise ou de l’organisation concernée. Elle est basée sur un modèle en quatre couches successives (voir figure 4.10) :
— l’architecture métier, — l’architecture fonctionnelle, — l’architecture applicative, — l’architecture technique.
Ces différentes architectures s’opèrent de façon séquentielle, dans l’ordre préalablement cité, d’une manière descendante : on commence par l’architecture métier, puis on décline sur cette dernière l’architecture fonctionnelle, qui va servir de référence pour l’architecture applicative. L’architecture technique, quant à elle, vient supporter l’architecture applicative définie. Si la démarche d’urbanisation du SI s’opère de façon descendante, certains allers-retours sont nécessaires notamment entre l’architecture applicative et technique, même si des allers-retours avec les architectures métiers et fonctionnelles ne sont pas exclus. Certaines exigences dites non fonctionnelles décrivent les propriétés que le système doit avoir comme la haute disponibilité, la sécurité, l’évolutivité, etc. Elles peuvent nécessiter, de ce fait, des allers retours entre l’architecture technique et l’architecture applicative.
Par exemple, un besoin de protection des données qui nécessite une isolation ou un cryptage de la donnée, et donc un environnement technique spécifique, peut ne pas être compatible avec un choix de logiciel. L’architecture technique va alors influer sur l’architecture applicative et l’obliger à trouver une
Figure4.11: Architecture fonctionnelle d’un lac de données
autre solution logicielle.
La démarche d’urbanisation du SI consiste dans un premier temps à étudier les différents secteurs fonctionnels d’une entreprise (production, administration, ventes, etc.), afin d’être en mesure d’en réaliser une cartographie, puis d’étudier de la même manière son système d’information.
Le lac de données étant un des composants du système d’information [49], sa conception obéit donc aux mêmes démarches d’architecture que les autres composants du SI notamment celle dite d’urbanisation des systèmes d’information [70].
Le paragraphe suivant détaille les quatre types architectures dans une démarche d’urbanisation.
4.7.1
L’architecture métier
L’architecture métier des lacs de données relève de la problématique d’une organisation autour de la capitalisation et valorisation de ses données pour supporter par exemple sa transformation numérique.
4.7.2
L’architecture fonctionnelle
Le lac de données a pour vocation de centraliser les données (en réponse à la capitalisation) sur un seul "réceptacle" d’entreprise (au sens logique) et de permettre aux outils logiciels de les explorer (en réponse à la valorisation). Le schéma fonctionnel d’un lac de données peut donc être représenté comme sur la figure 4.11.
Sa conception va prendre en compte les besoins fonctionnels auxquels le lac de données doit répondre : — Accessibilité à toutes les sources de données
Figure4.12: Architecture applicative d’un lac de données
— Mise à disposition d’un catalogue des données disponibles
4.7.3
L’architecture applicative
L’architecture applicative est une vue informatique des lacs de données décrits dans la couche fonc- tionnelle. L’objectif est la distribution et la réutilisation des fonctions applicatives [69]. Les structures de données sont également décrites au niveau de l’architecture applicative. Les accès à ces données ainsi que la gestion de leur persistance (sauvegarde, sécurité) sont également décrits à ce niveau. La figure 8 donne un exemple d’architecture applicative de lac de données :
Les composants logiciels qui peuvent être déployés dans une architecture de lacs de données sont par exemple :
— les bases de données relationnelles, noSQL ou système de fichier de type HDFS, pour la partie stockage
— Les patrons d’architecture (framework) pour manipuler les données tels que Map-reduce, Apache Spark.
— Les logiciels de gestion de métadonnées tels que Informatica, IBM Metadata Catalogue
— Les suites intégrées pour les lacs de données, à base de HDFS tels que Cloudera, HortonWorks. — Les logiciels de machine learning tels que Apache Spark, IBM Machine Learning...etc
Nous donnons un exemple de conception d’architecture applicative avec la figure 4.126
. Les couches logicielles y sont mentionnées, les flux de données établis, les sources de données référencées, les structures de données nommées et les interactions entre sources de données décrites.
Au sein de l’architecture applicative, Les couches logicielles sont décrites, les flux de données établis, les sources de données référencées, les structures de données nommées et les interactions entre sources de données décrites. Il y a donc un lien entre les données et les traitements qui est décrit dans l’architecture applicative. Ce lien entre données et traitements a retenu particulièrement notre attention car il soulève des questionnements autour des transferts de données, que nous allons approfondir dans le chapitre5.1.
4.7.4
L’architecture technique
Il convient de rappeler que l’architecture technique décrit l’ensemble des composants matériels sup- portant l’architecture applicative. Ces composants peuvent être :
— des serveurs,
— des postes de travail,
— des équipements de stockage (baie de stockage, SAN, filers...), — des équipements de sauvegarde,
— des équipements réseaux ("routeurs", "firewalls", "switches", "load-balancers", "accélérateurs SSL").
Le choix de ces composants techniques va être orienté par des exigences, dites non fonctionnelles des lacs de données telles que :
— la sécurité, — la disponibilité,
— le passage à l’échelle (scalability), — l’auditabilité,
— la performance, — le volume, — l’intégrité,
6. why use a data-ake. Retrieved from http ://www.jamesserra.com/archive/2015/12/why-use-a-data-lake/ : http ://www.jamesserra.com/archive/2015/12/why-use-a-data-lake/
— la robustesse, — la maintenabilité, — la fiabilité.
Selon l’importance de ces exigences (ou contraintes) non fonctionnelles le choix de l’architecture applicative peut être remis en cause par leur application dans l’architecture technique. Par exemple, dans le cas où le logiciel choisi ne permet pas la montée en capacité attendue ou bien ne tire pas parti des performances de l’architecture technique. Les explorations dans les lacs de données peuvent être très gourmandes en puissance de calcul et nécessiter l’utilisation des traitements massivement parallèles (architecture de type MPP (massively parallel processing), une architecture technique qui permet l’ex- ploitation de cette technologie mais dont le logiciel de manipulation ne sait pas en tirer parti remet en cause sa sélection dans l’architecture applicative. Dans cet exemple, on se trouve face à des contraintes (non liées au métier de l’organisation) qui réduisent le champ des solutions applicatives possibles.
L’influence de ces exigences (ou contraintes non fonctionnelles) reste peu étudiée, que ce soit au niveau de la littérature scientifique ou dans le monde industriel. Cependant la maturité des projets sur les lacs de données reste encore faible, il est à prévoir l’importance croissante de l’étude d’impact de ces contraintes dans la définition des architectures des lacs de données.
Dans le chapitre 5.1, nous explorons l’influence de certaines contraintes techniques sur la remise en cause d’une architecture applicative.
Dans cette section nous avons proposé d’appliquer une démarche d’urbanisation pour la conception de l’architecture des lacs de données. Cette démarche comprend quatre phases de définition d’architecture : métier, fonctionnelle, applicative, technique. Au vu des facteurs pouvant influencer chacune d’entre elles, notamment le passage entre l’architecture applicative et technique, cette démarche peut être un moyen de limiter les possibilités de transformation en marécage des lacs de données ou leur sous-utilisation. Nous pensons que la mise en œuvre de cette démarche d’urbanisation pour les lacs de données peut accélérer la réussite de leur mise en œuvre.
Après avoir appliqué une démarche d’urbanisation à l’architecture des lacs de données, nous détaillons les principaux composants ou fonctions que nous avons identifié comme clés dans leur conception, dans la section suivante.