2.4 Les systèmes décisionnels
2.4.6 L’architecture de référence
Définition d’une architecture de référence :
Une architecture de référence comprend un document ou un ensemble de documents qui contient des recommandations sur les structures et les intégrations de produits et services informatiques dans le but d’établir une solution. L’architecture de référence englobe les meilleures pratiques reconnues dans l’industrie et fait des suggestions sur la méthode de livraison optimale pour telle ou telle technologie.
Les architectes qui conçoivent les systèmes d’information ont à disposition plusieurs architectures de référence selon le domaine qu’ils souhaitent couvrir (système décisionnel, infrastructure, réseaux...etc), leurs préférences, les recommandations de leur société ou bien leurs connaissances et formations. Si les différentes références architectures peuvent différer par leur formalisme, leur représentation graphique, elles ont toutes le même objectif, celui d’aider l’architecte dans sa conception de solution décisionnelle.
Dans ses travaux de recherche Demchenko [14] explore plusieurs architectures de référence dans le cadre des données massives, dont celle d’IBM mais aussi NIST [54] ou Microsoft [52]. Les architectures de référence de NIST ou de Microsoft sont plus récentes et n’existaient pas lors des premiers systèmes décisionnels, notre choix s’est donc porté sur l’architecture de référence des systèmes décisionnel d’IBM [32] afin de pouvoir suivre l’adaptation des architectures de référence à l’évolution des systèmes décisionnels. Pour plus de simplicité nous appelons l’architecture de référence des systèmes décisionnel, l’architecture de référence décisionnelle.
Chaque architecture de référence, possède une certaine sémantique pour décrire ses composants. Dans le paragraphe suivant nous détaillons les composants de l’architecture de référence décisionnelle d’IBM.
L’architecture de référence d’IBM :
Figure2.8: Architecture de référence décisionnelle - IBM
(System Building Block) illustrés dans la figure2.8. La construction de système décisionnel repose sur le modèle d’architecture présenté dans la figure 2.8. Il fournit un cadre permettant de définir précisément les objectifs et le fonctionnement de chacun des composants entrant dans la construction du système décisionnel, et ainsi d’en faciliter la maintenance et les évolutions (prise en compte de nouveaux domaines fonctionnels par exemple ou de nouvelles solutions techniques).
Les composants indiqués sur la figure2.8 peuvent être répartis en trois sous-ensembles : — L’environnement de l’entrepôt de données (SBB 1, 2, 3, 4 et 6) ;
— L’environnement d’analyse (SBB 5) ;
— Les services techniques (SBB 7, 8, 9, 10 et 11). .
L’environnement du système décisionnel (SBB 1, 2, 3, 4, 6) Les objectifs principaux de ce sous-ensemble sont les suivants :
— L’acquisition des données opérationnelles et des données externes (SBB1) : procédures, programmes et outils "middleware"8
permettant d’extraire et de sélectionner les données.
— Les transformations et le «nettoyage» des données (SBB1, SBB3) : procédures, programmes et outils "middleware" permettant de fusionner, contrôler, dériver, agréger les données.
— Le chargement des données dans les différents niveaux de stockage des données (SBB1, SBB3) : procédures, programmes et outils middleware permettant de charger les données selon différents modes possibles : «replace», «append», «update or insert», etc ...
— Le transport et la distribution des données entre les différents niveaux de stockage des données (SBB3) ;
— Le stockage des données proprement dit, les procédures de sauvegardes (SBB2) ;
— Les processus d’archivage –ou d’apurement- des données dépassant la profondeur d’historique choisie (SBB2) ;
— La constitution des métadonnées, qui décrit le contenu de l’entrepôt de données (SBB6) sur le plan technique (administration du data warehouse), comme sur le plan métier (guide utilisateurs). — L’automatisation, le contrôle et le management des flux de données et des processus d’exploitation
de l’ensemble de l’environnement de l’entrepôt de données (SBB1, SBB2, SBB3).
— Les interfaces techniques d’accès aux bases d’informations constituant l’entrepôt de données (SBB4) : middleware et passerelles d’accès ;
— Le transport et la distribution des données entre les différents niveaux de stockage des données (SBB3) ;
— Le stockage des données proprement dit, les procédures de sauvegardes (SBB2) ;
— Les processus d’archivage –ou d’épurement- des données dépassant la profondeur d’historique choi- sie (SBB2) ;
— L’automatisation, le contrôle et le management des flux de données et des processus d’exploitation de l’ensemble de l’environnement de l’entrepôt de données (SBB1, SBB2, SBB3) ;
8. En architecture informatique, un middleware (anglicisme) ou intergiciel est un logiciel tiers qui crée un réseau d’échange d’informations entre différentes applications informatiques. Le réseau est mis en œuvre par l’utilisation d’une même technique d’échange d’informations dans toutes les applications impliquées à l’aide de composants logiciels. Les composants logiciels du middleware assurent la communication entre les applications quels que soient les ordinateurs impliqués et quelles que soient les caractéristiques matérielles et logicielles des réseaux informatiques, des protocoles réseau, des systèmes d’exploitation impliqués.
— Les interfaces techniques d’accès aux bases d’informations constituant le data warehouse (SBB4) : middleware et passerelles d’accès.
Description détaillée : niveaux de stockage (SBB 2)
Le rôle clé de ce sous-ensemble est de constituer, au travers des "éventuels" niveaux de stockage des données, des bases d’informations cohérentes et fonctionnellement fiables permettant aux utilisateurs d’effectuer leurs missions d’analyses sur des sous-ensembles (agrégats) et/ou sur des données détaillées. A chaque niveau peut correspondre un modèle de données spécifique. Selon le contexte et les besoins, les différents niveaux de stockage décrits ci-après seront ou non mis en œuvre (comme décrit dans la section2.4.5).
— Data Marts (magasins de données) ;
— Le Data Warehouse central (entrepôt de données) ; — Le réceptacle ou ODS.
Nous avons dans la section2.4.3donné les définitions de ces termes, dans l’architecture de référence ils sont considérés comme des "niveaux de stockage".
La propagation des données (SBB 3)
La propagation des données (composant SBB 3) est dans la plupart des cas prise en charge par ce que l’on appelle un outil de type ETL (Extract, Transform and Load), d’extraction de transformation et de chargement des données.
Nous utilisons la définition suivante pour un outil ETL :
Le composant d’ETL (Extract, Transform and Load) a pour but la collecte, la préparation et le chargement des données provenant des systèmes de production en vue de leur stockage dans l’entrepôt de données. Ce processus s’exécute périodiquement et s’intègre dans l’exploitation informatique de l’entreprise. Les étapes de ce processus sont en général les suivantes :
— L’Etape de collecte des données nécessaires à partir des systèmes opérationnels et de stockage intermédiaire permet d’affranchir la suite du processus des différents rythmes de vie des fichiers de production, et donc de garantir la cohérence dans le temps des données extraites.
— La préparation des données consiste à trier, fusionner ou au contraire diviser les fichiers de données extraites, à effectuer les opérations de nettoyage, de dédoublonnage d’enregistrements, de trans- formation de formats, de dérivation de valeurs, de concaténation ou d’éclatement des champs de données élémentaires, d’agrégation de valeurs, etc, c’est-à-dire à faire en sorte que les données des systèmes de production deviennent compatibles avec le modèle de données de l’entrepôt.
— L’alimentation consiste à charger les données préparées dans l’entrepôt selon différents modes possibles : remplacement des fichiers cibles, mise à jour des fichiers cibles, ou insertion de nouveaux
enregistrements dans les fichiers cibles ; le choix dépend de besoins fonctionnels comme un souhait d’historisation des données par exemple.
Ce composant peut être réalisé selon diverses méthodes : extractions complètes, extractions incrémen- tales, réplications, et divers moyens : outils d’extraction, outils de réplication, procédures et programmes développés manuellement.
Il y a en général combinaison de méthodes et de moyens.
Des moyens différents peuvent être choisis, d’une part pour l’alimentation de l’entrepôt central, d’autre part pour celle des magasins de données. Selon les sources de données (tables, fichiers, applica- tions..) ou les tables/fichiers cibles, les critères de choix sont les suivants :
— volumes des sources ou cibles ;
— durée acceptable d’indisponibilité des cibles ; — taux de mise à jour des sources ;
— capacité du système de transfert de données (réseau, logiciel de transfert) ; — journalisation des sources ou horodatage des modifications ;
— suppressions logiques ou physiques des enregistrements sources ; — qualité des données sources ;
— cardinalité des appareillages des sources de données (1-1, 1-N, N-N) ; — complexité de l’étape de préparation des données.
L’environnement d’analyse (SBB 5)
Cet environnement est composé des moyens, outils et applications mis à la disposition des utilisateurs pour trouver, comprendre, manipuler et analyser l’information contenue dans le système décisionnel. Différentes classes d’outils ou d’applications sont utilisables :
— Requêtes et reporting ;
— Outils d’analyse multidimensionnelle ; — EIS9 et tableaux de bord ;
— Fouilles de données ou outils de découvertes.
9. L’Executive Information System (EIS) est un mode de représentation des données décisionnelles, au sein d’un système d’information.
L’objectif fondamental de ce sous-ensemble est de fournir aux utilisateurs les outils et applications dont les fonctionnalités correspondent à leurs besoins d’analyse de l’information et à leur métier.
Les services techniques de base (SBB 7, 8, 9, 10, 11) Les services techniques de mise en œuvre de l’environnement du système décisionnel sont les suivants :
— Le système de base de données (SBB 7) : SGBD Relationnel et/ou multidimensionnel. — Le système de sécurité d’accès aux informations (SBB 8).
— Le réseau de connexion (SBB 9).
— Les plates-formes hardware et leurs systèmes d’exploitation (SBB 10).
— L’administration de l’ensemble : gestion des évolutions, des performances, des utilisateurs, des incidents, etc (SBB 11).
L’objectif fondamental de ce sous-ensemble est de permettre au système d’information décisionnel d’être : — Evolutif,
— Disponible et fiable.
Il est intéressant de noter que ce sont ces composants qui prennent de l’importance dans les architectures d’information, en effet la sécurité, la gestion et sauvegarde de gros volumes de données, par exemple, sont de réelles contraintes pour lesquelles l’architecte d’information se doit d’apporter des solutions et donc d’avoir des connaissances, à la fois logicielles mais aussi d’infrastructure informatique. L’utilisation de cette architecture de référence (quelque soit son créateur) est un outil indispensable à l’architecte. Il lui permet de considérer tous les composants entrant dans la conception d’un système décisionnel, sans rien omettre. Selon les besoins fonctionnels qu’il doit satisfaire et les contraintes auxquelles il est confronté, l’architecte peut décider que certains des composants de l’architecture de référence sélectionnée ne seront pas mis en place. La raison doit être explicitée et permet une traçabilité des choix qui ont été pris. L’architecte justifie ses arbitrages au travers d’un document de "décision d’architecture" (architectural décision) qui permet de comprendre ses choix.
L’évolution des systèmes décisionnels entraîne une évolution des architectures d’information qui les supportent et donc des architectures de références. La description détaillée de cette architecture de référence nous sert de repère pour mieux appréhender l’impact de l’évolution des systèmes décisionnels sur le système d’information.
Dans ce chapitre nous avons étudié les systèmes décisionnels du prisme de l’architecture , introduit les principaux composants d’un système décisionnel que sont le réceptacle (ou ODS), l’entrepôt de données (ou Data warehouse) et les magasins de données ( ou Data mart).
Dans le chapitre suivant nous détaillons les facteurs qui ont déclenché l’évolution des architectures des systèmes décisionnels.
L’évolution des systèmes décisionnels
Les systèmes décisionnels n’ont cessé d’évoluer, se démocratiser et de s’adapter ces dernières années. C’est notamment l’explosion des volumes des données émises (voir figure2.1) qui accélère cette évolution des systèmes décisionnels (et qui a retenu notre attention). Les marchés du logiciel et des infrastructures matérielles ont aussi contribué à l’évolution des systèmes décisionnels permettant d’accéder, de traiter, de transformer, de stocker, d’exploiter, de visualiser et d’analyser les données de façon plus rapide, plus simple et plus ouverte au point de vue technologique. Cette révolution technologique a permis de rendre les systèmes décisionnels accessibles à un plus grand nombre d’utilisateurs, accélérant leur démocratisation à toute la population d’une organisation et non plus seulement à des utilisateurs avertis.
Dans ce chapitre nous avons recensé, sous l’influence des données massives, les éléments des systèmes décisionnels sujets à évolution tels que :
— l’évolution des logiciels ; — l’évolution des infrastructures ; — l’évolution des données ; — l’évolution des usages ; — l’évolution de la modélisation. — la technologie Apache Hadoop
Nous allons détailler les évolutions des systèmes décisionnels relatives à ces divers facteurs dans les paragraphes qui suivent.
3.1
L’évolution des logiciels décisionnels
Chaque composant d’un système décisionnel (voir figure2.4) est couvert par une couche ou plusieurs couches logicielles.
Figure3.1: Magic Quadrant Gartner des outils d’intégration- outils E.T.L pour 2018