Revue : Big Data par Nathan Marz et James Warren

Je vais aller droit au but: vous savez comme je vois le DWH Toolkit de Kimball & Co comme LE bouquin de référence pour le décisionnel, et bien c’est très simple, voilà son équivalent côté Big Data. A mon sens c’est une lecture incontournable, d’autant plus si vous avez déjà écrit ou prononcé les mots « Lambda Architecture ».

Notez que je ne suis pas le seul à en dire du bien, c’est un ouvrage qui a été largement encensé depuis qu’il est sorti, et franchement il le mérite!

Nathan Marz (Twitter, Site) c’est un ancien de Twitter et l’un des créateurs d’Apache Storm, la techno de stream processing la plus utilisée dans la stack Hadoop. Il a fait ses preuves.

Couverture : Big Data chez Manning

Au delà du fond, vraiment passionnant, la forme est également au top. En effet on alterne des chapitres théoriques avec des exemples d’implémentation technique, sur des technologies variées, toujours dans le cadre de la mise en place d’un même système de web analytics. Ça donne un fil rouge au bouquin qui rend sa lecture vraiment digeste.

Morceaux choisis:

  • Les techniques fondamentales liées au Big Data: des systèmes (storage & compute) qui ont conscience de leur nature distribuée, des données immutables, le tout pour permettre le scaling horizontal (ajout de machines) le moins douloureux possible

  • Pour rendre un système de données résistants aux erreurs humaines : on conserve les données dans un format immutable (on ne peut qu’ajouter, ni supprimer ni mettre à jour) et des algorithmes en re-calcul complet (recomputation, à opposer aux chargements incrémentaux)

  • D’où l’architecture lambda : un master dataset immutable avec une ligne de chargement en re-calcul complet (batch + serving layers), mais ce sera lent, donc on y adjoint d’une ligne de chargement rapide (speed layer), à côté, qui gèrera les delta en attendant le prochain batch. Et pour l’utilisateur, une vision unifiée qui brasse des données issues du batch et du streaming.

Schéma de la Lambda Architecture

  • Côté Master Dataset, on utilise une techno robuste qui assure le caramel en batch write / batch read : du filesystem, en mode distribué avec HDFS. Là-dessus on emploie une modélisation particulière (fact-based model, une normalisation complète), si possible structurée via un framework de serialization genre Avro, ProtoBuf ou Thrift.

  • On prépare des batch views dans le Serving Layer, à coup de Map/Reduce en Java ou Python, à destination d’une base batch write / random read orientée requêtage ad-hoc. Ici on va indexer et dénormaliser, pour le confort des utilisateurs.

  • Sur le Speed Layer, le but va être de reproduire la même chaîne de traitement qu’en batch (un des inconvénients de la méthode), mais sur un volume bien moindre de donnée, pour s’approcher du temps réel. On parle Kafka pour gérer la queue multi-utilisateur, Storm pour le stream processing incrémental, et Cassandra pour gérer le random read / random write à exposer aux utilisateurs.

Si vous voulez avoir le pourquoi de tout ça, expliqué de façon propre et illustrée, direction le bouquin, il vaut le coup.

Je recommande plus que vivement 🙂

Modélisation dimensionnelle : Dimensions hétérogènes en Sur-type et Sous-type

N’ayez pas peur du nom à rallonge, le concept est finalement assez simple 😉

Cette technique super utile est évidemment couchée sur le papier par nos amis les retraités, dans leur bible incontournable (oui je parle de Kimball…).

Couverture DWH Toolkit 3rd Edition

Imaginez que vous bossez pour une compagnie d’assurance, qui vend des polices d’assurance pour plusieurs types de produit: auto, moto, habitation, personnelle…

Côté modélisation dimensionnelle (après consultation du chapitre 16 du DWH Toolkit), on voit bien une table de fait qui va couvrir les transactions des polices, permettant de suivre le cycle de vie des dossiers:

  • Création / modification du dossier (détails de l’assuré, dates de début…)
  • Création de la couverture et association à l’objet à couvrir (type de produit, options… par exemple un tout risque auto + vol)
  • Obtention d’un devis avec la génération du tarif
  • Validation du devis et création de la police effective, demande des justificatifs
  • Obtention des justificatifs et pérénisation du dossier

A cette table de fait on va associer une série de dimensions, les axes d’analyse qui nous permettront de ventiler et analyser les faits. Ici on retrouvera les différentes dates, l’assuré, la couverture et l’objet couvert, l’employé responsable du dossier, les attributs du dossier…

Alt

Seulement voilà, après réunion avec le métier, on se rend compte que les attributs des dimensions Couverture et Objet Couvert ne sont pas du tout les mêmes entre le domaine auto et habitation. En effet, il paraît assez normal qu’on ne décrive pas une maison et une voiture avec les mêmes informations.

Il est quand même à noter que pour des soucis de consolidation et de reporting transverse, on doit tout de même constituer une table de dimension « chapeau », avec une série d’attributs simples qui concerneront à la fois l’auto et l’habitation (valeur, risque, localisation géographique…).

Côté modélisation, Kimball nous recommande alors d’utiliser la technique Sur-type / Sous-type (Supertype / Subtype). Nos tables de dimension initiales deviennent des tables de Sur-type, elles détiendront les attributs communs. A ces tables on va ajouter des tables de dimension de Sous-type, à savoir Couverture Auto, Couverture Habitation, Objet Couvert Auto et Objet Couvert Habitation, qui contiendront elles les attributs spécifiques à chaque ligne de business.

Alt

Deux choses à noter:

  • On réutilise les mêmes valeurs de Surrogate Key pour les dimensions Sur-type et Sous-type, inutile d’encombrer la table de fait avec des FK supplémentaires
  • On intercale des vues entre ce schéma et les utilisateurs, pour apporter:
    • la vision consolidée (toutes les lignes de la table de fait et uniquement la dimension Sur-type)
    • des visions par ligne métier (un filtre sur la table de fait pour n’exposer que les transactions du type) et la dimension Sur-type accompagnée de la dimension Sous-type:

Alt

Plutôt cool non? On a le beurre et l’argent du beurre avec cette approche 😉

Evidemment on ne peut appliquer cette méthode que si les mesures présentes dans la table de fait sont communes à tous les processus métier (Auto, Habitation…)

Dans le cas contraire, il est nécessaire de créer des tables de fait différentes, chacune avec ses mesures propres. Notez que dans ce cas, il est toujours possible d’utiliser l’approche Sur-type / Sous-type, pour disposer d’une table de dimension permettant la consolidation et le reporting transverse. Voir pourquoi ne pas aller plus loin et créer une table de fait de consolidation, qui portera les mesures communes et la table de dimension Sur-type. Le gros avantage c’est d’être capable d’exposer en une passe les données de haut niveau sans repasser par 2 tables de bas niveau qui peuvent être plus lourdes (mais on s’en passe très bien si la solution contient un cube OLAP).

Pour aller plus loin: les chapitres 10 et 16 du Datawarehouse Toolkit 3rd Edition.

Modélisation dimensionnelle : Comment choisir entre Fait, Dimension ou Attribut de Dimension ?

C’est une question qui m’a été posée dernièrement, et je voulais partager avec vous la réponse. Pour ceux qui débutent, on va parler ici de comment construire un modèle dimensionnel, qui permettra le stockage et l’analyse de données que l’on souhaite étudier, que ce soit pour Excel, Power Pivot, SQL Server ou SSAS.

Et pour bien répondre, le mieux est de partir d’un cas pratique :
Je veux analyser la ville de mes magasins, comment la représenter dans mon modèle ?

  • Est-ce que c’est un fait ? L’implémentation géographique de mes magasins ?
    • Qui méritera donc une table de fait à part entière…
  • Est-ce que c’est une dimension à part entière ?
    • Qui méritera donc une table propre et des clefs étrangères dans les tables de fait qui l’utilisent…
  • Ou est-ce que c’est un attribut de ma dimension magasin ?
    • Qui méritera donc une colonne dans la table de dimension correspondante…

Comme d’habitude la réponse est de l’expert est « ça dépend ! »

Mais...

« Et ça dépend de quoi ? » me demandez-vous ?

D’abord de savoir si on joue avec un fait ou une dimension. Là le critère pour trancher est simple : la valeur permet-elle de quantifier (compter, mesurer…) ou qualifier (ventiler, filtrer, trier, grouper…) le processus que je veux étudier (ce à quoi correspond une ligne dans ma table de fait).

Dans notre cas : les quantités mesurées peuvent-elles être ventilées par villes, ou pas ? La réponse est oui : ma ville en elle-même n’est donc pas un fait. Et c’est d’ailleurs plutôt logique, un fait c’est un processus métier qui se réalise, typiquement une transaction ou un comptage. Si on joue avec des villes, une transaction ça pourrait être un déménagement, un comptage le recensement annuel. La ville en elle-même n’est donc pas une mesure. Attention à ne pas croire que la distinction se fait selon le type de la donnée, texte ou valeur numérique, puisqu’un âge ou un prix peuvent complétement être des éléments servant à filtrer (j’étudie mon CA des ventes par prix de vente des articles), donc être côté dimension.

Pour les gens de niveaux 2 et plus, vous noterez que la vraie question sous-jacente est comme toujours de préciser quel est le processus métier concerné par ma table de fait. A quel événement dans le monde réel correspond une ligne dans ma table de fait.

La question suivante est de savoir si la ville est une dimension de mon processus métier, ou un attribut d’une autre dimension, dans mon cas la ville du magasin (cf. schéma ci-dessous):

MD - Schéma 1

D’un point de vue strictement fonctionnel, le critère est simple : c’est le rythme de changement d’un attribut par rapport à un autre, et par rapport aux faits :

  • Si le magasin ne change jamais de ville : la ville est un attribut du magasin, c’est une colonne de la dimension magasin (partie droite du schéma)
  • Si le magasin peut changer de ville mais c’est rare : toujours un attribut mais on va utiliser les techniques SCD (d’où d’ailleurs le lent/slowly de slowly changing dimension, dimension à variation lente) dans la dimension magasin (partie droite du schéma)
  • Si le magasin change de ville plus ou moins à la même granularité temporelle que les faits (le mois ou le jour) : alors c’est une dimension indépendante (partie gauche du schéma)

Plutôt élégant non ?

Maintenant, il arrive que pour des raisons techniques on puisse créer des dimensions géographie ou adresse, quand on veut réutiliser ces adresses pour différentes dimensions (clients, collaborateurs, fournisseurs…), même si on est dans les cas invariants ou à variation lente. A ce moment-là soit on floconne les dimensions, soit on reste en étoile. En flocon (schéma en dessous à droite) on complexifie l’alimentation et les requêtes pour utiliser le modèle (jointures à étage), en étoile (schéma en dessous à gauche) on perd toutes les relations qui existent entre la géographie et le magasin qui n’auraient pas été concrétisées par un fait :

MD - Schéma 2

Dans ce cas, à vous de choisir en fonction de votre besoin métier et vos contraintes techniques.

Si on récapitule le tout, c’est plutôt simple finalement ?

  • Fait ou Dimension : quantifier (mesurer) versus qualifier (ventiler).
  • Dimension ou Attribut de dimension : en fonction du rythme du changement de l’attribut par rapport à la table de fait.

Évidemment on ne peut pas parler de modélisation dimensionnelle sans rappeler que c’est une science exacte qui dispose d’une bible, le DWH Toolkit de Ralph Kimball et toute sa clique.

N’hésitez pas à partager vos cas tordus, la théorie ça doit se tester sur la pratique 😉

JSS2012 : Modélisation Dimensionnelle – Slides à télécharger

Si l’année dernière nous avions eu la chance d’avoir des webcasts enregistrés pour chaque session, malheureusement cette année nous n’avons pas eu le budget. Je n’ai donc que les slides à vous proposer, pour cette session Modélisation Dimensionnelle présentée avec mon compère Charles-Henri. Ah et une photo aussi 🙂

JSS2012 - Charly et Florian causent Modélisation Dimensionnelle

Rho ces speakers qui regardent l’écran…

 

J’en profite pour rappeler la littérature obligatoire dont on parle pendant la présentation :

Voilà pour le contenu de la présentation. Concernant le « public speaking », je vous avoue que c’est un exercice qui m’éclate de plus en plus. Si j’ai encore les chocottes les 5 premières minutes avant le début, ça ne dure guère et ça se transforme vite en plaisir.

Par contre, pour que ce soit vraiment le cas, cela demande quand même 2 choses :

  • D’abord parler d’un sujet qui me passionne. Je ne pourrais définitivement pas faire ça sur un sujet qui ne m’intéresse pas, ou avec des contraintes éditoriales qui m’empêcheraient de délivrer le message comme je le souhaite.
  • Ensuite de la préparation ! Il faut du temps pour murir les slides (au moins 3 versions successives complétement différentes), et surtout répéter, pour harmoniser son discours, travailler ses transitions et valider qu’il y a bien un fil rouge, qu’on raconte bien une histoire, plutôt qu’énumérer une suite de listes à puces.

Si ces deux conditions sont remplies, alors c’est vraiment fun !

Et vous avez l’habitude avec moi, là aussi j’ai un gourou dont je suis les enseignements, il s’agit de Scott Berkun (celui dont je tiens également la vision différente du rôle de chef de projet) et son livre c’est « Confession of a Public Speaker », une référence sur le sujet.

Enfin, n’hésitez pas à me faire vos retours sur la session dans les commentaires. Ce que vous avez aimé, ce qui vous a déplu, à quel moment je vous ai perdu, est-ce que j’ai réussi à vous rattraper… Ça m’intéresse beaucoup ! Et en question complémentaire : on parle de quoi l’année prochaine ? 😉

Modélisation dimensionnelle à éviter : La table de faits universelle

Comme vous le savez peut-être, cette année encore je co-animerai la session Modélisation Dimensionnelle aux Journées SQL Server 2012, les 10 et 11 décembre sur Paris, avec mon camarade Charles-Henri. Cette année on passe level 300 (ça commence à causer plus sérieusement) et franchement je pense qu’on va passer un bon moment 🙂

En attendant le jour J, je voulais vous parler d’une technique qui ne sera pas présentée lors de la session : celle de la table de faits universelle. Rencontrée chez un client dernièrement, c’est une modélisation qu’on peut aussi appeler la table de faits unique. Une table de faits pour les gouverner toutes. Une table de faits pour les trouver. Une table de faits pour les amener toutes et dans les ténèbres les lierHumJe divague

Je te vois faire n'importe quoi!

Je te vois faire n’importe quoi!

Si ça avait été fait par un stagiaire, ou un client qui s’essayait au décisionnel en dilettante, je trouverais ça mignon. Sincèrement. J’applaudirais pour l’effort et on prendrait une demi-journée ensemble pour causer modélisation. Mais là c’est réalisé par une équipe de consultants spécialisés dans le décisionnel.  Et c’est facturé. Moins mignon.

Alors voyons à quoi ça ressemble:

La table de faits universelle

Dans cette même table de faits, qui s’appelle juste « Fait » (c’est plus simple) on retrouve :

  • Les ventes quotidiennes
  • L’inventaire hebdomadaire
  • Les budgets trimestriels des magasins
  • Les objectifs trimestriels des commerciaux

C’est quand même bien fait ! On a tout sous les yeux d’un seul coup. Pas besoin de jointures, les requêtes SQL sont simplissimes. Alors que reprocher à cette modélisation ?

Déjà, je vous avoue qu’en 6 ans de missions en décisionnel, je n’ai jamais vu ça. J’en ai même parlé lors d’un afterworks du GUSS, auquel étaient présents des consultants d’à peu près tous les pure-players en décisionnel Microsoft, et personne n’en avait entendu parler non plus.

Mais vous me connaissez, je n’allais pas me limiter à ça. Regardons donc ce qu’en dit la littérature :

  • Wikipedia – Fact Table : “In data warehousing, a fact table consists of the measurements, metrics or facts of a business process.”  Une table de faits pour un processus métier donc, les ventes ou l’inventaire ou les budgets… mais un seul. J’avoue, en effet, ils auraient pu insister et mettre: “ a SINGLE business process”. Mais à mon avis personne ne se doutait qu’on verrait arriver la table de faits unique.
  • Wikipedia – Base de données relationnelle : « Dans une base de données relationnelle chaque enregistrement d’une table contient un groupe d’informations relatives à un sujet (…) ». Même commentaire, et là on parle de toute la technologie de la base de données relationnelle, plus seulement du décisionnel.
  • Ralph Kimball, l’inventeur du schéma en étoile, indique lui que chaque table de faits représente un processus métier, que chacune de ces tables est reliée à des dimensions, les mêmes dimensions pour tout le monde (alors dites conformées), et que toute la valeur de la modélisation en étoile vient justement de là. Parce qu’entre nous, quitte à faire une table de fait unique, autant pas s’embêter à faire des tables de dimensions hein… Et là le lien je le fais par vers un article spécifique, mais vers le bouquin de Kimball, parce qu’à un moment il va falloir le lire ce livre si vous vous dites consultant ou développeur décisionnel.
  • Bill Inmon, l’inventeur du schéma en flocon, indique la même chose. En effet les différences entre les deux modèles se situent au niveau de la structure des dimensions et du processus de génération du modèle, pas des tables de faits.
  • Et quid de Datavault ? La troisième modélisation très contestée du décisionnel ? Là c’est pire puisqu’on normalise complètement et qu’on conserve le format source original (une table pour les clients, une table pour les magasins, une table de relation entre les 2, etc, etc). Pas de table unique en vue.

Pas de chance, la littérature ne fait donc aucune mention de cette technique, et c’est même plutôt l’inverse qui est recommandé : créer une table de faits par processus métier. Soit dans notre cas, 4 tables : ventes, inventaires, budgets et objectifs.

Je précise au passage que dans ces sources, il ne faut pas interpréter la phrase « la table de faits est au centre du schéma en étoile » comme une indication qu’il n’y en ait qu’une seule. En effet un datawarehouse ce n’est pas un mais plusieurs schémas en étoile, plusieurs datamarts, autant qu’il y a de processus métier. Et en théorie l’ensemble de ces étoiles s’appelle une constellation, mais ça devient trop poétique donc on emploie rarement le terme.

D’une manière plus pratique, si on abandonne la littérature et qu’on s’interroge sur les mérites d’une telle modélisation, on peut se faire les réflexions suivantes :

  • Performances
    • A priori elles ne seront navrantes. En effet pour aller chercher un élément particulier de la table (les budgets), le moteur doit parcourir toutes les lignes de la table (les ventes, les inventaires…). C’est largement inefficace.
    • L’index le plus rapide de tous est l’index cluster (celui qui dicte comment les données sont écrites sur le disque). Comme vous le savez, on ne peut en définir qu’un seul par table (par définition). Tout mettre dans la même table c’est donc se priver d’un des meilleurs outils d’optimisation de la base de données. A la place d’en avoir un par processus métier, il n’y en aura qu’un seul, qui en plus ne sera pas très bon. Car évidemment, l’index s’optimise différemment en fonction du sujet. On indexe les ventes (par jour/magasin/produit) différemment qu’on indexe les objectifs (par trimestre/commerciaux). Et croisez les doigts pour que l’unicité des lignes des 4 processus métiers tiennent en moins de 16 colonnes.
    • Même remarque pour le partitionnement.
  • Confort d’utilisation / Qualité du requêtage
    • Si on s’économise les jointures en SQL, j’ai peur de ce à quoi vont ressembler les clauses WHERE. Et on n’a pas intérêt à se tromper sur ces filtres, sans quoi on va additionner des choux et des carottes (des quantités de ventes et des quantités d’inventaires). Le risque métier est important avec cette approche, il est inexistant avec la modélisation classique.
    • Et là où les jointures reviendront en force, c’est si on veut obtenir un état avec par exemple du budget et du facturé. Il faudra en effet faire une auto jointure (en FULL OUTER JOIN) de la table unique sur elle-même. Ce sera douloureux en écriture de requête et en performance.
    • Enfin, on l’a bien compris, impossible d’exposer ce modèle directement à un utilisateur. Il faudra définir un modèle de métadonnées devant chaque outil de reporting (Excel, Tableau, SSAS, SSRS…). Attention au coût de développement masqué.
  • Maintenabilité / Evolutivité
    • J’ai peur que l’ajout d’un nouveau processus métier (comme il est prévu dans le lot 2 j’imagine ?) ne se traduise par l’ajout de nouvelles colonnes dans cette table. Dans ce cas il faudra changer toutes les requêtes déjà développées (clauses WHERE, agrégations), toutes les métadonnées, et toutes les optimisations déjà réalisées. En somme il faudra tout refaire. A chaque évolution.
    • Enfin, si on s’enferme dans cette architecture, impossible de trouver un prestataire digne de ce nom qui assurera la TMA ou les évolutions sans d’abord tout refondre.

Bon et bien on le voit, si c’est une nouvelle théorie, c’est l’équivalent de remplacer les groupes sanguins par les signes du zodiaque pour déterminer la compatibilité dans les transfusions sanguines. De temps en temps ça va marcher, certes, mais sur le long terme…

Et sinon, comment modéliser ça de manière satisfaisante ?

En identifiant les dimensions utilisées pour chaque processus métier, leur grain, et en construisant les tables de fait en fonction (c’est dans le livre, ou dans le webcast) :

Oh la jolie étoile!

PS : Les périodes temporelles diverses (semaines, trimestres) sont gérées directement dans la dimension temps.

Là on dispose d’une constellation composée de 4 étoiles, qui utilise des dimensions conformées (partagées), qui répond aux problématiques de performance, de confort d’utilisation et de maintenabilité. Si on souhaite intégrer un nouveau processus métier, on ajoute une nouvelle table de faits, sans avoir à modifier l’existant. Chaque processus peut évoluer indépendamment des autres. Chaque amélioration d’une dimension profite à toutes les analyses.

De tout ça on en reparle lundi 10 décembre, aux Journées SQL Server 2012. Inscrivez-vous 😉

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.