4 liens rapides pour la semaine (2012-05)

Je triche et j’en rajoute 2 pour rattraper la semaine dernière 😉

  1. Kevin Meyer d’Evolving Excellence sur Apple et sa chaîne de production. C’est très intéressant de voir le problème du côté des experts du Lean, ça remet les choses en perspectives.
  2. Via Marco Arment, une excellente réponse de Michael Wolfe à pourquoi les estimations et plannings de développement sont toujours à la ramasse.
  3. Mike Masnick de Techdirt sur les problèmes de corruption du gouvernement américain à travers le lobbying.
  4. Derek Edwards sur son blog Progressive Transit qui démontre que ce sont les voitures qui tuent les villes.
  5. Patrick McKenzie de Kalzumeus avec un très bon article sur la négociation salariale. A lire avant vos prochains entretiens!
  6. Enfin, Colin Percival qui repart de l’incident cat.jpg chez 37 Signals pour nous donner un excellent conseil sur comment designer ses systèmes. J’en reparlerai surement plus tard.

______________________

<< Semaine PrécédenteSemaine Suivante >>

Modélisation dimensionnelle : La révolution vient d’Italie!

Marco Russo (Blog | Twitter) retrouve son compère Alberto Ferrari (Blog | Twitter) pour mettre à jour son célèbre PDF gratuit The Many to Many Revolution.

Ça parle many to many, évidemment, en UDM (SSAS Classique) et en Tabular (BISM mode PowerPivot) autour d’une dizaine de cas fonctionnels classiques. C’est top!

C’est un document à lire / conserver sous le coude pour tous les consultants décisionnels qui s’orientent vers de l’architecture applicative, c’est à dire le bon design des modèles dimensionnels pour répondre correctement et efficacement au besoin métier.

Comme d’habitude avec les PDF et livres des compères, c’est super bien écrit, très clair et avec plein d’exemples. Je recommande vivement 🙂

Update 10/11/11 : Annonce officielle de la mise à jour par Marco Russo.

4 liens rapides pour la semaine (2011-17)

Que du bon cette semaine!

  1. Ted Dziuba sur les problèmes d’Amazon en tant que plateforme Cloud (EC2/S3). J’aime beaucoup sa franchise.
  2. Andy Ihnatko sur comment rattraper une journée mal partie.
  3. Seth Godin: après les économies du « scale » (d’échelle), les économies du « small » (des petites entreprises).
  4. On commence avec une citation d’Einstein trouvée sur le blog de 37 Signals pour conclure avec Kevin Meyer sur le cout absurde de la complexité.

______________________

<< Semaine PrécédenteSemaine Suivante >>

Des lignes et des colonnes

Je me suis fait une drôle de réflexion ce matin en lisant cet article d’Alex Payne (un des premiers ingés de Twitter, maintenant CTO de BankSimple), et plus particulièrement ce paragraphe:

Even the most bureaucratic of technologies can’t be claimed to be un-opinionated or free from our values. The lowly SQL database, workhorse of dismal trades like accounting and business analytics, is theoretically “value-neutral” to the data it stores. Yet, in structuring data into rows and columns of particular standard types, a set of values emerges that dictates what information is and how it should be stored and queried.

Traduit grossièrement:

Même la plus basique des technologies est affectée par nos valeurs et nos opinions. La simple base de données SQL, moteur de basses besognes telles que la comptabilité ou l’analyse business, est en théorie neutre en valeur vis-à-vis des données qu’elle héberge. Pourtant, en structurant les données en lignes et en colonnes de types standardisés, un ensemble de valeurs apparaît et dicte ce qu’est l’information et comment elle doit être stockée et requêtée.

C’est tellement vrai!

Pour étudier un événement à travers un modèle relationnel, un modèle en étoile, on le force à prendre une forme qui ne lui est pas forcément naturelle. La question devient: quelle est la valeur de l’analyse si pour la réaliser il a fallut tordre les faits et les conformer à un modèle artificiel? On retourne ici en plein problème de « legibility » dont je parlais tantôt.

Alors évidemment, étant donné que la plupart des phénomènes que l’on doit modéliser dans l’entreprise sont artificiels, il est facile de les modéliser en utilisant un processus artificiel. Un flux comptable, un portefeuille financier, une masse salariale, une chaîne de production… ce sont des éléments inventés de toutes pièces par l’homme et qui donc se conforment facilement dans une base de données.

Mais quand on étudie des phénomènes plus libres comme des courants d’idées sur Internet, la manière dont les sociétés s’organisent et se désorganisent, la mode… les relations humaines en somme, et bien cette mécanique se grippe vite. C’est surement la raison pour laquelle la plupart les gros acteurs sur le web, les journalistes et bloggeurs data ou encore les chercheurs en sciences sociales, n’utilisent que très peu les bases de données SQL et préfèrent le NoSQL, BigData et les nouveaux outils de visualisation (R & co).

Il suffit de voir les résultats de leurs études sur FlowingData ou Information is Beautiful, et de considérer l’effort que cela prendrait de faire certaines de ces analyses sur une plateforme décisionnelle classique, quand c’est possible, pour bien prendre conscience du poids que nous impose le modèle relationnel.

C’est une état de fait tellement évident qu’on l’oublie trop souvent lorsque vient le moment de modéliser un nouveau système décisionnel. Or certaines activités de l’entreprise comportent des éléments à la limite du modélisable, des éléments pourtant cruciaux à la compréhension globale de l’activité. Je pense par exemple aux relations clients ou aux ressources humaines. Sur ces domaines il faut donc être particulièrement prudent, se souvenir de ces limitations, et prévenir les utilisateurs des limites de l’outil à analyser un phénomène qui par définition ne peut pas être modélisé correctement.

4 liens rapides pour la semaine (2010-41)

Et hop:

<< Semaine PrécédenteSemaine Suivante >>

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!