Bataille d’experts – le retour : Savoir trancher un sujet technique lorsqu’on est DSI

Dans un précédent article je vous donnais quelques conseils pour fournir les bons arguments à son DSI afin qu’il tranche sur des sujets techniques. J’inverse les rôles aujourd’hui, pour m’adresser à nos CIO, nos CTO, ou encore nos DSI / RSI, en somme à nos patrons de l’informatique.

Et là le conseil va être beaucoup plus simple : si vous en êtes à trancher des sujets techniques, c’est que vous avez raté le coche dans votre organisation. Vous avez un background technique ? C’est une très bonne chose. Mais si vous êtes le chef il faut bien se dire que ce n’est pas grâce à votre compétence technique, soyons honnêtes. Ne croyez donc pas que votre avis vaut mieux que celui de vos troupes, sur le terrain, qui elles développent encore plus de 6 heures par jour.

Un DSI n’est pas nommé pour répondre lui même au débat technique. Il est nommé pour constituer une équipe de confiance, capable de le faire pour lui. Le job d’un exécutif c’est plein de choses passionnantes, mais ça n’inclut pas de prendre des décisions opérationnelles.

Donc si un sujet technique est escaladé jusqu’à vous (quel ETL utiliser pour le prochain projet, quelle modélisation choisir pour son datawarehouse…), sachez reconnaître le problème organisationnel sous-jacent, et réagir en fonction.

Pour ça, voici les grandes étapes à suivre :

  • D’abord, constituez-vous un état-major d’experts en qui vous avez confiance. Qu’ils soient internes (c’est mieux) ou externes, identifiez des individus qui savent vous dire non, qui savent vous dire quand vos décisions sont mauvaises, quelle que soit leur place dans la hiérarchie. N’hésitez d’ailleurs pas à tester la capacité à la franchise de cet état-major de temps en temps : demandez des avis externes, croisez le retour de plusieurs personnes, posez des questions théoriques douloureuses dont vous savez les réponses, auditez le résultat de vos audits… Car en effet, la confiance n’exclut pas le contrôle.
  • Une fois ces référents identifiés, appuyez-vous sur eux pour vous conseiller dans la décision. Non pas pour vous expliquer le sujet technique, mais plutôt pour vous clarifier les intérêts et conflits d’intérêts de chacun, et comprendre pourquoi votre organisation n’a pas su répondre au problème. Vous n’êtes pas là pour trancher le choix de l’éditeur de l’ETL, vous êtes là pour comprendre pourquoi votre architecte décisionnel n’a pas réussi à faire appliquer ses recommandations.
  • Enfin, n’ayez pas peur de prendre et d’assumer des décisions qui ne font pas de compromis. Si un sujet escalade jusqu’à vous, il sera forcément chargé émotionnellement et votre décision fera obligatoirement des malheureux. N’essayez donc pas de satisfaire tout le monde, vous n’arriverez qu’à des demi-mesures qui feront trainer la situation dans le temps. Mieux vaut une vraie tristesse, qu’une fausse joie (dixit les experts). Soit les recommandations de votre architecte sont mauvaises, alors il vous faudra l’accompagner dans la mise à jour de sa compétence ; soit l’équipe projet est trop arrogante pour reconnaître la sagesse de l’architecte, et un effort de management doit être fait pour remettre les choses à plat.

Le résultat c’est que vous ne choisissez pas à la place de vos équipes, vous corrigez votre organisation pour qu’elle réponde elle-même à la question, et aux prochaines du même acabit.

Si sur le papier ça a l’air simple, il est clair que dans la vie de tous les jours c’est plus complexe. On a tous une tendance à vouloir jouer les superhéros, à sauter dans l’action et sauver les situations. Une caractéristique d’ailleurs encore plus présente chez les individus ayant réussi à se hisser dans les fonctions exécutives. Mais il faut savoir déléguer les décisions au bon niveau de responsabilité (le terrain), et respecter ces décisions. Pour un collaborateur, il n’y a rien de pire qu’un désaveu de la part de sa hiérarchie, surtout si de son point de vue il faisait le nécessaire pour protéger l’entreprise. Il est également important d’éviter le micro-management, car intervenir sur toutes les décisions c’est encourager vos équipes à vous masquer les problèmes afin de conserver leur autonomie.

Enfin, et je conclue peut-être avec le message le plus important de cet article : en cas de problème ne blâmez pas une personne, blâmez plutôt les processus et/ou l’organisation. Cette règle est à la base du Lean IT, dont un des piliers est le respect de la personne. Elle est essentielle au bon fonctionnement du groupe. Au-delà de la considération à avoir pour son prochain, c’est également un excellent coup de pouce à la transparence, puisque l’apparition d’un défaut dans l’organisation sera l’occasion d’améliorer les conditions de travail des équipes.

Décisionnel Agile : Réaliser son Datawarehouse en itérations agiles

Ça y est, vous avez bien intégré les valeurs de l’Agilité et vous vous êtes décidés pour construire votre datawarehouse en utilisant une méthode Agile. Excellent !

Déjà vous allez devoir convaincre les gens autour de vous que c’est possible. En effet la réaction naturelle dès qu’on parle de construire une solution décisionnelle en mode Agile c’est l’incrédulité. Autant pour la partie reporting personne ne voit vraiment de problème, souvent c’est même le contraire, autant côté back end – l’ETL et le datawarehouse à proprement parler – les reproches fusent :

  • Les alimentations sont lourdes et compliquées, on ne peut pas les réaliser rapidement
  • L’entrepôt est monolithique, vu les volumes on ne pourra pas le faire évoluer facilement

Pourtant, dès 1998 Kimball (notre père à tous 😉 ) publie les 3 concepts de base (PDF) du cycle de vie du datawarehouse :

  1. Mettre l’accent sur l’ajout de valeur métier pour toute l’entreprise
  2. Délivrer les données à travers les dimensions
  3. Développer une solution de façon itérative, livrer des incréments compréhensibles, plutôt que de travailler en mode big bang.

Vous avez vu la 3 ? Et la 1 ? Quel talent ce Ralph, en 1998 il faisait déjà de l’Agilité 🙂

Si le pape du datawarehousing dit qu’il faut le faire – notez qu’il ne dit pas qu’on devrait le faire, mais qu’il faut le faire – c’est bien que c’est faisable non ! Le tout c’est de savoir comment.

Dilbert.com

Là encore on écoute Monsieur Kimball, qui applique parfaitement l’Agilité et qui nous donne le mantra du découpage (Slide 19) : « Meaningful but Manageable » – « Porteur de sens mais Gérable ».

Point de vue implémentation l’objectif devient d’identifier la plus petite fonctionnalité qu’on puisse livrer à l’utilisateur qui porte encore du sens par rapport à ses besoins. Si on suit la méthodologie Kimball, cela veut dire qu’on va se concentrer sur un seul processus métier à livrer à chaque fois. Autrement dit, une seule table de fait (ou une poignée de tables) et les quelques dimensions qui lui vont bien. Soit on livre ces tables et on les rend accessibles en SQL, donc exploitable par l’utilisateur, soit on les accompagne d’un petit rapport SSRS ou un petit cube SSAS tout simple généré en une demi-journée. Là on a une itération courte et qui apporte de la valeur.

Oui mais même une table de fait et 4 dimensions ça peut prendre bien plus que 2 semaines à fabriquer, recetter et livrer ! Si on a des problèmes de qualité de données, si on fait du multi-source…

Ok. Alors on va se concentrer sur une seule source de données (une seule instance, un seul applicatif source…), sur un seul périmètre de données dans une même source (la France parmi le monde…), pour réduire le périmètre métier de la fonctionnalité, tout en maintenant son intérêt pour l’utilisateur, jusqu’à obtenir quelque chose d’unitaire et de livrable.

Par exemple, dans le cas d’une solution décisionnelle RH, on commencerait par importer uniquement les données actuelles, sans reprise d’historique. On récupèrerait uniquement les effectifs, uniquement d’une source choisie et d’une seule instance de cette source. On ne ferait de la qualité de données que de bas niveau (unicité, validation des types…) en rejettant tout ce qui n’est pas conforme. On ne ferait que peu de transcodage (uniformisation des critères type sexe, situation familiale…). Et on arriverait à générer un premier rapport simple mais précis sur la situation actuelle des effectifs sur ce premier périmètre. A partir de là on pourra itérer pour améliorer la couverture et/ou la qualité de la solution, en fonction des priorités arbitrées par l’utilisateur. Parfait ! 😉

Ce qui est important, c’est qu’il faut découper son projet selon l’axe métier, le périmètre fonctionnel, et pas selon l’axe technologique. Il faut faire du bout en bout (de l’ETL au reporting) en traitant un sujet simple, plutôt que de faire tout l’ETL, avant de passer à une autre brique :

Découper son datawarehouse en itération agiles

Il faut penser ses fonctionnalités comme les vertes, et pas comme les rouges!

Au départ cela peut paraître difficile, voir même contre-productif. Et ça le sera d’ailleurs certainement au début. Mais cela mène à une plus grande expertise, une plus grande maîtrise de la solution de bout en bout et à une bien meilleure satisfaction client. En 2 semaines on va pouvoir lui générer un premier rapport qu’il pourra effectivement employer pour améliorer son quotidien.

Evidemment il existe des cas particuliers. Si vous êtes à fond dans la qualité de données, on peut considérer qu’une table de transcodage propre, avec une petite interface d’administration en ASP.NET, c’est une fonctionnalité qui a de la valeur pour l’utilisateur. Dans ce cas on n’est pas obligé d’aller jusqu’au modèle dimensionnel pour avoir de la valeur.

Et une fois que votre datawarehouse sera monté et stable, vous pourrez faire des itérations facilement au niveau de SSAS, SSRS ou tout autre outil de haut niveau, là on retombe sur quelque chose de plus facile à gérer.

Un conseil important au niveau de l’ETL : perdez le réflexe de vouloir importer tous les champs de tous les fichiers ou tables sources. Il faut savoir minimiser la largeur (le nombre de colonnes) à importer après la collecte (Extract d’ETL) dans le phase de nettoyage/transformation (Transform d’ETL). Chaque colonne a un coup de maintenance, que vous l’utilisiez ou pas, elle a un impact sur les performances (largeur du buffer), sur la maintenabilité (les bugs qu’elle peut générer) et dans l’évolutivité (lourdeur des métadonnées à mettre à jour). Il faut savoir rester lean de bout en bout, même si nos instincts d’écureuils de la forêt nous encouragent à stocker toutes les noisettes qu’on peut trouver !

Une noisette pour les diriger toutes!

Si vous voulez stocker ces informations parce qu’elles sont périssables, utilisez ce type d’architecture comportant une base d’archivage des données au format source. Vous pourrez l’utiliser si besoin de reprise d’historique :

Archivage des données périssables

Enfin, tout cycle de développement Agile commence par une phase d’initialisation : rencontre des intervenants, découverte des premiers besoins, installation des produits, prototypage… qui ne sont pas à proprement parler des itérations. C’est normal, pas d’inquiétudes à avoir, la transition vers les itérations se fera naturellement quand on vous demandera la première date de livraison 🙂

Voilà, on a fait le tour de l’itération décisionnelle, n’hésitez pas à poser vos questions dans les commentaires. Mais notez tout de même que cela ne suffit pas pour avoir un vrai décisionnel Agile. La brique essentielle qu’il manque encore c’est le cycle d’amélioration continu, tant au niveau de l’équipe que du datawarehouse. Ça c’est un sujet pour un autre jour 😉

Projet décisionnel : choisir la bonne technologie dans l’offre Microsoft SQL Server

Je vous parlais tantôt de gestion de projet décisionnel, et en passant je vous disais que le choix d’une technologie pour un projet décisionnel n’était pas une décision anodine. Je voulais vous en dire plus, c’est le moment !

Rappelons d’abord que les projets décisionnels répondent à 3 besoins (cf ma session aux Journées SQL Server pour ceux qui prennent le wagon en route) :

Le décisionnel : Besoin Historisation

Historisation. Les bases de données des applications de l’entreprise sont régulièrement purgées (commandes livrées = commandes effacées du système). Pourtant ces informations sont importantes, il faut les conserver.

Le décisionnel : Besoin Centralisation

Centralisation. Les applications de l’entreprise sont des silos indépendants. Pourtant être capable de croiser ces domaines pour comprendre, par exemple, l’impact des actes commerciaux (CRM) sur les ventes (Logiciel de caisse) est indispensable.

Le décisionnel : Besoin Analyse

Analyse. Mon entreprise est un organisme qui vit dans un environnement. Mes applications (CRM, RH, ERP…) sont des capteurs qui génèrent des informations, des stimuli locaux de ce qu’il se passe dans chaque processus métier. J’aimerai analyser ces informations pour obtenir une image globale et comprendre le monde autour de moi.

Dans un projet décisionnel, on répond à ces 3 besoins à travers 5 fonctions :

  1. L’extraction : à la charge du décisionnel d’aller chercher les données qu’il souhaite
  2. Le nettoyage : ces données doivent être uniformisées et transformées pour être exploitables
  3. Le stockage : on archive les données pour garantir leur pérennité, on les historise pour être capable de comparer le passé au présent
  4. L’analyse : on modélise et interprète les données  pour en tirer un sens
  5. Le reporting : on apporte le résultat des analyses et des requêtes aux utilisateurs

Le décisionnel : 3 Besoins 5 Fonctions
Dans le monde Microsoft, ces fonctions sont assurées par les produits suivants :

Le décisionnel : Produits Microsoft

Ma liste est limitée, il existe d’autres produits (ReportBuilder… et tous les nouveaux sur le Cloud dont Data Explorer) mais on a là les piliers de l’offre.

D’abord on peut se poser la question du pourquoi Microsoft et pas un autre éditeur? Ma réponse c’est que c’est la gamme de produits avec le rapport efficacité / facilité d’usage le plus élevé, et de loin, sur le marché à l’heure actuelle. Notez que ce n’est pas forcément le plus performant sur chaque problématique (Informatica sur l’ETL en temps réel par exemple), ni forcément le plus facile d’utilisation (SSRS…), mais le plus complet, le plus équilibré, celui qui flatte le plus le développeur et l’utilisateur.

On en revient au tableau, pour noter qu’il n’existe au final que 3 domaines ou un choix de technologie existe.

Côté Archivage (je stocke mes données au format source, pour répondre à un besoin d’audit et/ou de sécurité), on stocke directement les fichiers sources sur le disque, ou les tables sans transformation dans la base. Rien de très intéressant par ici. Au passage : attention à ne pas systématiquement utiliser ces données pour vider et régénérer complétement le DWH à tous les chargements. Cette pratique est une bonne pratique uniquement dans certains cas d’utilisation mais pas dans tous. Voir les 2 excellents documents de Marco Russo et Alberto Ferrari sur le sujet, spécifiquement le chapitre « Classification of BI solutions« , dans le PDF introduction.

Côté Reporting, le choix se fait en fonction du type d’utilisation souhaité. Des analyses à la demande ? Excel et les TCD. Du reporting de masse ? SSRS. Du « collaboratif » ? SharePoint et ses Services. Un tableau de bord ? PerformancePoi… non je blague, n’importe quoi d’autre 😉

Le problème avec l’offre jusqu’à aujourd’hui, c’était que le choix de solution de reporting impactait le choix du moteur d’analyse. En effet les tableaux croisés dynamiques d’Excel et les services SharePoint étaient obligatoirement branchés sur du SSAS classique (maintenent BISM-Multidimensional). Heureusement c’est une contrainte qui saute, ou plutôt qui évolue, avec SQL Server 2012 et la refonte de SSAS. Certes cette refonte introduit de nouvelles contraintes (PowerView sur du Tabular), mais elle libère Excel et les TCD.

Ce qui fait que le choix va se faire beaucoup plus librement sur le moteur d’analyse, entre :

  • Monter un datamart répondant à un besoin spécifique directement dans la base SQL
  • Construire un cube : SSAS – BISM Multidimensional
  • Construire un modèle tabulaire : SSAS – BISM Tabular

Et avec Excel 2010 (plus PowerPivot dans certains cas) on peut accéder facilement à ces 3 sources et offrir des tableaux croisés dynamiques bien velus à nos utilisateurs, indépendamment du moteur d’analyse. Ça c’est cool 🙂

La dernière question qui reste est donc quel moteur d’analyse choisir entre SSAS-Multidimensionnal, SSAS-Tabular ou le dB Engine ? La réponse n’est pas encore définitive, elle se précisera au fur et à mesure que nous ferons des projets sur les technos, mais des pistes apparaissent déjà:

  • BISM – Multidimensional : Techno « complexe », données hiérarchisées, grosses volumétries avec reporting à niveau agrégé, relations complexes (many to many…), comparaisons temporelles (mais pas trop les faits en période), des chiffres (pas trop des lettres)
  • BISM – Tabular : Techno simple et performante (elle rattrape les erreurs de développements assez bien), rapide à implémenter, beaucoup plus libre sur le modèle de données, agrège bien mais traite aussi bien le détail, costaud sur le distinct count, attention cependant aux trop grosses volumétries
  • Datamart SQL : J’entends par là des tables d’agrégats bien pensées. Dedans on mettra tout le reste 🙂

Pour plus d’infos, n’hésitez pas à consulter le webcast d’Aurélien Koppel et François Jehl sur le sujet, et n’hésitez pas non plus à en causer dans les commentaires, tous les avis sont bons à prendre!

Gestion de projet décisionnel : gardez vos utilisateurs proches de vous!

Entendu par un camarade consultant la semaine dernière dans l’open-space chez son client, c’est le directeur des études qui s’adresse à la chef de projet MOA : « Il faut arrêter de mettre tout le monde dans vos mails! Si vous parlez au métier, ne mettez pas la MOE en copie et inversement. Il ne faut pas qu’ils communiquent directement! ».

Mes dents grincent…

J’insiste lourdement sur ce point dans ma session sur la modélisation dimensionnelle, construire un datawarehouse sans les utilisateurs, sans les métiers, c’est le chemin direct vers les projets les plus frustrants qu’il soit.

Mais d’abord un peu de vocabulaire. Notez que ce ne sont pas des définitions absolues: c’est ma vision de la chose, et cela nous permettra juste de ne pas discuter pendant 3h pour se rendre compte à la fin qu’on était d’accord depuis le début:

  •  Côté Cycle en V (on spécifie un sujet de bout en bout, on développe tout d’un coup, on livre tout d’un coup – échelle temporelle : le mois)
  • Métier / Utilisateur : Au sens strict, les gens qui utiliseront le système. Donc ça exclut les sponsors, les acheteurs, et tous les gens qui passent leur temps en réunion mais qui ne produisent rien.
  • MOA : Maîtrise d’Ouvrage. Les métiers passent commande auprès de la MOA d’une solution à un de leurs problèmes. La MOA va écrire un cahier des charges qui décrit la solution le problème et les attributs essentiels de la solution (MàJ 26/12/11 – précision). Ils connaissent bien les problèmes que les métiers ont l’habitude de rencontrer et les solutions usuelles qui y répondent. Ils savent quelle(s) MOE impliquer pour chaque solution.
  • MOE : Maîtrise d’Œuvre. Réalise les solutions. Plusieurs MOE aux capacités distinctes peuvent intervenir sur une même solution.
  • AMOA : Assistance à la MOA. En informatique, unité spéciale de la MOE qui à force de réaliser des solutions commence à bien connaître les problèmes. Va filer un coup de main à la MOA quand les sujets deviennent complexes.
  • PMO : Projet Management Office. Les gens qui suivent les plannings et les budgets au niveau global. Ils ne produisent rien au niveau projet.
  • Côté Agile (on définit un besoin unitaire, on le développe, on livre uniquement la solution locale, on itère – échelle temporelle : la semaine), les termes correspondent ici à la méthodologie SCRUM:
  • Product Owner : Son nom est écrit sur le produit. Son activité principale c’est la bonne tenue du backlog au niveau produit – la liste ordonnée par priorité des fonctionnalités qu’on veut voir apparaître. Notez qu’il ne doit pas forcément écrire lui-même toutes les users stories (la description des fonctionnalités), mais il doit travailler à ce qu’elles soient le plus clair possible et que leur ordre corresponde effectivement à la valeur métier qu’elles apportent.
  • SCRUM Master (ou équivalent) : Garant de la bonne application de la méthodologie. Son but à terme c’est de ne plus avoir de boulot! En effet si tout le monde joue bien le jeu, plus besoin de lui 😉
  • Equipe de développement : Tous les contributeurs qui permettent la livraison des besoins unitaires.

Maintenant que c’est clair, on peut revenir au sujet du jour. L’étape n°0 pour la modélisation de son datawarehouse c’est identifier ses utilisateurs clefs, et se garantir un accès direct à leur calendrier. Pour moi c’est juste indispensable. C’est la raison pour laquelle j’aime beaucoup la philosophie Agile. Peu importe la méthodologie Agile choisie (la plupart du temps je n’utilise qu’un mini SCRUM à ma sauce), ce qui compte c’est de délivrer de la valeur, rapidement. Certes ça a un coût sur l’emploi du temps du Product Owner, mais on obtient des solutions qui répondent beaucoup mieux aux besoins des utilisateurs.

Mais quand on est en cycle en V, on n’accède pas directement aux utilisateurs, on doit passer par la MOA. Et là il faut que les rôles de chacun soient clairs : la MOA n’est pas là pour faire écran entre les métiers et la MOE.

Dans un premier temps, la MOA est là pour comprendre le besoin métier et choisir la MOE qui saura réaliser la solution.

Une fois ce choix fait, elle est là pour faciliter les échanges entre les métiers et la MOE. C’est un rôle d’interprète et de diplomate. Interprète pour que tout le monde se comprenne – expliquer le métier aux techniques et les contraintes techniques aux métiers. Diplomate pour faire coïncider les objectifs de tout le monde: un besoin théorique parfait pour les utilisateurs VS la dure réalité technique imparfaite de la MOE.

De la même manière qu’un interprète ne remplace pas un interlocuteur dans un dialogue, la MOA ne doit pas occulter la MOE. D’où mes dents qui grincent quand j’entends un directeur des études dire l’inverse…

En tant qu’architecte j’ai un problème supplémentaire pendant les cycles en V (en plus des problèmes habituels des architectes). Je m’occupe de l’architecture technique, activité clairement MOE, mais également de l’architecture fonctionnelle, à savoir la modélisation dimensionnelle à proprement parler. Je réponds entre autres aux questions suivantes:

  • Quelles sont mes dimensions?
  • Quelles sont mes mesures?
  • Quel processus métier modéliser dans la table de fait?

Et ça ce sont des questions qui ont souvent déjà des réponses dans le cahier des charges rédigé par la MOA. Si les MOA sont éclairées, les réponses sont bonnes, ou au minimum elles ne sont pas figées dans le marbre. Le problème survient quand les réponses ne sont pas optimales et qu’elles ont déjà été promises à l’utilisateur. Là pas de remède miracle à part une bonne dose de diplomatie et pédagogie.

L’autre problème c’est quand une technologie est choisie par la MOA: « Mon utilisateur veut un cube pour faire des tableaux croisés dynamiques sur les 500’000 clients dans les 100’000 portefeuilles et afficher le détail »… Pour ceux qui ne connaissent pas les technos, c’est l’équivalent de choisir un semi-remorque pour rouler en ville parce qu’on aime bien la taille du coffre. Le choix d’une technologie pour un projet décisionnel n’est pas une décision anodine. Inclure la MOE dans ce choix est une évidence qu’il faut malheureusement souvent rappeler.

Désolé pour le pavé, mais il fallait que ça sorte 😉

Prochains sujets : choisir la bonne gestion de projet pour son projet décisionnel (Agile vs Cycle en V), et choisir la bonne technologie dans l’écosystème Microsoft.

Sécurité des données dans l’environnement SQL Server

Lors d’un des derniers projets auquel j’ai participé, nous avons eu à mettre en place une sécurité à la ligne. Rien d’extraordinaire en soi, mais c’est un bon cas d’étude pour comprendre comment fonctionne la sécurité entre les différentes briques de l’environnement SQL Server.

J’ai essayé de schématiser ça en 3 dessins Visio que je laisse en téléchargement par ici (C’est la première fois que j’utilise Google Document comme ça, mailez moi si ça ne marche pas).

Pour faire court :

  • Un groupe d’administration accède à une interface ASP.NET qui lui permet de définir des couples Utilisateur / Périmètre. Le périmètre s’applique sur une hiérarchie organisation, il se compose d’un niveau et du code de l’entité à ce niveau.
  • Le groupe d’utilisateur accède à un reporting qui utilise un cube et des données de la base. On doit lui appliquer la sécurité définit par les administrateurs.

Pour implémenter une sécurité à la donnée, on ne peut pas donner des droits DataReader/DataWriter aux utilisateurs sur la base. En effet la granularité minimale de la sécurité sur SQL Server c’est la table, ni la ligne ni la colonne.
Il va donc falloir utiliser des procédures stockées (droits GRANT EXECUTE) et joindre les résultats sur la table qui stocke les couples Utilisateur / Périmètre.
Pour le cube, il va falloir définir un rôle qui utilise cette même table.

Le point important dans tout ça, c’est que si votre configuration n’est pas mono-serveur, c’est-à-dire si votre service SSRS n’est pas installé sur le serveur qui héberge la base et/ou le cube, il va falloir mettre en place la délégation d’autorité en utilisant Kerberos. C’est en effet la seule manière de faire propager le UserId depuis le SSRS frontal jusqu’aux cubes et aux procédures stockées. Dans le cas contraire, ce sera le compte de service de SSRS qui se propagera jusqu’aux données.

On peut contourner ce pré-requis si on n’utilise pas de cube dans la solution. Pour ce faire, il suffit de transmettre la constante User !UserId de SSRS en paramètre à la procédure stockée appelée. Ce n’est pas la best practice, mais ça marche. Cette manipulation n’est pas possible pour SSAS puisque la gestion des droits est transparente dans le cube.

Voici le premier schéma, il présente une vue d’ensemble de la configuration:

Vue d'ensemble de la sécurité

Concernant la sécurité fonctionnelle, la sécurité à la ligne, on peut utiliser un jeu de tables comme cela pour l’implémenter:

Définition de la sécurité

Et enfin, pour utiliser tout ça, il faut employer les scripts suivants:

Utilisation de la sécurité

Rappel : si vous voulez le VSD de ces schémas, il suffit de remonter en haut de l’article.

Ne disposant pas de la science infuse, j’apprécierai sincèrement les éventuelles corrections / améliorations que vous auriez à proposer 🙂