Tag BI

Michael Stonebraker casse la baraque!

Fleid Laisser un commentaire

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)

Fleid 4 commentaires

(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)

C’est parti!

Fleid 4 commentaires

Plus tôt je vous décrivais rapidement mon métier. C’est une description très artificielle, de celle que l’on fait quand on se présente en entretien chez un client pour gagner une mission.

Je vais quand même prendre le temps d’aller plus loin, de préciser ce qu’est le job de consultant, puisque c’est autour de ces activités que va se structurer ce blog, son contenu.

Pour moi dans ce job il existe 5 grandes facettes :

A – le développeur : celui qui exécute

C’est la partie du job dans laquelle on réalise, on fabrique, on produit…  Pour moi un bon consultant sait réaliser, même si ce n’est pas sa tasse de thé, même s’il ne le fait plus ou que très rarement. S’il ne sait pas faire, s’il n’a jamais fait, à mon sens il ne pourra pas assumer les rôles que je décris après. C’est donc manifestement pour moi la partie la plus importante, sans laquelle rien ne se passe.

  • Un projet sans développeur ne se réalise pas !

B – le designer : celui qui imagine

Avant de pouvoir faire, il faut concevoir ce qu’on va faire. Il faut entendre le besoin client (dans ma salle de bain il me faut une serviette qui absorbe mieux !), comprendre les intentions réelles sous-jacentes (quand je me lave les cheveux, ma serviette ne les sèche pas vraiment bien !), et imaginer une solution qui résoudra le problème et non les symptômes (un sèche-cheveux par exemple, à comparer au besoin initial…).

  • Un projet sans designer se réalise mal – qualité foireuse, périmètre non couvert.

C – le chef de projet : celui qui facilite

Attention à la vision franco-française du chef de projet qui le positionne comme un petit chef ! Un chef de projet, c’est le chef d’un projet. Un projet, ce sont des powerpoints, des docs, des deadlines, un bout de code, et 3 serveurs. Les êtres humains qui travaillent sur le projet ne sont pas le projet. Donc un chef de projet n’est pas un chef de gens, pas un manager. Le vrai job d’un chef de projet est de rendre possible et faciliter au maximum les contributions des gens qui participent au projet. Il élimine la résistance à la contribution, mais il ne dirige rien ! Je n’invente rien ici hein, confère Scott Berkun ou Joël Splosky.

  • Un projet sans chef de projet est en retard, hors budget, ou ne se réalise pas.

D – le testeur : celui qui garantit

On ne peut pas faire de la qualité sans prévoir une phase de tests soutenus des livrables. C’est un métier à part entière, que je trouve vraiment trop sous-représenté dans le monde du décisionnel. Je n’ai pas encore vu de SSII ou boîte de conseil qui disposait d’une petite équipe de testeurs, transverse, bien équipée, pour aller sur chaque forfait valider ce qui était livré. Pourtant le coût peut tout à fait être intégré à la prestation et la valeur ajoutée est immédiate!

  • Un projet sans testeur c’est un projet où les consultants sont en fuite dès le PV de recette signé, attention quand vous irez voir sous les tapis…

E – le service après vente : celui qui accompagne

Cette partie tout le monde l’oublie tellement souvent que moi-même j’ai faillit pour cet article! Fabriquer c’est beau, mais livrer proprement, accompagner les utilisateurs, remonter les anomalies, faire accepter le produit, c’est 90% de ce que le client va percevoir. C’est bien plus que 3 slides poliment vendus comme de la conduite du changement. C’est s’engager sur le long terme, et en faire la preuve. Rien ne sert de se battre pour signer de nouveaux clients quand les anciens sont tellement contents qu’ils continuent à vouloir signer avec vous!

  • Pas de service après vente, pas de relations à long terme avec le client

Ce découpage des rôles n’est pas nouveau, encore une fois je n’invente rien: il n’y a qu’à voir toutes les grilles d’évaluation des consultants lors des entretiens annuels.  Et évidemment ce découpage ne s’applique pas qu’au décisionnel.

Les 4 premières facettes sont 4 professions classiques de l’IT. Si le consultant décisionnel est au milieu de tout ça, c’est parce qu’en général il travaille en parallèle sur des petits projets (1 à 6 mois) dans des petites équipes (2/3 personnes). Dans ce genre de conditions, tout le monde doit être ouvert et capable d’assumer un peu tous les rôles. La cinquième facette, c’est moins une profession qu’une attitude un peu trop rare à mon sens.

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