Agile ou contortioniste?

Pourquoi la méthode Agile a du mal à s'imposer dans les projets informatiques?
Une réponse intéressante à cette question a été postée sur le site DZone. L'auteur explique que que le client trop impliqué par Agile, se comporte comme s'il ne voulait pas qu'on lui reproche le disfonctionnement de l'application qu'il a contribué à spécifier. Plus crûment, il ne veut pas être blâmé en cas de problème. D'où vient ce sentiment?
Le plus souvent, une solution informatique en entreprise est imposée plus que choisie. Dès lors, elle cesse d’être une solution pour devenir un fardeau. La vision simplificatrice de l’entité « Client » occulte tous les aspects humains entourant la réalisation d'un projet.
Agile est une méthode pragmatique, bâtie sur l’hypothèse d’un monde faillible et d’un contexte humain contraint et donc peu coopératif et peu constructif par nature. Cette méthode a brisé la linéarité irréaliste de Waterfall en petits incréments, dont le but est de faire apparaître les imperfections, le plus tôt possible.
Voici un exemple type d'un dialogue Agile entre Marlene, du service de Gestion et Fred, un développeur:
F: Voici ma compréhension de ce cas d’utilisation. Êtes-vous d’accord ?
M: Oui.
F: Alors passons à la réalisation…. Qu’en pensez-vous maintenant ?
M: Ce n’est pas bon, vous n’avez pas bien compris ce que je voulais dire.
F: Pourtant je l'ai écrit et vous l’avez relu… Recommençons…. Qu’en pensez-vous maintenant ?
M: C’est beaucoup mieux. Il reste deux trois détails
….
M: Là c’est parfait !
Une fois l’application mise sur rails, on se rend compte que ce cas d’utilisation mérite d’être revu. Il faut refaire appel aux service de Fred et Marlene qui avait validé ce cas, risque d’être pointée du doigt et le vivra mal.
C’est de cette situation que souffre Agile. Le fait que le client s’implique à ce point dans le processus de développement et le risque qu’il en soit blâmé. Ceux qu’on doit blâmer, traditionnellement, ce sont les fournisseurs, non ?! Pourtant Marlene ne devrait pas avoir de soucis à se faire, l'éventualité de redévelopper un cas d'utilisation fait partie d'Agile et ne coûtera pas plus chère à l'entreprise.
Agile remet en question les situations schizophrènes comme par exemple: le client ne maîtrise pas son métier et ne peut pas l'admettre et le fournisseur n'a aucun moyen de lui soutirer des informations et ne peut pas s'en plaindre. Alors on fait avec... Une situation Ubuesque qui a mené en deux décennies, à une belle pagaille dans les SI.
Alors on tente de remplacer cela par un processus qui répartit les responsabilités ou, disons, en crée là où il n’y en avait pas auparavant. Une méthode qui tient compte de l'imperfection des hommes et des logiciels pour peut-être moins de stress inutile dans les projets.
Un projet ne peut être quantifié seulement par une durée, un budget et un taux de cas d’utilisations couverts. Il faudrait y ajouter une composante que nous avons totalement occulté : la sérénité.
J. Stiglitz a introduit un indicateur de « bien être » dans l’évaluation du PIB, ce qui révèle que des pays supposés riches ne le sont pas réellement. Pourquoi ne pas en faire autant pour les projets informatiques ? Cela révèlera peut-être que certains projets sont plus aboutis que d’autres, même si la sacro-sainte « deadline » n’a pas été respectée.

L'interface "est" le système

C'est en tout cas ce qu'affirme Vinayak Hegde dans la liste des 97. Dans cette même liste on peut lire une contribution de Einar Landre qui affirme pour sa part que l'architecte doit se focaliser principalement sur l'interface.
Le premier évoque la relation de l'humain avec le système, le second parle de la relation des systèmes entre eux. Peut-on établir un parallèle?
Dans ces deux affirmations, l'interface joue le rôle d'intermédiaire dans l'établissement de relations.
Dans la culture populaire, un agent intermédiaire peut faire ou défaire une bonne entente, quelle que soit la bonne foi des deux parties.
Pourquoi alors cette confiance en un intermédiaire incontournable? Quelle est la pérennité d'une telle association? Réponse: aucune des parties prenantes à la relation ne veut s'adapter à l'autre, car cette adaptation induit une dépendance. Autrement dit, chaque partie portera en elle, une définition de l'autre. L'intermédiaire devient alors un facilitateur!
Lorsque les systèmes s'interfacent entre eux, on parle de "découplage". Lorsqu'ils s'interfacent avec des humains, on évoque... "l'intuition". Dans les deux cas on fait appel à l'agent adaptateur.
Les systèmes entre eux, pour réduire leur dépendance, sont conçus en faisant appel à des modèles respectant les principes fondamentaux que sont la Séparation des responsabilités et l'inversion de contrôle. Quant à l'humain, sa communication avec le système passe par l'image au sens figuré, que lui retransmettent ses sens. Les interfaces se sont donc adapté à ce mode de communication: vue, ouïe, toucher, (goût et odorat?). Il y a quelques années elles étaient minimalistes: clavier, écran et symboles, ce qui nécessitait un effort cérébral important pour mémoriser l'association des symboles informatiques au monde réel. Au fil des années, de plus en plus de sens sont stimulés et la symbolique disparaît peu à peu: la communication est devenue graphique, s'est colorée, animée et sera bientôt holographique. L'action passait par le clavier, elle est devenue tactile, orale... bientôt télékinétique?
Nous déployons de moins en moins de moyens rationnels pour communiquer avec le système, qui pour sa part nécessite de plus en plus d'intelligence pour rendre possible cette simplification. Ne sommes-nous pas en train de nous atrophier à l'avantage des systèmes que nous concevons?
Disons que notre intelligence change; nous évoluons vers un futur plus heuristique que rationnel.
Un jour, doués de cette nouvelle forme d'intelligence, nous finirons par concevoir des systèmes qui seront intelligents, certes d'une intelligence à l'image de notre passé d'humain atrophié, mais alors une nouvelle étape sera alors franchie, celle où interfaces et systèmes se confondrons.

OWF!

Il y'a quelques jours, a eu lieu l'Open World Forum. Si vous y étiez, vous auriez remarqué que le perfecto en cuir de Simon Phipps tranchait franchement avec le costume-cravate du DSI de Sanofi-Aventis :-)
Il ne s'agissait pas d'une énièmme messe d'évangélisation de l'humanité à la voie sacrée de la FSF, avec RMS en post-babacool, pronant l'amour du software libre et le rejet de la vile monaie! Non, il s'agissait d'un autre type d'évennement, un show orchestré par des acteurs aguerris aux règles du business qui présentaient leurs solutions. De vraies solutions robustes; concurrentes directes de solutions commerciales, pour des utilisations stratégiques en entreprise: Cloud Computing, Virtualisation, BPM, BI, CMS...
Ce forum a soulevé de nombreuses questions de fond:
Comment cette culture, hérétique il y'a dix ans, est-elle devenue aujourd'hui une réelle alternative? Est-ce mimétique ou conjoncturel? Quel est l'avenir du logiciel libre face au logiciel commercial? Comment transformer une solution Open Source en opportunité business?
Je n'ai pas trouvé de réponses à toutes ces questions. J'ai cependant observé que la curiosité a disparu pour laisser place à une véritable adoption, réfléchie et pragmatique. Les DSI présents (Bull, Sanofi-Aventis, Safran, PriceMinister...) se sont tous déclarés comme déjà utilisateurs de solutions Open Source et prêts à considérer les offres; du moment que la performance est au rendez-vous. La révolution appartient déjà à l'histoire!
La gêne perceptible, car il y'en a, est due au fait que l'Open Source expose beaucoup plus la responsabilité des dirigeants. Point de contrat commercial exhorbitant, adossé à des clauses telles que que seules de puissantes firmes logicielles peuvent se permettre de parapher. L'Open Source ramène aux fondements d'un métier, de notre métier: la compétence, la passion, l'honnêteté. Aucun dirigeant n'est sûr de disposer, dans son projet d'intervenants sûrs, partageant ces valeurs. Alors, il préfèrera les firmes. A grand renfort de communication, elles ont imposé à notre subconscient l'image de la perfection. Personne ne reprochera à ce dirigeant de s'être mépris en choisissant une perfection admise par tous.
Seulement voilà, tout cela est en train de changer, la maturité de ce métier explique de moins en moins la délégation de responsabilité. Les défaillances répétées des firmes ont érodé définitivement le mythe de la perfection. Nous redescendons vers une réalité moins brillante: les paradigmes sur lesquels sont construites les nouvelles architectures d'aujourd'hui ont moins de dix ans d'existence. Alors faisons profil bas, dénouons le nœud de notre cravate et comme Simon Phips, revêtons notre blouson en cuir de baroudeur de l'informatique, abandonnons notre égo et tentons de construire, enfin, des systèmes par la seule force de notre intelligence.

L'art de la maquette

Lors d'une visite de la Sagrada Familia à Barcelone, j'ai été frappé par l'audace de Gaudi. Oser reproduire les frondaisons d'une forêt dans une cathédrale pour exprimer des sentiments abstraits: l'élévation, l'origine de la vie, la beauté maîtrisée de la nature et sa copie inachevée par l'homme. Audacieux!
Comment peut-on oser la réalisation d'oeuvres monumentales en gardant une totale assurance dans ces créations? Comment peut-on se permettre de telles audaces?
La réponse je l'ai eu un peu plus loin. Alors que je m'avançait dans la crypte je me suis retrouvé devant une reproduction inversée en structure de fil de fer de la Colonia Guëll. De petites bourses de sables maintenaient les arrêtes vers le bas en augmentaient la courbure de leur arc en fonction de leur poids. Le tout faisait penser à un hologramme sortie d'un logiciel de modélisation d'architecture. Gaudi avait, au début du 20ème siècle, inventé la maquette 3D!
Pourquoi cette structure de maquette complexe alors que du plâtre, comme il était d'usage à son époque, aurait suffit? Les maquettes en dur, il en a construit plusieurs, encore bien conservées à ce jour. Celle qui m'a attiré donnait au visiteur, une sensation de légèreté, une cathédrale immense, flotant dans les airs, comme les colonnes de la Sagrada, semblables à d'immenses arbres dont les sommets s'élèvent vers le ciel pour soutenir le plafond de la cathédrale. Tout un symbole... Gaudi ne voulait pas seulement modéliser une forme, mais un concept! Il tentait d'approcher et de "peaufiner" l'émotion que susciterait son oeuvre une fois terminée.
Lorsque l'on opère un changement dans les systèmes d'informations, nous réalisons ce que nous appelons des POC. Ces derniers, comme leur acronyme l'indique, doivent représenter un concept et non pas un sous ensemble de l'architecture finale. Le plus souvent nous nous contentons d'y tester des procédures d'installation, nous passons ensuite à la réalisation et nous nous étonnons de découvrir d'énormes disfonctionnements pendant le projet. Nous aurons non seulement perdu tout l'intérêt d'un POC, mais en plus, nous scellerons à jamais toute tentative de réarchitecture ou même de compréhension ou de modification future.
La plupart du temps, le système d'information est vu comme un agrégat de logiciels et de matériel plutôt que comme un ensemble de concepts.
Les partisants de SOA honnissent l'architecture en "silos", Je trouve cette image très éloquente... passer du silot à la cathédrale ne revient-il pas à délaisser l'alimentaire pour le spirituel. OK, me direz vous, mais seulement le dimanche!

Corrélation VS Causalité

Un jour, j'ai eu à traiter un incident de production qui s'est déclaré sous la forme d'une application de production qui s'est brusquement ralentie au point de ne plus fonctionner.Dans le même temps, un serveur hébergeant un service utilisé par cette application s'est arrêté de fonctionner.

Déferlement d'e-mails, cacophonie de sonneries de téléphone et confusion généralisée. Que faire?! Quelques redémarrages de services plus loin et le système était reparti tant bien que mal.
De par sa rareté, le problème était difficile à reproduire. Une démarche simpliste dans ce cas, est de tenter plusieurs interventions sur les différents services impliqués, dans différents ordres pour tenter d'en déduire la séquence fatale. Peu efficace. Cette Méthode empirique s'appuie sur la dépendance intuitive entre des phénomènes.
La seule conclusion à laquelle nous aboutissons (permettons nous un peu de probabilités), est que les variables aléatoires correspondant aux éventualités d'occurrence d'un résultat sont liées entre elles plus ou moins fortement. Cette liaison s'exprime, dans la théorie de la probabilité, par une corrélation définie par son coefficient. Plus ce dernier est élevé plus forte est cette liaison.
La corrélation ne suffit pas pour se prononcer sur ce que l'on tente de vérifier réellement: une causalité! La modéliser n'est pas une mince affaire!
Introduisons un autre niveau de probabilité: celui concernant l'occurrence de relations de causalité entre les variables aléatoires. Nous obtenons un graphe (de causalités) et une table de probabilité. Le tout est appelé: réseau Bayésien.
Dans ce graphe les relations de cause à effet ne sont pas déterministes mais probabilistes. Nous n'exprimons plus une cause mais une probabilité précise qu'un effet soit du à cette cause.
Appliqué à notre problème, cela nous aurais permis d'exclure les fausses pistes jusqu'à se rapprocher de l'origine du problème.
Dans une architecture distribuée modélisée par un graphe acyclique fortement connexe, les nœuds représentent des services (ou des serveurs) et les arcs sont les protocoles réseau les reliant. Nous disposons d'une connaissance (le savoir empirique cumulé par notre expérience sur cette architecture) et des inférences (observations intuitives sur notre système). Comment vérifier ces inférences? Posé ainsi, le problème se modélise de lui même en réseau Bayésien.
Combien de fois avons nous entendu des phrases contenant des termes comme: "très probable", "peu probable"... et combien de fois nous en avons été peu convaincus, nous avons cependant refermé le dossier par manque d'outils, mais aussi, avouons le... par paresse ;-)

Bonne année 2010!

"Souviens-toi que le Temps est un joueur avide
Qui gagne sans tricher, à tout coup!" Charles Baudelaire

C'est ainsi que commence l'exposé de Francesco Cirillo, intitulé: "La technique du Pomodoro".
Pomodoro signifie "Tomate" en italien. Ce fruit importé des amériques avait à l'époque la couleur jaune dorée, les italiens le baptisèrent "Pomme d'or". Le Pomodoro est aussi ce minuteur de la forme d'une tomate, gradué que l'on trouve souvent dans les cuisines. F. Cirillo a choisi ce nom d'objet anodin pour baptiser sa technique de gestion du temps.
Cette technique vient du constat suivant: nous ne savons pas estimer la durée de ce que nous accomplissons.
Selon Bergson, la perception du temps n'est pas celle d'une durée mais celle d'une succession de situations simultanées. Seule la mémoire permet d'estimer la durée entre deux successions. Cette durée est donc subjective.
Notre dépendence au temps est telle qu'une réalisation même aboutie peut être perçue comme inachevée, de par le caractère subjectif de la durée que nous y avons consacré. Ainsi, nos tâches journalières se suivent et le goût d'inachevé est chronique.

Faut-il reconsidérer notre perception du temps?

C'est en tout cas l'idée de la technique du Pomodoro basée sur une décomposition fine des tâches, bornées dans un intervalle de temps fini et mésurable (grace au minuteur). Cette technique ne s'arrête pas là, elle nous impose aussi des moments de réflexion ou de "feedback", ne serait-ce que pour apprécier, pour une fois qu'une tâche planifiée soit terminée...dans les temps. Ainsi, s'opère l'association dans l'esprit, des deux notions d'achèvement et de durée. On aquière alors la faculté de percevoir le temps en unités de tâches, en réalisations et non plus en positions simultanées des aiguilles d'une horloge.

Quant aux autres résolutions, inspirez-vous de la liste d'Andy Lester dans PragPub:

• Soyez positifs
• Améliorez votre expression écrite
• Soyez pertinents sur votre CV
• Arrêtez d'être omniscient
• Evitez de dramatiser
• Surveillez votre cote sur Internet

et j'ajouterais ... faites simple!

Gold rush

Récemment, un ami me disait toute la déception que lui avait apporté Java. Qu'il avait abandonné son vieux C pour se plonger dans la nouveauté de l'époque, pour se rendre compte qu'il était temps de renoncer.

Au début, mus par un enthousiasme euphorique, mon ami, tout comme des foules de développeurs chevronnés et d'apprentis gourous, se sont rués vers le Klondike de l'informatique de la fin des années 90: Java.

La majorité de ceux qui ont connu le Klondike, à en croire London, sont revenus, fourbus, alcooliques, avec comme seul gain, une pépite porte-bonheur en pendentif. Ceux qui ont connu Java ont eu un sort moins dramatique, quoique la déception a été à la hauteur des attentes, après quelques cycles interminables de Garbage Collector.

Cet ami qui se plaignait de Java, a aussi admis que ce langage lui a facilité l'apprentissage de la conception par objets et la notion de "Thread".

"Apprendre"…depuis la renaissance et jusqu'au début du 20ème siècle, les familles nobles apprenaient à leurs rejetons le grec et le latin. Non pas pour demander une adresse ou le chemin des toilettes dans un restaurant, mais juste pour… se distinguer. Il était alors de bon aloi d'auréoler son allocution de citations de Platon et de quelques proverbes latins.

Ce genre d'apprentissage élitiste avait pourtant une origine bien plus sérieuse. Les savants de la renaissance lisaient les écrits de leurs prédécesseurs grecs et latins, pour apprendre sur les réflexions anciennes et créer le système de pensée, qui distingua plus tard le siècle des lumières. Ces deux langues ont donc été perçues durant longtemps, comme vecteurs de savoir.

Ce mouvement est similaire à l'apparition de l'algèbre dans les démonstrations de physique du 19ème siècle. Grace à Newton, l'emploi d'équations différentielles s'est démocratisé et a ouvert la voie à de nouvelles théories mieux armées pour formaliser les observations informelles de Galilée. Cela a poussé, plus tard, des générations de chérubins, futurs apprentis nobelists, à verser dans l'étude du langage du moment, clé de toutes les portes de la science: les mathématiques.
Le grec et le latin ne sont plus appris à l'école. Sur des projets internationaux, le pragmatisme est de rigueur; on parle donc Globish! De même, les mathématiques sont de moins en moins considérées comme un passeport pour l'avenir social des enfants. On préférerait qu'ils apprennent le Jazz, la voile ou le Thaï-Chi.

Qu'adviendra t-il de Java?
Java est une langage qui s'inscrit dans la lignée des accélérateurs d'apprentissage. Il a démocratisé la conception par objets et par patterns. Il a permis d'élever la syntaxe des langages informatiques à un plus haut niveau, permettant ainsi de réduire la courbe d'apprentissage, de notions restées trop vagues même dans l'esprit de gens qui prétendaient le contraire: threads, accès concurrents, programmation réseau…etc
Nous sommes sûrs aujourd'hui que les langages informatiques modèlent le processus de pensée et donc d'innovation. Nous savons aussi que la richesse syntaxique et conceptuelle d'un langage, rendent réalisables des rêves d'architectes. Java fait partie d'une famille de langages dont les membres ont subi des mutations syntaxiques pour s'adapter aux mutations technologiques.
On continue d'étudier le grec et le latin à l'université…en plus d'autres langues. Les mathématiques sont toujours essentielles pour formaliser la science, en plus de la logique et des méta-langages.
Se demander quel langage sera celui de l'avenir, est réducteur de nos ambitions d'avenir. Il faudrait peut être se demander quels langages seront ceux de l'avenir. Cela conjugue d'emblée nos rêves au pluriel.

Solow VS Moore: entre paradox et conjecture

J'ai assisté récemment à un excellent séminaire autour d'ITIL et la gouvernance informatique, présenté par Romain Hennion de Thyses. Dans ce séminaire, qui se voulait un état de l'art, un débat a émergé en aparté de la présentation et a donné lieu à un échange que j'ai trouvé très riche d'enseignements.
Le sujet polémique portait sur la capacité réelle de l'informatique à dégager de la valeur. Selon Robert Solow, « L'ère de l'informatique est visible partout sauf dans les statitiques de productivité ». Selon Gordon Moore, le coût d'une puissance de calcul diminue chaque année et durant la même période, la puissance de calcul double pour le même prix.
Donc, d'une part, une puissance technologique en augmentation constante pour un prix de moins en mois élevé et d'autre part, le constat sévère que la productivité n'y est pas nécessairement liée.
La course au plus puissant et au plus complet aboutit souvent à la multiplication d'imperfections, qui finissent par éclipser l'effort de sophistication qui a été fourni en amont et donc, à moyen terme, cela fini par jeter le discrédit sur le produit, sur l'éditeur ou sur la technologie elle même.
Cela a été observé dans de nombreux projets informatiques voulant atteindre la perfection dès la première version. Il s'ensuit alors le sacrifice de la qualité sur l'autel des délais. Souvent, au tout début, lors de la phase de prospection, les utilisateurs n'en demandent pas autant. Ils acceptent, cependant les propositions alléchantes de l'éditeur qui leur propose beaucoup plus que la concurrence pour le même prix sur le principe de la loi de Moore. Il obtiennent un produit qui, finalement, doit souvent évoluer pour être corrigé ou optimisé provoquant retards et déceptions. Les utilisateurs ont alors des doutes sur la réelle valeur ajoutée du produit. Au mieux pour eux, ils factureront les pénalités de retard à l'outsourceur et au pire, ils seront obligés de reconsidérer leur stratégie en retard sur le calendrier. Tout cela est peu productif et rejoint le fameux paradox de Solow.
Un article de The Economist loue le retour au « POGE », le principe du "good enough" que l'on pourrait traduire par le "juste assez". Il s'agit d'un principe pragmatique tenant compte de la complexité des systèmes et de notre incapacité à prévoir tous les états-transitions possibles dans un système connexe. La stratégie consiste à réduire les ambitions fonctionnelles pour gagner en efficacité. L'exemple le plus frappant est le succès des NetBooks, ces ordinateurs portables sous-équipés mais remplissant parfaitement leur rôle: surfer sur Internet. Le succès a été immédiat.
Dans un monde qui se relève d'un cycle d'hyper-activité, il nous revient de discréditer le paradox et de réduire la conjecture.
Louable résolution, sommes nous tentés de dire...jusqu'à ce qu'une annonce d'Intel analysée sur le blog de Gilles Fontaine, nous apprend que le géant des circuits imprimés est en train de préparer une puce capable de doubler la puissance d'un processeur, pour le même coût avec une consommation d'énergie moindre. Ainsi, un datacenter de 200 serveurs, pourra être remplacé d'ici deux ans par un seul serveur.
Finalement, il faut se faire une raison: le moteur de la technologie est...la déraison!

Vous plaisantez monsieur Tanner

J'aime bien comparer un projet informatique à un projet de construction de maison. Juste pour souligner le...décalage.
Imaginez, une fois votre maison construite, que vous ne soyiez pas sûr que les murs puissent tenir debout plus d'un an. Alors, vous prévoyez une aile dédiée aux maçons. Ils habiteront chez vous pour qu'ils puissent colmater tous les jours les imperfections de leur propre travail.
Un exemple: aujourd'hui, le résultat de l'audit compris dans le contrat de TMA, indique que le bidet des toilettes du 1er, risque de s'effondrer dans le séjour au rez de chaussée. C'est très embêtant et ce n'est pas normal mais vous remerciez votre sous-traitant d'avoir été proactif. Car au fond c'est un peu votre faute. Vous auriez du opter pour du béton armé de bonne qualité avec un contrat de support « Platinum », au lieu de vous servir gratuitement dans la carrière désaffectée à ciel ouvert de votre région.
On vous dresse un devis et on vous propose un « backup »: durant les travaux, vous pourrez vous soulager chez les voisins. Le service est dégradée et externalisé mais reste dans la limite de la QoS. Une preuve quand même rassurante de résilience de votre SI.
Un jour vous décidez de construire une cabane dans votre jardin pour y entreposer votre matériel de jardinage. Devis de projet (hors contrat de TMA). Votre fournisseur en profite pour « expérimenter » une nouvelle organisation très à la mode, conseillée par un cabinet de consulting de renom (évidemment vous n'en savez rien). Le prix est cependant très compétitif. La raison: pour rogner sur le coût de la main d'œuvre, la cabane sera construite en Égypte et sera ensuite transportée jusque dans votre jardin. Une fois sur place, les rangements intérieurs ne vous conviennent pas. Ce n'est pas ce qui était prévu au départ, on ne vous avait montré jusque là que l'aspect extérieur. Retour en Égypte. Pour votre sous traitant c'est la banqueroute, les délais s'allongent, vous lui intentez un procès, vous vous séparez à l'amiable grâce à la brochette d'avocats qui vous ont coûté une fortune. Mais il y'a une note positive: vous avez retenu la leçon et capitaliserez pour le futur. Et puis vous êtes déjà heureux de ne pas payer des indemnités de résiliation de contrat. Vous optez pour une autre équipe de maçons. Ils vont construire la cabane directement dans votre jardin...et logeront chez vous entre temps. Pour leur commodité, vous allez aussi investir dans une machine expresso et un bon stock de dosettes, car vous avez d'autres projets en tête!
Là, le drame: vos finances sont en berne, le banquier bloque vos comptes et votre femme, excédée, demande le divorce. Vous quittez la maison sans vos boutons de manchettes après y avoir consacré toute votre énergie. Il ne restait que cette maudite cabane à terminer et vous auriez pu entamer la certification ISO 20000! C'est injuste! Mais vous allez rebondir. Vous actionnez votre réseu et fort de votre expérience, on vous propose un poste...de contermaitre dans une entreprise de maçonnerie. Avec un peu de chance, vous arriverez à séduire une riche bourgeoise qui vous accueillera sous son toit...dont vous aurez supervisé l'isolation.

YAM: Yet Another Middle Tiers Technology

Un article de JavaLoby a attiré mon attention. Encore une tentative d'Antonio Goncalves d'évangéliser les brebis égarées. L'article date déjà d'un an et ressemble à un cri du cœur: Pourquoi JEE 5, spécification de "rupture" n'arrive toujours pas à percer?! Je me suis posé la même question surtout quand je vois que la prochaine version JEE6 est déjà en gestation. Revenons à l'essentiel...
Qu'est ce qui représente la chose la plus précieuse pour une entreprise? Réponse: ses données et ses traitements métier. Il s'agit du bien le plus important que peut posséder une entreprise, son savoir faire. Il y'a souvent une association dans nos esprits entre la notion de bien précieux et la notion de coffre fort. L'entreprise possède son coffre fort pour y entreposer ce qui assure sa survie: ce coffre fort c'est le MainFrame! Même la direction générale sait ce qu'est un IPL. Non pas pour ces caractéristiques techniques mais surtout pour la frayeur tétanisante qu'invoque un arrêt du système informatique central. Il y'a toujours eu le MainFrame et le reste de l'informatique. Cette dichotomie est évidemment particulièrement palpable dans la distribution des budgets informatiques.
Jamais aucun dirigeant n'acceptera de sortir le capital de sa société hors du coffre fort, sauf pour le remettre dans un autre coffre fort au moins aussi sûr que le précédent. La technologie qui se substituera à ce coffre fort sera assurée d'une longévité enviable.
Unix a déjà perdu la bataille de ce créneau. Trop libre, conçu pour des esprits trop intelligents. Il a été transformé par ces pratiquants en technologie chaotique pour gourous rétifs et dispersés. il ne sera qu'une technologie de middle tiers, un système fourre-tout se battant avec d'autres systèmes alternatifs.
JEE est en train d'empreinter le même chemin. Un discours dispersé autour de cette technologie fait naître le doute dans l'esprit des décideurs. Son association avec Java et une politique de versions illisible, conjuguée à une suractivité communautaire et une multiplicité d'implémentations et de compléments sous forme de frameworks et autres APIs, fait penser que jamais la stabilité n'arrivera.
On ne sais plus si dans cinq ans, les choix d'architecture actuels ne seront pas complètement obsolètes voire hors de propos à cause d'une énième "rupture". On peut donc sans prendre de risque, déduire que JEE est condamnée à des projets "miettes" faute d'être suffisamment adulte pour se stabiliser et s'industrialiser.
Une réputation est très difficile à rectifier. Pour qu'une technologie survive, il faut que son discours soit homogène et que sa stratégie soit lisible. Il faut qu'elle se forge une réputation de stabilité, car la production n'admet pas l'incertitude et l'expérimentation. Il faut enfin que sa maîtrise soit assimilée à un savoir faire qui donnera naissance à un véritable corps de métier. Elle sera alors "bancable" et percera le marché vérouillé des coffres forts. Si JEE et Unix n'arrivent pas à redorer leur blason alors ils ne seront que des technologies de middle tiers...parmi d'autres.