De la BI? Vraiment?

Histoire de quand même mériter la mention de « Business Intelligence » dans le nom de ce blog, je vous livre ce lien vers un article de Marco Russo. Ce sont les sources de son livre sur PowerPivot, ça peut être super pratique pour débuter sur cette techno (avec ou sans le livre).

J’en profite pour vous dire que si ça vous concerne, ça bouge du côté de la faille ASP.NET découverte la semaine dernière.

Un beau métier? Architecte des étoiles!

La base de cet article est un pavé écrit par Venkatesh Rao de Ribbonfarm: celui-ci.

Pour moi c’est à lire absolument, et d’autant plus si vous êtes dans un de ces deux cas:

  • Vous travaillez avec un architecte des étoiles,
  • Vous êtes en train de modéliser la réalité pour en faire une application, et ça commence à faire mal à la tête.

Qu’est ce que j’appelle un architecte des étoiles? C’est un architecte perdu pour la cause dans son délire mégalo-maniaque de modéliser le monde entier dans son application.

Les symptômes?

  • Le modèle de l’application qui comporte trop de niveaux d’abstractions (faire un ETL avec un ETL, redévelopper SSAS dans SQL Server…),
  • Le modèle que plus personne ne comprend de bout en bout à part l’architecte des étoiles,
  • Le projet qui inclut le développement d’un framework (alerte rouge),
  • La documentation qui fait plus de 200 pages…
  • Le fait que les développeurs passent plus de temps à coder des « corrections » des outils de dev que pour implémenter l’application

Ce qui nous ramène à l’article de Ribbonfarm, qui vient nous expliquer comment naissent ces délires étoilés:

  1. Tout commence quand on regarde une réalité complexe et déroutante, avec pour volonté de l’analyser,
  2. Cette réalité étant complexe, on échoue à répétition à intégrer toutes les subtilités dans son analyse,
  3. On attribue alors cet échec (et la frustration qui va avec) à une irrationalité supposée de ce qu’on analyse plutôt qu’à ses propres limites,
  4. On invente alors une version de la réalité telle qu’elle devrait être,
  5. On impose ensuite cette vision comme vérité, quitte à détruire la réalité qui existait avant,
  6. Enfin on regarde l’impossible utopie élaborée avec amour échouer lamentablement

Toutes ces étapes sont naturelles, humaines, il ne sert à rien de vouloir les éviter absolument.

Ce qui est important, c’est que lorsque ça commence à faire mal (étape 3, étape 6), on arrive à mettre son amour propre de côté et repartir de 0. A force d’itération la connaissance et la compréhension vont s’améliorer, un modèle correct finira donc bien par émerger tôt ou tard. Bien évidemment, une itération prenant du temps, il faut donc mieux itérer sur des maquettes, voir des prototypes, pendant une grosse phase de conception, plutôt qu’itérer sur des cycles de développements complets à 200 jours-hommes pièce…

Vous pouvez maintenant vous demander qu’est ce qui différencie l’architecte étoilé de ses pairs, si la nature humaine force tout le monde à suivre le même chemin de croix? C’est son manque définitif de remise en question lorsque tout s’écroule qui l’identifie clairement: son modèle était parfait, ce n’est quand même pas de sa faute si les développeurs étaient si bêtes!

Les deux mondes de la BI

Vu chez Flowing Data, ce slide issu d’une présentation de Tableau Software:

Le slide est commenté par son auteur ici, je trouve sa réflexion extrêmement pertinente. La citation « big software, little analysis » pour décrire le datawarehousing est tellement vraie!

L’idée présentée dans ce slide est très bien résumée par cette phrase de Nathan Yau : « You have to get over the wall to really get something out of your data. Otherwise, you’re just a drone doing a computer’s work when it should be the other way around » (« Tu dois aller à droite du mur si tu veux tirer quelque chose de tes données. Sinon tu n’es qu’un drone qui fait le boulot d’un ordinateur alors que cela devrait être l’inverse.« )

Le message nous est en partie adressé, à nous les consultants qui fabriquons les applications décisionnelles, bien à l’abri à gauche du mur:

  1. nos applications doivent être conçues pour permettre aux utilisateurs de franchir le mur,
  2. nous devons accompagner les utilisateurs pour qu’ils puissent le faire.

En terme d’outils, à gauche du mur on retrouve SQL Server, SSIS et SSRS. Pour moi la brique qui fait le pont entre les deux mondes c’est SSAS. De l’autre côté, on a Excel (tableaux croisés dynamiques ou avec les fonctions cube), maintenant PowerPivot (gratuit sur Excel 2010) et les modules de données de SharePoint (ex PPS Monitoring). Cela plus tous les outils de l’écosystème Microsoft (Tableau pour l’analyse, Clarity Systems pour le BPM,…), ça ne fait pas de nous les plus mal équipés pour traiter le problème!

Alors va falloir s’y mettre! 🙂

Ps: J’ai testé Tableau, enfin leur soft, et je l’ai trouvé vraiment sexy. Par contre je ne l’ai encore jamais déployé ni vu déployé. A venir peut être!

Ps: Je cite Clarity ici parce que j’ai eu droit à une démo de leur produit, et leur module de saisie (objectifs, budgets…) est juste bluffant.

La Sagesse du Junkie

Le Junkie en question c’est Jamie Thomson, le célébre SSIS Junkie.

Dernièrement il a écrit 3 articles qui ont retenu mon attention:

  • Repenser les méthodes de diffusion de la BI. Utiliser Outlook, les flux RSS, twitter/facebook, que sais-je, pour délivrer les infos issues de la BI, pour moi c’est définitivement sexy. Des variations non seulement sur le medium (iPhone, SmartPhone, Mac…) mais aussi sur la méthode. Ça peut devenir un gros sujet pour nous.
  • Comment ne pas transformer le dataflow en un curseur. Dans un flux de données, il faut savoir bien répartir les taches entre les différentes ressources et composants, sous peine d’être violemment pénalisé en performance. Cet article est une bonne piqure de rappel. Cela dit, attention à l’effet inverse qui consiste à passer toute l’intelligence du flux dans la requête SQL source. Rien de pire qu’une requête de 3 pages dans la source et hop une destination. Quand je vois ça, je m’énerve tout rouge!
  • Le dépivot dynamique : comment dépivoter des données lorsqu’on ne connaît pas à l’avance les colonnes que l’on obtiendra en sortie. A noter que c’est possible quelque part dans un coin de sa tête 😉

Pour ceux qui ne suivent pas directement Jamie, je pense linker régulièrement ses bons articles par ici. A suivre donc!

Michael Stonebraker casse la baraque!

Tout d’abord, qui est ce Michael Stonebraker?

Bah juste un vieux de la vieille de la base de données. Il a contribué à Ingres, Postgre, il est prof au MIT, et maintenant il bosse dans 4/5 boîtes autour des bases de données à stockage vertical. Il en impose en somme. Et si je peux me permettre, il n’est pas très photogénique… Mais ce n’est manifestement pas un défaut pour sa carrière 🙂

Ensuite, qu’a dit ce monsieur qui me fait m’exclamer qu’il casse la baraque? En fait pas grand chose, c’était juste une tentative foireuse de faire un jeu de mot avec son nom…

Mais bon, il a quand même dit des choses dernièrement, particulièrement, il a fait son top 10 des vérités à propos des data-warehouses. Et tout d’un coup, ça devient vachement plus intéressant que tout ce que j’ai dit avant non?

Pour le commentaire de texte, on va se faire ses vérités une par une, du goret quoting comme on disait à mon époque, ça sera plus simple:

  • 1 – Étoiles et Flocons c’est bon, mangez-en

Hum, rien à redire là dessus, avec une nette préférence pour les étoiles par ici!

  • 2 – Le stockage vertical (par colonne) remplacera à terme le stockage par ligne chez les éditeurs de DWH

Là, ça me semble plus être du whisful thinking de la part d’un gars qui a mis tous ses oeufs dans un panier vertical qu’une prédiction réellement motivée. En même temps il a prévenu dans l’intro qu’il était biaisé vers sa techno.

Dans tous les cas, si ça doit arriver, je verrais bien un paramètre de base dans SQL Server qui indiquerait le type de stockage souhaité: colonne ou ligne. Ça ce serait sympa!

  • 3 – La vaste majorité des DWH ne sont pas candidats pour le stockage in-memory

En gros: les DWH sont trop gros pour être stockés en RAM ou sur de la flash, compte tenu du prix de ces mémoires par rapport à la quantité de données à stocker. Ils seront donc cantonnés aux disques durs pour un bout de temps.

Rien à redire là dessus, il prend pas trop de risques en même temps.

Mouais. Faut voir ce qu’il appelle le « marché ». S’ils ne considèrent que les DWH qui pèsent des Peta, alors là oui. Pour la majorité des DWH, ceux qui sont dans les Giga, ça risque de prendre plus de temps. Dans tous les cas, nous on est prêt, on a rien à craindre!

  • 5 – Objectif : des bases qui ne se paramètrent pas

Je suis carrément d’accord là dessus. Ça dit que l’augmentation du nombre d’options et de paramètres dans la configuration des bases implique une baisse de la compétence des dBa. C’est normal! Avec 20 pages de paramètres, il faut des magiciens pour arriver à tuner correctement une base en perte de performance.

Et j’aime l’approche prise du côté SQL Server sur ce point: installer une base ça prend 15 minutes. Elle pourra tourner pendant 5 ans sans aucun problème. La plupart des options sont très correctement configurées par défaut. Et si besoin, on peut quand même accéder à 15 pages d’options pour les cas bien tordus.

  • 6 – Les vendeurs d’appliances devraient oublier le hard

Encore d’accord. Teradata héberge des gens extrêmement brillants, mais je n’accroche pas du tout à leur modèle.

Pour la BI sur laquelle je bosse, c’est trop compliqué, trop figé et surtout trop cher.

  • 7 – Un serveur par type d’application

Mouais. Tout dépend de l’échelle des applications. On peut faire cohabiter de l’OLTP et de l’OLAP (au sens large) dans une même base SQL Server sans tout crasher, tout dépend du dimensionnement et des volumétries.

Ce point 7 c’est surtout une occasion pour reparler de stockage vertical! Quel coquin!

  • 8 – Toutes les appli BI veulent de la haute dispo

Hum. Toutes? Là on va pas être d’accord Mister!

Toutes les applis qui nécessitent des dizaines de serveurs de plusieurs K€, 25 personnes à temps plein pour la maintenance et qui brassent des terabytes de données? Là on est d’accord!

Mais réduire la BI à ça, c’est bien dommage.

  • 9 – Les bases devraient supporter le « online reprovisioning »

Joker, pas mon sujet.

  • 10 – La virtualisation ça ne marche pas génial pour les bases de données

Même remarque que pour la 8. Encore une fois le monde du BI est réduit aux monstres. C’est bien dommage!

Conclusion:

Je suis d’accord sur 4 points (1,3,5,6), pas d’accord sur 1 (2), et pas d’accord sur la définition du marché de la BI sur 4 (4,7,8,10). Plus un NSPP, le 9.

Et vous? 🙂

That’s the spirit of it! (2/2)

(La partie 1/2 c’est par là)

Disclaimer : l’auteur des 3 lois, anonyme, est un brin vulgaire. Moi je trouve que ça va bien avec son discours, certains pourraient ne pas aimer, vous êtes prévenus.

Avant de parcourir les 3 lois du business, il y a un petit préambule. Tout d’abord c’est évidemment hautement satirique, et comme toute bonne satire, on y retrouve un bon fond de vérité… Ensuite, l’auteur entend ces 3 lois comme 3 lois qui s’appliquent aux vrais consultants, aux pros, ceux qui savent ce qu’ils font, ceux qui maitrisent leur sujet et connaissent leurs limites, ceux qui ont déjà fait leur preuve.

Et pour l’auteur, ces gens là…

  • …n’en n’ont rien à carrer du service des achats et de ses processus. S’ils se déplacent chez un client, ils sont payés, ou ils ne viennent pas. Rien n’est gratuit : No Freebies
  • …n’en n’ont rien à carrer des conflits politiques, des dress codes et de l’étiquette locale. S’ils se déplacent ce n’est certainement pas pour se retrouver dans une cours de récréation : No Backsies
  • …n’en n’ont rien à carrer des menaces. Si ça dégénère, il ne faut pas oublier qu’un pro ça change de mission en 48h, par contre un client ça reste avec son problème : GTFO

Oui c’est extrême, mais j’adore 🙂

Au-delà de ces 3 lois, sa « sagesse » s’exprime principalement autour d’articles courts qui sont de vraies perles, dont voici une petite sélection :

  • Les faits ne sont pas négociables – « Tu peux soit t’assoir, fermer ta gueule et apprendre quelque chose, soit me décrire comment ton idée n’a rien à voir avec le problème en cours »
  • La banque de la dette technique – « Des fois tu sais que tu n’arriveras jamais à finir correctement et à l’heure. C’est là qu’intervient la plus vieille institution connue des programmeurs : la banque de la dette technique, qui échange un peu de temps contre la qualité de ton code. Mais faut pas oublier que la banque se rembourse toujours à la fin »
  • Des améliorations jusqu’à plus soif – « Et toutes mes jolies fleurs sont mortes, saloperies d’incompétents
  • Test moi ça ! – « Encore une fois, si tu ne sais pas te servir d’un outil, pose le par terre et va t’en. Ou au minimum, recule d’un pas et demande toi pourquoi tu es en train de t’infliger ça »
  • Le Culte du Cargo – « La première des Best Practices ? Savoir ce que tu es en train de faire avant de commencer à pisser du code. »
  • Méthodes Agiles – « Si tu pensais pouvoir utiliser les méthodes Agile pour éviter d’écrire une documentation correcte, alors tiens toi prêt à Agiler ton derrière pour calmer le client en colère. »

Oui oui, quand on est tout rempli de colère et de haine après la Nième décision stupide prise par un directeur quelconque, ça soulage d’aller lire ou relire tout ça 🙂

Ca inspire non ? Ca donnerait même envie de remodeler sa boîte autour de nouvelles valeurs 😉

(MàJ : 30/08/2010 – sp)