Le futur du décisionnel? Pas forcément là où on veut nous le faire croire…

Via Jason Kottke, cette jolie vidéo qui présente la chaîne d’assemblage de Tesla pour produire le Model S :

Prenez le temps de la regarder, elle est courte et elle vaut vraiment le coup d’œil.

Pour donner un peu de contexte, Tesla Motors est un constructeur automobile américain récent, spécialisé dans les voitures 100% électriques, lancé par Elon Musk, un Nikola Tesla moderne. Comme on le voit dans la vidéo, ils sont au somment niveau innovation.

Et un peu plus tôt, toujours via Kottke, il y a cette vidéo de l’usine d’assemblage NeXT, le constructeur informatique qu’avait lancé Steve Jobs avant de revenir chez Apple.

Ce qu’on peut voir dans ces vidéos, c’est pour une chaîne de fabrication le top en termes d’organisation, de flux de production, d’automatisation, d’intégration logistique, d’amélioration continue… (de lean manufacturing en sorte) qui mènent au top en terme de qualité et de temps de construction (3 jours pour une voiture, combien de temps pour un projet décisionnel?).

Et de là on peut faire le parallèle à notre activité de développement en décisionnel, sur SQL Server ou pas. Chez nous, pas d’usine logicielle, très peu de frameworks – ou qui ne font pas franchement rêver – le tout début de la génération automatique de code (il faut que je m’y mette), surtout des Best Practices transmises via savoir tribal et quelques Design Patterns (SSIS oui, SSAS et SSRS sont bien vides).

Ça c’est sur la conception, mais côté industrialisation on est aussi à la ramasse. Entre autres: un déploiement de toute une solution en un clic c’est encore trop risqué, un build complet ça n’est pas possible et ça ne sert surtout pas à grand chose, et si les tests automatisés fonctionnent bien en SQL OLTP, c’est encore dur de comparer des données en provenance de sources hétérogènes (SQL vs MDX vs DAX, à voir si ça n’est pas en train de changer).

On présente le futur de la BI comme étant un mix de Big Data, de Data Visualisation, d’in-memory, d’analyse prédictive, de stockage verticale ou encore de Cloud. Certes, mais je crois qu’avant cela il faudrait déjà qu’on rejoigne le présent du monde du développement logiciel. Ce serait déjà pas mal.

Deux points positifs cependant : on se rattrape sur les cycles d’amélioration continue : côté plateforme (base de données des bugs, templating, reporting sur l’usage et les performances…) et côté équipe (revue de code, plan de formation, plan de carrière, suivi des objectifs…). Et également avec la verticalisation, à savoir : on construit une fois, le plus proprement possible, et on réutilise sur d’autres projets qui utilisent les mêmes applicatifs sources. Mais ça ne marche que dans les marchés où les progiciels utilisés sont toujours les mêmes (compta d’entreprise, RH, CRM…), marchés qui sont finalement assez rares.

A nous donc d’arrêter de courir après les dernières modes, et de nous concentrer sur ce qui est vraiment important pour la croissance de notre « science » (dit-il tout en préparant un article sur Azure – spoiler : le IaaS c’est trop bien ;)).

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!