Trois principes de développement d'entrepôt de données

Gartner estime que près de 70 à 80 % des projets de Business Intelligence nouvellement lancés échouent. Cela est dû à une myriade de raisons, allant du mauvais choix d'outil à un manque de communication entre l'informatique et les parties prenantes de l'entreprise. Ayant mis en œuvre avec succès des projets de BI dans tous les secteurs, j'espère partager mes expériences dans cet article de blog et mettre en évidence les principales raisons de l'échec des projets de Business Intelligence. Cet article présentera des contre-mesures à l'échec basées sur trois principes qui devraient régir la façon dont les entrepôts de données sont construits. Suivre ces concepts d'entrepôt de données devrait vous aider, en tant que développeur d'entrepôt de données, à naviguer dans le parcours de développement en évitant les nids-de-poule courants ou même les gouffres des implémentations BI.

Implémentation de l'entrepôt de données de Business Intelligence

Bien que les critères d'un entrepôt de données décisionnel réussi varient selon le projet, certains minimums sont attendus et requis pour tous les projets. Voici une liste des principaux attributs que l'on trouve généralement dans un entrepôt de données décisionnel performant :

• Valeur : Les projets d'informatique décisionnelle peuvent s'étaler sur plusieurs mois, voire plusieurs années. Cependant, il est important de montrer les avantages d'un entrepôt de données aux parties prenantes de votre entreprise très tôt dans le projet pour assurer un financement et un intérêt continus. Idéalement, les parties prenantes devraient voir une valeur commerciale significative du nouveau système dans les trois premières semaines d'un projet.
• BI en libre-service : l'époque où l'on attendait l'informatique pour répondre aux demandes de données ou effectuer des analyses de données est révolue. Le succès de tout projet de BI se mesure désormais à la mesure dans laquelle il permet aux utilisateurs métier d'extraire eux-mêmes la valeur du système.
• Coût : les projets de BI ont généralement des coûts de mise en œuvre initiaux relativement élevés. Pour contrebalancer et compenser le coût initial élevé, il est important de concevoir des entrepôts avec de faibles coûts de maintenance. Si le client a besoin d'une équipe complète de développeurs BI pour assurer/diagnostiquer les problèmes de qualité des données, apporter des modifications de routine aux modèles de données ou gérer les échecs ETL, le système serait coûteux à budgétiser et risquerait d'être désactivé après un certain temps. .
• Adaptabilité : La capacité de s'adapter à l'évolution des demandes commerciales est cruciale. Il est important de garder à l'esprit le nombre incalculable d'outils de BI disponibles sur le marché et le rythme auquel ils évoluent pour inclure des fonctionnalités et des fonctionnalités supplémentaires. Couplé au fait que les entreprises évoluent continuellement, les exigences pour l'entrepôt changeront; L'adaptabilité nécessite que les entrepôts de données soient conçus pour permettre l'utilisation d'outils de BI alternatifs tels que différents back-ends ou outils de visualisation à l'avenir et qu'ils soient adaptables à des changements souvent imprévus des besoins.

Grâce à mon expérience dans la création de solutions réussies, et peut-être plus important encore, en étant impliqué dans des projets qui ont échoué, je suis arrivé à la conclusion que trois principes clés sont primordiaux pour augmenter la probabilité d'une mise en œuvre réussie d'un système de Business Intelligence. Cependant, avant de les couvrir en détail, commençons par un peu de contexte.

Qu'est-ce qu'un entrepôt de données ?

Avant de se plonger dans différents concepts d'entrepôt de données, il est important de comprendre ce qu'est réellement un entrepôt de données.

Les entrepôts de données sont souvent considérés comme des systèmes de veille économique créés pour répondre aux besoins quotidiens de reporting d'une entité commerciale. Ils n'ont pas les mêmes exigences de performances en temps réel (dans les implémentations standard) que les systèmes de données OLTP, et alors que les systèmes OLTP ne contiendront que les données relatives à un petit sous-ensemble de l'entreprise, les entrepôts de données cherchent à englober toutes les données relatives au affaires .

Les modèles d'entrepôt de données n'offrent des avantages à une entreprise que lorsque l'entrepôt est considéré comme la plaque tournante de «toutes les données» et pas seulement comme un outil grâce auquel vos rapports opérationnels sont produits. Tous les systèmes opérationnels doivent avoir une communication bidirectionnelle avec l'entrepôt de données pour alimenter les données et recevoir des commentaires sur la façon d'améliorer l'efficacité opérationnelle. Tout changement commercial, tel qu'une augmentation des prix ou une réduction de l'offre/des stocks, doit d'abord être prototypé et prévu dans votre environnement d'entrepôt de données afin que votre entreprise puisse prédire et quantifier de manière fiable le résultat. Dans ce contexte, toutes les fonctions de science des données et d'analyse de données seraient centrées autour de l'entrepôt de données.

Un entrepôt de données comporte de nombreux composants, et il ne s'agit pas simplement d'une base de données :

• Une base de données est un support par lequel vous stockez vos données.
• Un entrepôt de données va au-delà pour inclure les outils et les composants nécessaires pour extraire la valeur commerciale de vos données et peut inclure des composants tels que des pipelines d'intégration, des cadres de qualité des données, des outils de visualisation et même des plugins d'apprentissage automatique.

Voici une représentation plus visuelle de la différence entre une base de données et une structure d'entrepôt de base de données. Les bases de données ou les nouveaux magasins de métadonnées de données logiques tels que Hive forment l'étoile centrale du système stellaire d'un entrepôt de données, avec tous les autres composants comme ses planètes tournantes. Cependant, contrairement à un système en étoile, un entrepôt de données peut avoir une ou plusieurs bases de données et ces bases de données doivent être interchangeables avec les nouvelles technologies, comme nous le verrons plus loin dans l'article.

Principe du premier entrepôt de données : la qualité des données règne en maître

Les entrepôts de données ne sont utiles et précieux que dans la mesure où les données qu'ils contiennent sont approuvées par les parties prenantes de l'entreprise. Pour garantir cela, des cadres qui capturent et corrigent automatiquement (si possible) les problèmes de qualité des données doivent être créés. Le nettoyage des données doit faire partie du processus d'intégration des données avec des audits de données réguliers ou un profilage des données sont effectués pour identifier tout problème de données. Pendant que ces mesures proactives sont mises en œuvre, vous devez également envisager des mesures réactives lorsque de mauvaises données passent ces portes et sont signalées par l'utilisateur.

Pour garantir la confiance des utilisateurs dans le système d'entrepôt de données, toute mauvaise donnée mise en évidence par les utilisateurs professionnels doit être examinée en priorité. Pour faciliter ces efforts, des cadres de lignage des données et de contrôle des données doivent être intégrés à la plate-forme pour garantir que tout problème de données puisse être identifié et résolu rapidement par le personnel de support. La plupart des plates-formes d'intégration de données intègrent un certain degré de solutions de qualité des données, telles que DQS dans MS SQL Server ou IDQ dans Informatica.

Tirez parti de ces plates-formes intégrées si vous utilisez un outil commercial dans vos pipelines d'intégration de données, mais en plus ou autrement, assurez-vous de développer les mécanismes qui vous aideraient à maintenir la qualité de vos données. Par exemple, la plupart des outils d'intégration de données manquent de bonnes fonctionnalités pour suivre le lignage des données. Pour surmonter cette limitation, une structure de contrôle par lots personnalisée peut être créée à l'aide d'une série de tables de contrôle pour suivre chaque flux de données qui se produit dans le système.

Il est très difficile de regagner la confiance des parties prenantes de votre entreprise si elles rencontrent une mauvaise qualité au sein de votre plate-forme, donc l'investissement initial dans les cadres de qualité des données devrait en valoir le coût.

Principe du deuxième entrepôt de données : inverser le triangle

Cette figure illustre la répartition des efforts dans la mise en œuvre et l'utilisation de la plupart des entrepôts de données.

La plupart des efforts sont investis dans la construction et la maintenance de l'entrepôt, tandis que la valeur ajoutée d'avoir un entrepôt pour l'analyse commerciale représente une bien plus petite partie de l'effort. C'est une autre raison pour laquelle les projets de business intelligence échouent souvent. Parfois, il faut trop de temps dans le cycle de projet pour montrer une valeur significative au client, et lorsque le système est enfin en place, il faut encore beaucoup d'efforts informatiques pour en tirer une valeur commerciale. Comme nous l'avons dit dans l'introduction, la conception et le déploiement de systèmes d'intelligence d'affaires peuvent être un processus coûteux et long. Par conséquent, les parties prenantes s'attendront à juste titre à commencer rapidement à récolter la valeur ajoutée de leurs efforts d'intelligence d'affaires et d'entreposage de données. Si aucune valeur ajoutée ne se matérialise, ou si les résultats arrivent tout simplement trop tard pour avoir une valeur réelle, rien ne les empêche de débrancher la prise.

Le deuxième principe du développement d'un entrepôt de données consiste à retourner le triangle comme illustré ici.

Votre choix d'outils d'informatique décisionnelle et les cadres que vous mettez en place doivent garantir qu'une plus grande partie des efforts déployés dans l'entrepôt est destinée à extraire la valeur commerciale plutôt qu'à la créer et à la maintenir. Cela garantira des niveaux élevés d'engagement de la part des parties prenantes de votre entreprise, car elles verront immédiatement la valeur d'investir dans le projet. Plus important encore, vous permettez à l'entreprise d'être autonome dans l'extraction de valeur sans dépendre autant de l'informatique.

Vous pouvez adhérer à ce principe en suivant des méthodologies de développement incrémentiel lors de la construction de l'entrepôt pour vous assurer de fournir la fonctionnalité de production aussi rapidement que possible. Suivre la stratégie de data mart de Kimball ou les méthodologies de conception d'entrepôt de données Data Vault de Linstedt vous aidera à développer des systèmes qui se construisent progressivement tout en tenant compte des changements en douceur. Utilisez une couche sémantique dans votre plateforme telle qu'un cube MS SSAS ou même un univers Business Objects pour fournir une interface métier facile à comprendre à vos données. Dans le premier cas, vous fournirez également aux utilisateurs un mécanisme simple pour interroger les données d'Excel, qui reste l'outil d'analyse de données le plus populaire.

L'intégration d'outils de BI qui défendent la BI en libre-service, tels que Tableau ou PowerBI, ne fera que contribuer à améliorer l'engagement des utilisateurs, car l'interface pour interroger les données est désormais considérablement simplifiée par opposition à l'écriture SQL.

Le stockage des données source dans un lac de données avant de remplir une base de données aidera à exposer les données source aux utilisateurs très tôt dans le processus d'intégration. Au moins les utilisateurs avancés tels que les business quants pourront désormais digérer les données source (via les fichiers bruts) en connectant des outils tels que Hive/Impala au-dessus des fichiers. Cela aidera à réduire le temps nécessaire à l'entreprise pour analyser un nouveau point de données de semaines à jours ou même heures.

Troisième principe d'entrepôt de base de données : Plug and Play

Les données sont sur le point de devenir l'équivalent numérique du pétrole. Ces dernières années, nous avons assisté à une explosion du nombre d'outils pouvant être utilisés dans le cadre d'une plate-forme d'entrepôt de données et du taux d'innovation. En tête de liste se trouvent la myriade d'outils de visualisation disponibles actuellement, avec des options avancées pour les back-ends juste derrière. Compte tenu de cet environnement et de la propension des exigences commerciales à changer constamment, il est important de garder à l'esprit que vous devrez échanger des composants de votre pile technologique ou même en introduire/supprimer d'autres avec le temps, en fonction des changements commerciaux et technologiques.

D'après mon expérience personnelle, il serait heureux qu'une plate-forme puisse durer 12 mois sans changement significatif. Un effort raisonnable est inévitable dans ces situations; cependant, il devrait toujours être possible de changer de technologie ou de conception, et votre plate-forme devrait être conçue pour répondre à ce besoin éventuel. Si le coût de migration d'un entrepôt est trop élevé, l'entreprise pourrait simplement décider que le coût n'est pas justifié et abandonner ce que vous avez construit au lieu de chercher à migrer la solution existante vers de nouveaux outils.

Construire un système qui répondrait à tous les besoins futurs imaginables est impossible. Par conséquent, un certain niveau d'appréciation que tout ce que vous concevez et construisez maintenant pourrait être remplacé avec le temps est nécessaire lors de la construction d'entrepôts de données. À cette fin, je préconiserais l'utilisation d'outils et de conceptions génériques dans la mesure du possible plutôt que de coupler étroitement votre plate-forme aux outils sur lesquels elle s'exécute. Bien sûr, cela doit être fait après une planification et une réflexion minutieuses, car la puissance de nombreux outils, en particulier les bases de données, réside dans leur individualité et leur complémentarité.

Par exemple, les performances ETL sont considérablement améliorées lors de l'utilisation de procédures stockées dans une base de données pour créer de nouvelles données d'analyse commerciale, par opposition à l'extraction et au traitement des données en dehors de la base de données à l'aide de Python ou SSIS. En ce qui concerne la couche de création de rapports, les outils de visualisation offriraient certaines fonctionnalités qui ne sont pas facilement disponibles dans d'autres, par exemple, Power BI prend en charge les requêtes MDX personnalisées, mais pas Tableau. Mon but n'est pas de préconiser l'abandon des procédures stockées ou l'évitement des cubes SSAS ou Tableau dans vos systèmes. Mon intention est simplement de promouvoir l'importance d'être conscient dans la justification de toute décision de coupler étroitement votre plate-forme à ses outils.

Un autre gouffre potentiel se trouve dans la couche d'intégration. Il est très facile d'utiliser un outil comme SSIS pour l'intégration de vos données en raison de ses capacités de débogage ou de sa facilité d'utilisation avec la plate-forme SQL Server. Cependant, la migration de centaines de packages SSIS vers un autre outil deviendrait un projet très coûteux. Dans les cas où vous faites principalement "EL", cherchez à utiliser un outil générique pour effectuer votre traitement. L'utilisation d'un langage de programmation comme Python ou Java pour écrire un chargeur générique pour charger votre couche intermédiaire vous aidera à réduire les packages SSIS individuels dont vous auriez eu besoin autrement. Cette approche permet non seulement de réduire les coûts de maintenance et de migration future, mais également d'automatiser davantage d'aspects du processus d'intégration des données sans avoir à écrire de nouveaux packages individuels (en lien avec le principe 2).

Dans tous ces cas, vous devez décider d'un compromis pratique entre les avantages immédiats et les coûts de migration futurs pour vous assurer que l'entrepôt ne soit pas mis au rebut parce qu'il ne peut pas gérer le changement ou parce que le changement aurait nécessité trop de temps, effort ou investissement.

Emballer

Il existe de nombreuses raisons pour lesquelles un certain système de Business Intelligence peut échouer, et il existe également des oublis courants qui peuvent conduire à un échec éventuel. Le paysage technologique en constante évolution, le budget limité pour les systèmes de données en raison d'une priorité secondaire mal conçue aux systèmes opérationnels, et la complexité et la difficulté de travailler avec des données signifient qu'un examen attentif non seulement des objectifs immédiats mais aussi des plans futurs doit avoir lieu lors de la conception et construire les composants d'un entrepôt de données.

Les principes fondamentaux de l'entreposage de données décrits dans cet article sont destinés à vous aider à prendre en compte ces considérations importantes. Bien sûr, la prise en compte de ces principes ne garantit pas le succès, mais ils vous aideront certainement à éviter l'échec.