Contrairement à William Shakespeare et certains experts de l'industrie des entrepôts de données, ce n'est pas la question.
Dans cet article, nous discutons d'un problème rencontré dans les environnements d'entrepôts de données et de data-marts matures. Alors que certaines organisations sont des nouveaux venus dans cet univers, d'autres sont là depuis un certain temps. Et bien que le marché arrive à maturité, la cause de souffrances que provoque les entrepôt des données au sein des organisations IT est liée à son évolution. Récemment, la centralisation a été promue comme le dernier élixir miracle. La centralisation est revendiquée pour transformer les data-marts indépendants et hétérogènes en "or", en réduisant les coûts d'administration et en améliorant la performance. Alors que la centralisation "peut" offrir une certaine efficacité opérationnelle, elle ne traite pas en soi les grandes questions d'intégration et de cohérence.
Dans cet article, nous discutons d'un problème rencontré dans les environnements d'entrepôts de données et de data-marts matures. Alors que certaines organisations sont des nouveaux venus dans cet univers, d'autres sont là depuis un certain temps. Et bien que le marché arrive à maturité, la cause de souffrances que provoque les entrepôt des données au sein des organisations IT est liée à son évolution. Récemment, la centralisation a été promue comme le dernier élixir miracle. La centralisation est revendiquée pour transformer les data-marts indépendants et hétérogènes en "or", en réduisant les coûts d'administration et en améliorant la performance. Alors que la centralisation "peut" offrir une certaine efficacité opérationnelle, elle ne traite pas en soi les grandes questions d'intégration et de cohérence.
Si votre environnement d'entrepôt de données a été développé sans une stratégie globale, vous avez probablement affaire avec de multiples îlots indépendants de données avec les caractéristiques suivantes:
- Plusieurs extractions non coordonnées de la même source opérationnel
- Des variations multiples de la même information avec des conventions de nommage et des règles métier incompatibles
- De multiples analyses illustrant des résultats incompatibles
Certains analystes ont terni la réputation des data-marts en attribuant cette multitude de péchés à l'approche par data-mart. C'est une généralisation grossière qui ne tient pas compte des avantages que de nombreuses organisations ont réalisés avec leurs data-marts correctement architecturés. Les problèmes que nous avons énumérés ci-dessus sont le résultat d'une stratégie inexistante, mal définie, ou mal exécutée et peuvent exister dans n'importe quelle approche architecturale incluant l'entrepôt de données de l'entreprise, les hubs de données, et les data-mart distribués/fédérés.
Nous sommes tous d'accord pour dire que les ensembles isolés de données d'analyse demandent de l'attention. De toute évidence, ils sont inefficaces et incapables de livrer au métier la promesse des entrepôts de données. Les bases de données autonomes peuvent être plus faciles à mettre en œuvre au départ, mais sans une stratégie d'intégration de haut niveau, ce sont des impasses qui continuent à fournir des vues incompatibles de l'organisation. Déplacer simplement ces îlots de données dans une boîte centralisée n'est pas un remède miracle si vous esquiver la vraie question: l'intégration de données et la cohérence. Une approche centralisée qui ne parvient pas à faire face à ces maux est coupable de traiter les symptômes plutôt que la maladie. Bien qu'il soit plus simple de cacher l'intégration et la cohérence sous le tapis en raison des enjeux politiques ou organisationnels qui leur sont associés, ce sont les atouts d'un entrepôt de données pour fournir un vrai avantage métier. C'est un travail difficile, mais l'entreprise en vaut la peine. Dans le langage de modélisation dimensionnelle, cela signifie se concentrer sur l'architecture de bus d'entrepôt de données et des dimensions/faits conformes.
Comme nous l'avons décrit précédemment, l'architecture de bus d'entrepôt de données est un outil pour établir la stratégie globale d'intégration de données de l'entrepôt de données de l'organisation. Elle fournit le cadre pour l'intégration de l'information analytique de votre organisation. Les lignes de la matrice représentent les processus opérationnels de base de l'organisation, alors que les colonnes de la matrice, reflètent les dimensions conformes communes.
Les dimensions conformes sont le moyen pour décrire systématiquement les caractéristiques de base de votre entreprise. Ils sont les points d'intégration entre les différents processus métiers de l'organisation, en veillant à la cohérence sémantique entre les processus. Il peut y avoir des raisons fonctionnelles valables pour des dimensions non conformes. Par exemple, si vous êtes un conglomérat diversifié qui vend des produits uniques à des clients particuliers à travers des canaux uniques. Cependant, pour la plupart des organisations, la clé pour intégrer des données disparates, c'est l'engagement de l'organisation à créer et utiliser des dimensions conformes tout au long de votre architecture d'entrepôt de données, indépendamment du fait que les données soient centralisées ou distribuées physiquement.
Nous vous avons averti plus tôt, la centralisation sans intégration ne peut que jeter de l'huile sur les problèmes préexistants. La direction peut être convaincue que l'achat d'une nouvelle machine pour y loger la multitude de data-marts/entrepôts, fournira une meilleure efficacité opérationnelle. En fonction de la quantité d'argent qu'ils sont prêts à dépenser pour une plate-forme centralisée, cela peut impacter positivement la performance. Toutefois, ces avantages informatiques sont insignifiants par rapport au potentiel que l'entreprise peut tirer de données intégrées. La centralisation sans intégration des données et sans cohérence sémantique va empêcher une organisation de se concentrer sur le vrai nœud du problème. Des données incompatibles continueront à saboter la capacité de prise de décision de l'organisation.
Nous sommes bien conscients que le passage à une architecture de bus d'entrepôt de données demande de la volonté de la part de l'organisation et le recourt à des ressources rares. Personne n'a dit que ce serait facile. En fait, certains analystes de l'industrie affirment que c'est impossible. Cependant, les expériences de nos clients prouvent le contraire.
Nous avons défini les tâches typiques associés à la migration des données disparates vers une architecture de bus avec des dimensions conformes. Bien sûr, puisque l'environnement pré-existant de chaque organisation varie, la liste devrait être ajustés pour refléter votre propre scénario:
- Documenter les data-marts/entrepôts existants dans votre organisation, en notant les chevauchements de données inévitables.
- Procéder à une évaluation de haut niveau des besoins métiers de l'entreprise qui ne sont pas satisfaits.
- Rassembler les intervenants clés pour élaborer une matrice de bus de l'entrepôt de données préliminaire pour votre organisation.
- Identifier une autorité ou un comité de gestion pour définir chaque dimension de manière conforme.
- Concevoir les principales dimensions conformes par l'intégration et/ou la réconciliation d'attributs de différentes dimensions déjà existantes. En réalité, il peut être fatiguant d'arriver à mettre tout le monde d'accord sur tous les attributs, mais ne laissez pas cela mettre le processus en échec. Vous devez commencer à avancer sur le chemin vers l'intégration.
- Obtenir l'accord de l'organisation sur la dimension(s) conforme maître.
- Élaborer un plan par étapes pour évoluer vers la nouvelle dimension(s) conforme.
Définir l'architecture de bus et le déploiement de dimensions conformes entraînera la création d'un entrepôt de données compréhensible pour votre organisation, et qui sera intégré, cohérent, lisible et performant. Vous serez en mesure d'ajouter naturellement des data-marts qui seront intégrés avec les données existantes. Plutôt que de focaliser l'attention sur des incohérences de données et les rapprochements, les capacités de prise de décision de votre organisation seront améliorées grâce à des données intégrées cohérentes.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #36: To be or not to be (centralized)", publié le 5 mai 2002.
Aucun commentaire:
Enregistrer un commentaire