Editions ENI Livres | Vidéos | e-Formations
Gouverner les datamarts
Introduction
La gouvernance est un aspect important dans toute application ou tout système informatique collectif.
La gouvernance des datamarts est l’application de l’autorité sur les datamarts : données, mais aussi mesures et plus généralement architecture. C’est davantage nécessaire pour les datamarts, non seulement parce que cela concerne les données cruciales au cœur de l’organisation, mais aussi parce que Microsoft positionne les datamarts comme un outil métier en libre-service.
Le premier point suggère qu’on dispose d’une source unique de vérité sur les données : des états ou des calculs divergents entre datamarts ou entre datamart et logiciels internes seraient dramatiques. Le second suggère que là où n’importe quel collaborateur peut piocher n’importe quelle infomation dans cet entrepôt de données métier, il va falloir instituer des règles de conduite à tous les étages du processus et attribuer des rôles. À défaut, le dispositif va grossir, le nombre de mesures et d’espaces de travail va se multiplier, le nombre de tables va exploser, sans contrôle facile sur les modèles de données et sans garantie, ni de véracité ni de fonctionnement ni de sécurité de l’information.
Pour agir et permettre au modèle de données de pouvoir être maîtrisé, nous...
Le rôle de l’IT et du pôle Data
Dans un entrepôt de données sur site - OnPremise, le rôle de l’IT est souvent technique comme s’assurer par exemple que l’infrastructure et les outils sont anticipés et dimensionnés pour une bonne performance dans des conditions économiques acceptables.
Avec les volets défensifs et offensifs de la gouvernance, et une architecture d’entrepôt multiple de données métier cloud comme les datamarts, le rôle de l’IT va être tout autre : un rôle de pilote de projet d’entreprise, et plus précisément un rôle de gestion de programmes, avec un cadrage stratégique d’architecture commune. Il s’agit de fournir une gouvernance défensive et, en même temps, répondre aux besoins des différents métiers, voire anticiper de futurs besoins qui n’ont pas été formalisés. La gestion de programme va permettre de gérer un plan d’action et un budget d’ensemble pour des familles de projets BI (défensif et offensif par exemple).
C’est l’IT et son éventuel pôle Data qui érigeront les règles communes, encadrant une série de projets que sont les datamarts.
Par ailleurs, l’IT discutera et négociera avec l’éditeur et les utilisateurs...
Les rôles à prévoir pour les datamarts
Plusieurs profils sont à couvrir, voici les grandes lignes des rôles et de leur responsabilité.
Architecte Data
-
garant des modèles de données transverses et métier ;
-
fournisseur des règles autour des datamarts ;
-
concepteur des groupes de sécurité pour Power BI à destination des administrateurs Azure Entra ID ;
-
coordinateur de la conformité des données ;
-
met en place ou fait mettre en place les espaces de travail Premium transverses et DG ;
-
gère la stratégie en amont et en aval entre ce qu’on place à la source dans le cloud et ce qu’on consomme in fine ;
-
gère la stratégie générale des droits RLS société et externes.
Acheteur de licence et contact Editeur
-
évalue les besoins globaux en licence pour optimiser la formule d’achat ;
-
achète les licences BI.
Propriétaire de datamart
-
ajoute ou modifie une source de données dans le datamart ;
-
responsable des évolutions des sources de son datamart ;
-
responsable de la conformité des données de son datamart.
Direction générale
-
décideur en comité de direction BI.
Manager des Data Métier
-
encadre les propriétaires de datamarts ;
-
supervise la gouvernance défensive (conformité) ;...
Instituer des règles de conduite
Les règles de conduite peuvent varier en fonction de la taille des organisations, des moyens financiers de l’IT et de la stratégie Data de l’entreprise, défensive et offensive. En tous cas, il faut rédiger des règles pour les différents rôles décrits ci-dessus à destination des prestataires et des collaborateurs.
1. Règles d’architecture
L’architecture cible doit être décrite dans un dossier d’architecture technique (DAT). Ce DAT doit préciser les couches et le modèle de données attendu, les sources de données autorisées, les ports à ouvrir et les règles de pare-feu à établir dans Azure ou équivalent.
La méthode d’authentification aux sources de données y sera précisée.
2. Règles d’attribution des licences
Le but est de servir les besoins légitimes. Plus on sera restrictif sur les licences Premium plus le dispositif sera contourné par des solutions locales comme les tableurs ou Power BI desktop.
Pour gérer le budget, il faut centraliser l’attribution des licences en distinguant remplacement de licence existante et nouvelle licence. Il faudra indiquer le rôle de chacun en face du nom de la personne et de la licence, de façon à prévoir le(s) groupe(s) de sécurité...
Les processus à prévoir
1. Processus de gestion de projet BI agile
Si les exigences sont difficilement formalisables dans un cahier des charges complet, relu et validé par un manager, s’il y a une certaine urgence à livrer certains points essentiels et si la maîtrise d’ouvrage et la maîtrise d’œuvre coopèrent facilement, une méthode agile peut être considérée.
Un binôme maître d’ouvrage (MOA)/maître d’œuvre est constitué, si possible déplacé temporairement dans le même bureau pour un maximum de proximité et idéalement en « pétale » c’est-à-dire à proximité de toutes les personnes impliquées sur le processus, pour gagner du temps.
Un propriétaire de datamart et/ou une équipe de développement se mettent en place ainsi qu’un responsable de projet ou Scrum Master, qui va cadencer la coopération et la production de façon itérative et régulière.
La méthode SCRUM avec ses réunions courtes quotidiennes repose sur une équipe de développement, elle ne peut se mettre en place avec un seul développeur. Par contre, la méthode agile peut être adaptée pour des équipes réduites, selon le protocole suivant.
Un cadre proche du terrain (du business et des développeurs) joue le rôle d’organisateur (maître Scrum - Scrum Master).
Un prestataire ou un consultant interne peut jouer le rôle de de chef de produit (Product Owner) et reformuler le besoin sous forme d’une histoire d’attente utilisateur - user story située dans son contexte métier sous la forme que vous verrez page suivante. Une livraison d’une maquette visuelle se fait...
Pipelines de déploiement métier
1. Mettre en place un pipeline de déploiement
Les pipelines Power BI savent gérer trois espaces de travail distincts :
-
développement (espace déjà existant)
-
test
-
production
La fonction Pipeline de déploiement est prévue pour fonctionner avec les datamarts et tout le contenu sous-jacent. L’avantage des datamarts est que les mesures sont prises en charge en plus des tables et du modèle de données. Cette fonction supporte pleinement les applications Power BI.
La fonction Pipeline de déploiement est visible dans le menu vertical de Power BI. Elle n’est accessible qu’à ceux qui ont la licence Premium par utilisateur ou Premium par capacité : ce sont les mêmes prérequis que ceux du datamart.
Vous êtes sur le portail Power BI,
cliquez sur le volet rapide de gauche Pipelines de déploiement 
pour créer un pipeline.
Cliquez sur le bouton Créer un pipeline, un nom du pipeline et une description vous seront demandés. Ce nom pourra être modifié ultérieurement, sans impact sur le processus.
Une fenêtre vous demande de confirmer le nom des étapes et propose par défaut Development, Test et Production ainsi qu’un bouton Ajouter si l’on voulait ajouter PréProduction entre 2 et 3, par exemple. Contentez-vous de renommer la première étape Développement (qu’on aurait pu aussi appeler Usine) et cliquez sur le bouton Créer.
Important : pour créer un pipeline avec un datamart, voici les conditions requises qui permettent à l’espace d’être assignable à un pipeline :
Il faut être propriétaire du datamart et administrateur de l’espace de travail.
Il faut un espace de travail Premium (PPU ou PPC plus licence Pro ou Essai Fabric).
Cet espace de travail, au moment de sa création, ne doit pas être attaché à un modèle d’application : la case Développer une application modèle doit être décochée dans les paramètres avancés de l’espace de travail.
L’espace de travail n’a pas d’étiquette de sensibilité.
L’espace de travail n’est pas déjà...
