Google will become a bank

To whom interrested in google architecture; have a look to this post.

Google operates 450.000 machines (BNPP operates 5000 servers), mastering all the hardware and software stack...
What amazes me the most is probably what is called the 'darwinian' algo. :
if you have a long task to launch, launch it several times in // on differents machines, get the result from the quickest one and kill the other running tasks...

Having said that, here is my bet on google's future:

• google is going to propose to host production sites, providing the fact they are the only ones on earth to operate such a wide cluster.
• existing companies are going to outsource their production to google; new companies will be first to jump.
• machines, networks, apps will be operated from within google datacenters
• this move might occur with an indirection level: software providers, such as Oracle, SAP might propose bundled hosted app relying on google's infrastructure
• Salesforce (leader in the hosted CRM market) is a perfect example of this; needless to say google will probably try to acquire it (this partnership is already engaged between the 2 companies)

Ultimaltely, google with become a Bank and host companies and people data pretty much as traditional Banks are keeping safe our money, and providing us with credit cards to use it.
Technically speaking, they is no reason why this won't happen (in fact that has already started), The only stopper is currently the level of trust and confidence one have in google.
Trust will then be the most valuable thing google is going to acquire in the next years.
Once trust will reach a critical level, everyone will jump in without any resistance.

Conclusion:

Google will become a competitor to BNPParibas in the coming years.
They will continue to draw people and market attention at an exponential rate; in // day to day life will become more and more digital; the conjunction of this two factors makes google a clear winner.

• BNPParibas can fight back:
• propose to its customers (corporate or consumers) some storage services, hosting services, technical services
• reeinforce BNPParibas' presence in the digital world, open a "second life" subsidiary
• open WIFI access points in every local agency
• With any new bank account provide, a mail, a blog, a video space, unlimited storage on BNPP servers, and sponsorize a mobile PC and an internet access
• your suggestion here...

Last question : when will this happen ?
soon.

Êtes-vous prêts pour le management 2.0 ?

Corsetée par un sur croît de procédures, la gestion de projet a tendance à oublier l'essentiel : les hommes. Un management « 2.0 » vise à recréer du lien. En s'aidant des nouveaux outils collaboratifs et des méthodes agiles.

Laurent Bédé, et Olivier Vallet, avec Stéphane Parpinelli et Xavier Biseul , 01 Informatique (n° 1896), le 16/03/2007 à 00h00

Un vent de révolte souffle parmi les chefs de projet. CMMi, Itil, Cobit, Six Sigma... Ils assistent, depuis quelques années - parfois sous la contrainte -, à une inflation de cadres méthodologiques. Des référentiels de bonnes pratiques qui visent à l'industrialisation des systèmes d'information, à la taylorisation des tâches et, en définitive, au mirage du zéro défaut. Or, la lapalissade est parfois bonne à rappeler, un projet reste et restera une affaire d'hommes. Ce qui fait les joies et la difficulté du management.

Ne gérer un projet qu'en fonction des risques présente un risque en soi. Un excès de formalisme, en figeant des organisations sans tenir compte du contexte et de ses évolutions, s'avère au contraire contre-productif. Comme l'expose ce site parodique ⁽¹⁾ qui épingle « les ravages de la pseudo-rigueur » . Une organisation qui éprouve des difficultés à mener à bien des projets aura pour réflexe naturel d'édicter une nouvelle procédure plutôt que de régler les problèmes sur le fond.

Aussi structurant soit-il, un modèle de certification qualité tel que CMMi montre ses limites en s'affranchissant des « risques humains » . Pour ce référentiel, les compétences sont interchangeables. Et, un départ en maternité, un coup de déprime chez un salarié, ou un turn over galopant, restent définitivement hors périmètre. Pourtant, la majorité des points de blocage d'un projet relèvent du management d'équipe.

En ajoutant un P, pour People, au CMM, le P-CMM tente de répondre à cette attente. Quasiment inconnu en France, ce modèle définit des recommandations dans le domaine de la gestion des ressources humaines - formation, communication, rémunération, reconnaissance... - au risque de calquer des concepts théoriques sur des relations humaines. Le management relève de l'inné et non de techniques universelles. Tous les Pert et Gantt du monde n'apprendront pas à un chef de projet à être chef.

L'émergence d'un nouveau mode de management

Face à ce constat, un management baptisé par certains « 2.0 » (2) - par analogie au web 2.0 qui remet l'humain au centre de la Toile - semble émerger. Plusieurs événements récents abondent dans ce sens. Le 5 décembre dernier se tenait une conférence grands comptes de Microsoft autour du travail collaboratif. Dans le cadre de son déploiement de SharePoint, Bouygues Télécom y a expliqué comment les utilisateurs ont constitué un groupe de travail pour une formation centrée non pas sur les outils de Microsoft, mais sur l'organisation et la gestion du travail personnel. L'opérateur s'est félicité également du succès sans pareil de cette formation, et des retours positifs qu'elle a suscités. Dans son dernier édito intitulé Itil et la gestion de la sécurité , Daniel Kervarec, directeur de la publication de Newsitweb.info , annonce, de son côté, la création d'une nouvelle rubrique « consacrée à la gestion des hommes » . Que le monde d'Itil, pilier des processus, s'intéresse aux hommes est révélateur.

Enfin, le 6 mars dernier se déroulait la troisième Active Directory Strategy Group dans les locaux de Microsoft. Après une demi-journée de présentation des solutions techniques autour de l'annuaire de l'éditeur et de la gestion des identités, la séance des questions/réponses se met en place. Une voix dans la salle : « Votre présentation est très opérationnelle, mais avez-vous une présentation fonctionnelle de l'Active Directory au sein de l'entreprise. Par exemple : Comment trouver les données qui l'alimentent ? Existe-t-il des connecteurs pour les bases RH ? » Réponse embarrassée d'un des consultants : « Vous avez raison, ce que vous dites représente 95 % du problème ».

S'aider des solutions du web 2.0

Les outils collaboratifs du web 2.0 peuvent concourir à cette révolution managériale. D'ores et déjà, les relations avec la maîtrise d'ouvrage (MOA) sont affectées.L'application proposée doit tenir la comparaison avec ce qui se fait de mieux aujourd'hui sur internet. Cette nouvelle « métaexigence » s'immisce dans les discours, les écrits, et alimente les non-dits.

La MOA souhaite-t-elle le même degré de personnalisation que le portail en mashup de Netvibes ? Le chef de projet doit savoir s'engager sur un niveau d'exigences raisonnable, faire preuve de diplomatie et de psychologie, et gérer les frustrations le plus tôt possible.

Par ailleurs, le développement 2.0 se complexifie. Il implique l'intervention d'une multiplicité de talents : designers, ergonomes, développeurs de frameworks, etc. En tant que manager, le chef de projet doit savoir recruter une équipe, en panachant ces divers profils et en les plaçant sur l'axe temps de son projet.

Et dans ce cadre, les outils existants ne suivent plus. Excel montre ses limites et Project est aussi adapté pour le suivi de planning qu'une carte routière en papier sur une moto de course. Le wiki et la messagerie instantanée peuvent être utiles, mais le développement véritablement collaboratif, lui, sort à peine des laboratoires - Jazz avec Eclipse, et Team System chez Microsoft, notamment.


Influencés par les pratiques des communautés open source, les développeurs pressent leur management à adopter les méthodes agiles (Scrum, XP).

Avec quels arguments le chef de projet peut-il convaincre sa DSI d'engager un projet agile ? Si, en parallèle, il est impliqué dans un processus qualité de type CMMi, on mesure l'ampleur du grand écart à accomplir. Il doit se convaincre d'abord que CMMi et méthode agile sont complémentaires, puis identifier un périmètre d'essai et faire une proposition d'expérimentation. Puis faire le bilan, et recommencer en mieux. Pourquoi pas en offshore...

Chefs de projet, rédacteurs en chef d'un jour

Une journée à jouer au journaliste avec des journalistes (des vrais) de 01.
Expérience passionnante au cours de laquelle le terme "chemin de fer" a pris un autre sens.

Résultat, un article co-écrit publié dans le post précédent.

Web 2.0, Chef de projet 2.0 ?

Non.
Le chef de projet transcende la technique sous jacente; peu importe que l’on ait à gérer un projet Web 1 ou 2, un projet client-serveur ou de datawarehouse, la posture ne change pas, les données en entrées et les livrables sont toujours les mêmes – exigences en amont, logiciel en aval - les facteurs externes et internes sont stables et maîtrisés.

L’expérience permet sans doute de nuancer un propos aussi tranché.
On peut défendre l’idée que le chef de projet 2.0 à part entière existe, reprenant à sa charge les rôles classiques comme « gestionnaire de relation avec la maîtrise d’ouvrage » ou « chef d’équipe » et avec des spécificités issues de la technologie ou simplement conjoncturelles.

MOA 2.0 ?
Les relations avec la maîtrise d’ouvrage sont affectées. La nature même du contrat passé entre les parties évolue.
Il ne s’agit plus seulement de produire un logiciel conforme aux attentes exprimées dans un cahier des charges, il faut aussi qu’il tienne la comparaison avec ce qui existe ailleurs, sur Internet en particulier.
Cette nouvelle « meta-exigence » est le plus souvent informelle ; elle s’immisce dans les discours, les écrits et alimente les non-dits. Le projet Web2.0 n’est plus uniquement engagé dans une course contre la montre, mais aussi en compétition avec l’Internet tout entier.
Et la compétition est rude.
Le Web est devenu la référence; les nouvelles exigences sont dictées par les réussites fracassantes des meilleurs sites 2.0 et les composants Ajax les plus riches en libre essai à quelques clics de souris.

C’est l’effet Casino.
Dans un établissement de jeu, la densité des machines à sous est calculée de façon à ce que le joueur soit en permanence bercé par la douce musique des pièces qui tombent. Jouer devient une condition suffisante pour gagner. Transposé au Web, ce syndrome se traduit par des d’exigences supérieures ou égales au meilleur de ce que l’on peut voir sur le Net - moi aussi, je peux gagner autant - mais en sous estimant la difficulté et le coût – pour gagner beaucoup, il suffit de jouer un peu - le résultat est le même qu’au Casino ; on gagne peu et rarement, en investissant toujours plus que ce que l’on avait prévu au départ.
Pire, s’il on essaie de jouer avec une machine qui vient de « payer » le jackpot, c'est-à-dire reproduire ce qui existe de mieux sur le net dans une application maison, on perd – à coup sûr.

Et il revient naturellement au chef de projet de faire en sorte que la production d’applicatifs de qualité, soit moins aléatoire et plus fréquente que le jackpot d’un bandit manchot.

Il doit faire preuve de diplomatie et de psychologie; la MOA veut le même graphe que celui de Yahoo! Finance ou le même degré de personnalisation que le portail Mashup de Netvibes ? Que lui proposer et surtout comment lui présenter ?

Le chef de projet doit savoir s’engager sur un niveau d’exigences raisonnables et négocier en amont le degré de nouveauté du périmètre technique et fonctionnel de son projet.
Ne pas se tirer une balle dans le pied en gérant la frustration le plus tôt possible. Proposer des expérimentations locales et cadrées en jouant la transparence des coûts. Revendiquer le droit à l’erreur sur ces expérimentations.

Face à ce nouveau défi, quels sont les nouveaux moyens dont dispose le chef de projet dans son rôle de manager d’équipe ? Quelles sont les nouvelles contraintes internes ?

Avec le Web 2.0, le développement se complexifie ; de plus en plus fréquemment on emploie à plein temps des designers, ergonomes et intégrateurs HTML pour assister les développeurs de gestion. Les développeurs de frameworks et experts de la sécurité sont aussi couramment des profils que l’on trouve dans ces équipes 2.0.
Le développeur orchestre est un vestige ; les métiers se spécialisent, signe d’une maturation de l’industrie logicielle.
En tant que manager, recruteur, le chef de projet 2.0 doit savoir construire une équipe, en équilibrant ces différents nouveaux profils et en les plaçant sur l’axe temps de son projet.
Cette multiplicité de nouveaux talents introduit une complexité nouvelle dans la gestion des dépendances entre les tâches d’un projet ; 100 jour.hommes à 10 développeurs ne correspondent plus à 10 jours de délais ; les outils de base ne suivent plus, Excel montre rapidement ses limites et Project est aussi adapté pour le suivi de planning qu’une carte routière en papier sur une moto de course.

Cette nécessaire diversité des profils exacerbe la dimension collaborative du travail. Et « collaboratif » est justement l’adjectif le plus associé aux concepts Web 2.0.
De ce côté-là, les outils suivent difficilement ; on pense naturellement au Wikki pour le référentiel de documentation ou de meilleures pratiques et à la messagerie instantanée comme nouveau média à mi-chemin entre le téléphone et le mail.
Mais le développement véritablement collaboratif, lui, sort à peine des laboratoires. Jazz chez Eclipse, et TeamSystem chez Microsoft par exemple. Pour l’heure, on en est encore à industrialiser les usines de développement basées sur des middleware de build automatique et d’intégration continue dont les usages et les outils sont généralement issus de la communauté open source.

Influencés positivement par les pratiques de ces communautés, les développeurs ont l’initiative de la méthode ; du ‘test-driven’ au ‘test-first’ pour arriver aux méthodes agiles, les producteurs de code pressent leur management pour la prise en compte de ces nouvelles pratiques.
Bien évidemment, la nature d’une application Web 2.0 et la gestion d’un projet en mode Agile ne sont pas directement liées. Néanmoins, c’est un fait, les développeurs promoteurs de méthodes Agiles sont le plus souvent ceux que le chef de projet rencontre dans cet univers 2.0.
Et au chef de projet de vivre un nouveau moment de solitude : avec quels arguments peut-il convaincre sa DSI d’engager un projet Agile ? Comment « vendre » le « time-boxing» de Scrum et son caractère adaptif plus que prédictif ?

Si en parallèle, il est engagé dans un processus de certification Qualité de type CMMi, on mesure l’ampleur du grand écart à accomplir.
A lui de se convaincre d’abord que CMMi et Agile sont complémentaires, puis d’identifier un périmètre d’essai et faire une proposition d’expérimentation avec le même droit à l’erreur que s’il s’agissait de la mise en œuvre d’un nouveau framework. Faire le bilan, et recommencer en mieux.



D’un point de vue RH, cette spécialisation des équipes replace sur le devant de scène un vieux débat Franco-Français. Idéalement, le chef de projet 2.0 voudra s’entourer de développeurs experts ou au moins panacher son équipe avec des profils juniors et seniors.
Et quoi qu’en disent les grilles, on n’est pas expert à 25 ni à 30 ans. L’expert, celui dont le vécu permet d’emprunter le seul bon chemin parmi cent possibles, est nécessairement plus âgé ; il est le gourou, la référence sauf qu’en France, il n’existe pas.

Pourquoi ?

Parce que la fonction de chef de projet est une position hiérarchique plus qu’une fonction avec sa technique propre. On devient chef de projet, parce que c’est l’heure et parce que l’on a compris que c’est une étape obligatoire pour progresser dans l’entreprise.
Le résultat : des équipes avec des développeurs certes talentueux, mais inexpérimentés encadrées par des chefs de projets plus motivés par la reconnaissance que par le métier.

Rêvons d’un monde ou le développeur de 45 ans existe et s’épanoui au sein d’une équipe encadrée par un chef de projet communiquant et diplomate, favorisant le travail collaboratif entre des experts hyper-productifs et des jeunes à potentiel.

Le chef de projet 2.0 n’est pas une star ; il valorise la production de ses équipes et rend leur travail possible. Par tous les moyens.

Petit déjeuner SQLi sur Java / Swing

Un autre petit déjeuner; avec le groupe SQLi ou j'y ai présenté ReachPeople
Voici le lien de l'annonce de cette demi journée.

Ajax, Hector, et leur talon d'Achille

Laurent Bédé*, 01 Informatique (n° 1836), le 18/11/2005 à 00h00

C'est ainsi, la communauté informatique a besoin de ses jeux du cirque. Après l'affrontement pour le titre du meilleur mécanisme de persistance objet, place au combat que se livrent, d'un côté, les défenseurs du web enrichi et, de l'autre, les partisans du client lourd. Ce dernier regroupe l'ensemble des technologies dont le prérequis à l'exécution est le téléchargement du code de l'application sur le poste de l'utilisateur. On en distingue deux catégories : celles basées sur une machine virtuelle Java, et les autres. La première oppose deux bibliothèques de composants graphiques : SWT, promue par Eclipse - et IBM -, et Swing, poussée par Sun. La seconde héberge surtout Microsoft Winform . Net, Macromedia Flash, ainsi que tous les L4G propriétaires - Powerbuilder et Delphi en tête.

Il n'y a donc pas un seul client lourd, mais un ensemble d'environnements concurrents et incompatibles, qui se disputent le droit de rivaliser avec l'autre type de client - riche, celui-là -, porté par la technologie Ajax ⁽¹⁾ . ^.

Le client Java en panne de standard

La proposition de Sun se distingue nettement des autres challengers, comme le montre une récente étude d'Evans Data Corporation sur l'adoption des technologies. En 2005, Java/Swing arrive en tête des outils de développement pour client lourd : 47 % des développeurs interrogés l'utilisent, soit 27 % de mieux qu'en 2004.

Si ce rapport ne concerne que les Etats-Unis, au vu du choix de Fiducia AG, l'Europe pourrait confirmer, sinon accentuer ce résultat. Cet hébergeur allemand de logiciels bancaires, en mode hébergé, déploie son logiciel client Java/Swing de 120 Mo sur plus de 100 000 postes clients avec Java Web Start au travers de bandes passantes souvent réduites à 64 Kbit/s.

Swing, appelons-le Hector ⁽²⁾ pour la métaphore mythologique, serait l'alpha et l'oméga des interfaces riches et de la transparence du déploiement. Peut-être, mais pas en l'état, car Hector souffre de ne pas être spécifiquement dédié aux applications de gestion. A tel point que rien n'empêche de bâtir sur ses fondations une console de supervision de centrale nucléaire ou un simulateur de cockpit d'avion de ligne. En théorie, c'est un gage de souplesse. En pratique, le coût pour spécialiser cette bibliothèque à l'informatique de gestion est prohibitif pour les projets de petite et moyenne envergure. D'où la pauvreté de l'offre de frameworks répondant au problème. Et pour cause : il manque un standard dédié au client Java - à l'instar de J2EE pour le serveur -, qui pérenniserait des investissements nécessairement importants. La notion de « conteneur client lourd » reste à inventer, et son modèle de programmation avec.

Ajax écartèle le modèle MVC

Si Hector entre dans l'arène en quête d'une plus grande reconnaissance, Ajax, le populaire, harangue la foule en délire. Ce n'est pas un outil, mais un modèle évolutionniste, qui s'appuie sur les standards existants et promet d'élever le web au rang des meilleures interfaces homme-machine. Mais la puissance d'Ajax ne s'exprimera pas si facilement. D'abord, parce qu'il écartèle le contrôleur du fameux modèle MVC (Model-View-Controller) entre le serveur et le client, sans pour autant en spécifier de substitut. Ensuite, parce qu'il repousse le HTML, les feuilles de style CSS, le Javascript et l'invocation asynchrone XML aux limites de leurs implémentations propriétaires par les navigateurs. Enfin, parce que la pléthore d'outils estampillés Ajax n'est pas le signe d'une grande maturité.

Le HTML pourrait ne jamais atteindre la richesse génétique du client lourd. Le prix à payer pour enrichir une interface web avec Ajax est une fonction exponentielle de la valeur ajoutée. Swing inverse cette formule, mais augmente l'investissement initial.

Ironie de l'histoire, Ajax vénère trop de dieux, alors que Hector s'en cherche un désespérément. Si l'on en croit la mythologie, il n'y eut qu'un seul combat entre ces deux héros. Combat qui ne vit ni vainqueur ni vaincu : à la nuit tombée, ils échangèrent leurs armes et firent la paix.

(1) Ajax fut, après Achille, le plus vaillant des Grecs.(2) Hector fut le plus fort et le plus vaillant des Troyens.* directeur technique du projet AceTP chez BNP Paribas Securities Services.

Ce qu'ils pensent d'Ajax

Anicet Mbida, 01 Informatique (n° 1835), le 16/11/2005 à 07h00

Le sceptique : Laurent Bédé (BNPParibas Securities Services)

« Il ne faut pas enterrer le client lourd. »

« Le déploiement en client-serveur n'est plus un problème. Avec un nombre fini d'utilisateurs, des outils comme Java Web Start assurent un déploiement transparent. Fiducia AG, par exemple, a déployé automatiquement une application Java/Swing de 120 Mo sur plus de 100 000 postes. Derrière Ajax,il y a un bricolage incroyable. Même si les outils s'améliorent, les meilleures bibliothèques d'aujourd'hui atteignent à peine le niveau de ce que faisait Visual Basic il y a dix ans. Quel intérêt y a-t-il à rester centré sur le navigateur ? C'est le nivellement par le bas. Le client du futur, le téléphone, a depuis longtemps opté pour un modèle avec des applets. »

Petit déjeuner OCTO Technology sur Java / Swing à l'ATELIER BNPParibas

En partenariat avec Octo Technology, j'y ai présenté le framework client riche Java / Swing ReachPeople développé au sein de mes équipes entre 2002 et 2005 dans le cadre du project AceTP.
Page de l'agenda de cet événement.

ReachPeople Overview

ReachPeople est un framework Java/Swing developpé dans le cadre du projet AceTP par mes équipes. Je me suis investi dans sa conception et sa promotion à l'intérieur et extérieur du groupe BNPParibas. Le texte qui suit est la factsheet présentant ReachPeople.

ReachPeople: empower rich desktop client applications

ReachPeople is a framework for building rich client applications above Sun’s Java / Swing standard in such domains as finance, accounting, CRM, insurance and healthcare.

It is the solution of choice for replacing old proprietary client server applications and boosting poor usability of HTML Web like applications. It fits in any kind of architecture topology: client-server, n-tier, offline or standalone application.

ReachPeople bridges the gap between low level Swing APIs and the need of business applications developers to work with very high level rendering components and technical services.

It is crafted by people for other people: end-users, architects, developers and IT managers.

For end-users

A consistent desktop, a homogeneous look and feel, a standardized screen behavior, make application easier to learn and faster to use. Messages like errors and warnings are normalized, in terms of content and display.

A set of high level rendering business components give more control to users than ever:

• PowerTable that leverages on most common used features of spreadsheet softwares, while providing unlimited user customization capacity.

• Setting management let user customize each component individually, and save as many settings as needed.

• Selector is an overboosted combo-box for selecting one or more values, among virtually unlimited lists.

All graphical components are designed and tested to be keyboard driven, for maximum end-user productivity. Powerful surface controls and formatting abilities help users to correct typein mistakes, at the earliest possible time.

User’s performance is also adressed with the management of background tasks, keeping application usable while long-lasting operations only freeze affected GUI subpart. Low memory and CPU footprints let more room to retrieve more data from the server than you ever dreamed considering Web-based applications.

And the nightmare of deployment with first-generation client / server, or cross-browser Web applications is over: ReachPeople is Java WebStart™ ready.

For architects and developers

ReachPeople provides the backbone of a rich client application, with unified window collaboration scheme, and well-defined client / server conversation model.

This conversation model takes advantage of a thin invocation layer for hiding the underlying protocol(s) like JDBC, RMI, SOAP, HTTP. Of course, implementations are pluggable. As a benefit, it is possible to use remote invocation over HTTP for preserving existing Webapp architecture. Security concerns are handled through simple patterns and a pluggable architecture to fit in any security infrastructure.

A bi-directional, type-safe binding API provides a productive and innovative way to bind “model” objects to visual components. An internal message bus enables inter-windows communication.

Application tuning is taken to heart, with explicit error messages and fine- grained logging provided by the framework.

A complete documentation provides startup guide, know-how, FAQ, release notes, sample applications, javadocs, code samples, best practices and patterns.

For IT managers

ReachPeople meets high quality standards, with 96,000 lines of production-ready code (including 39,000 lines of comments) covered by more than 1000 unit tests. Those tests include “live” GUI testing with Abbot. With Cenqua’s Clover, measured code coverage is near 70%.

ReachPeople does not depend on any proprietary / commercial library, but well-recognized open-source libraries (with liberal licences), neither it sticks to one particular development environment.

It perfectly fits in a software factory and automated build process. The framework itself is built with Apache Maven.

ReachPeople has serious references. BNP Paribas successfully deployed it in production since March 2005. It empowers the AceTP project, the core mission-critical system of BNP Paribas Securities Services. With 500 screens and 200 developers, it is one of the biggest Swing/J2EE project in Europe. During an audit led by ATOS in 2005, ReachPeople has been recognized as a key factor of success.

Contact

Laurent BEDE – BNP Paribas Securities Services

See some screenshots below; the PowerTable in action:

La fin des bases de données relationnelles

Laurent Bédé* , 01 Informatique (n° 1821), le 30/06/2005 à 00h00

Le langage SQL a joué un rôle de précurseur en sacrifiant vingt années d'alternatives sur l'autel du « on peut sûrement faire mieux, mais c'est un standard, et on s'en accommode » . Au début des années 80, l'apparition des systèmes de gestion de bases de données relationnelles (SGBDR) offre un cadre structuré et normalisé aux données. La nécessité de travailler avec un langage standard d'interaction avec les données et de fournir l'accès à ces informations à un utilisateur lambda donne naissance à SQL. On assiste alors à une extraordinaire arnaque intellectuelle, en retombant dans le piège de logiciels toujours trop compliqués pour un néophyte, ou trop limités pour un informaticien.

Aujourd'hui, après le télescopage du client-serveur et du web, les architectures à la mode nous font marcher sur la tête. Ainsi, les données stockées en mode relationnel sont extraites en SQL, de façon à alimenter un modèle objet, qui doit être à nouveau mis à plat pour l'ultime conversion à des fins de représentations tabulaires. Vu sous cet angle, la question se pose de savoir qui, de la base de données ou du serveur d'applications, doit rendre son tablier.

D'un aspect purement pragmatique, il faudrait détruire la brique du milieu, supprimant la double distorsion (relationnel/objet et objet/représentation tabulaire), et par là même quelques décennies d'avancées technologiques. N'en déplaise aux conservateurs, je préfère une autre option.

Les serveurs d'applications prennent le relais

Car, en regardant de plus près, les SGBDR représentent « le » point faible des architectures à plusieurs niveaux. Risques d'indisponibilité, problèmes de performances, évolutivité trop verticale... Leur mode d'interaction n'est plus du tout en phase avec les standards de développement objet et XML. En outre, les futurs ingénieurs ne sont plus formés au SQL, et encore moins aux formes normales. Mais alors, si la base de données disparaît, qui prend le relais ? Les serveurs d'applications bien sûr. Un exemple : même si dans le monde Java, les premières spécifications des EJB Entity ont échoué pour donner naissance dans la foulée à JDO, d'un côté, et à Hibernate, de l'autre, elles proposent une façon ­ plutôt incompatible ­ de résoudre la différence d'impédance objet/scalaire. Peu importe, la bataille acharnée que se livrent les partisans des deux camps, tous ceux qui ont expérimenté ce mapping objet/relationnel (ORM), dressent un même constat : la différence se fait autour de la gestion du cache.

Un langage d'interrogation objet pour remplacer SQL

Une unification des ORM est attendue en fin 2005. Le cache, lui, restera encore longtemps loin de toute normalisation. Qu'il s'agisse de celui de niveau 1, propre à chaque session (ou transaction) qui assure qu'un objet n'est instancié qu'une seule fois ; ou de celui de niveau 2, qui propose des services de réplication transactionnelle interserveurs, de tolérance aux pannes, de gestion de conflit sur mise à jour concurrente, et, enfin, de tolérance à l'absence de base de données. Ce cache en écriture, réparti sur toutes les instances d'une grappe de serveurs d'applications, supprime de facto le goulet d'étranglement inhérent aux moteurs de persistance classiques. Un langage d'interrogation orienté objet remplace alors SQL ; la distorsion objet/relationnel est éliminée, et avec elle le mapping. Cerise sur le gâteau, on administre les composants exécutables et leurs données depuis une console unifiée. Les conditions optimales pour l'arrivée d'un mode de persistance asynchrone, distribué et à évolutivité horizontale et linéaire, se trouvent donc réunies. Une telle technologie peut donc ­ en théorie ­ prétendre se substituer au SGBDR et le reléguer au rang des bandes magnétiques d'archivage.

Bien entendu, tout cela n'en est encore qu'au stade préhistorique. Les fournisseurs se défendent en faisant la promotion du Datagrid ; d'autres mettent l'accent sur les développements Javaspace, JCache ou propriétaires.

* directeur technique du projet AceTP chez BNP Paribas Securities Services

Open source : demandez-en plus

Le choix d’un produit libre de renom diffère peu du travail à mener dans le cas de la sélection d’un logiciel commercial.

Mais les autres projets qui représentent une écrasante majorité, ne peuvent faire état ni de prestigieuses références en production, ni de la solidité de leur fournisseur ou de la qualité de leur support et courent le risque de ne jamais passer la barre de la simple curiosité technique; au grand dam de ceux à qui revient la responsabilité du choix et qui ne peuvent faire peser dans la balance que leur intime conviction et leur crédibilité. Heureusement, l’accès au code source de ces logiciels libres se révèle leur meilleur allié. Une simple revue de code, comme on le fait sur un développement maison, apporte des trésors d’informations de nature qualitatives et quantitatives.

Le code est-il lisible ? Est-il documenté ? Quelles conventions de nomages sont utilisées ? Quels patterns sont mis en œuvre ? Des tests unitaires existent-ils ? Quel est leur pourcentage de couverture ?

Pour se simplifier la tâche, on aura recours à une panoplie d’outils de mesure automatique – eux aussi en open source pour la plupart. Une fois les entrailles de la bête décortiquées, on s’attachera à étudier son environnement. Combien de développeurs contribuent à son évolution ? Les forums, les faqs sont-ils fournis et actifs ? Quels sont les autres projets où librairies dont il dépend ? Quels sont les autres projets qui dépendent de lui ? Quel est l’historique des téléchargements ? A quelle fréquence, les nouvelles versions apparaissent-elles ? Quel est le délai entre la découverte d’un bug et sa correction ?

Les communautés qui hébergent ces projets regorgent d’informations permettant de se faire une bonne idée de leur qualité. Certaines d’entre elles comme Sourceforge.net, calculent quotidiennement l’indicateur d’activité de chaque projet, sorte de moyenne pondérée de métriques telles que celles décrites plus haut. Voilà donc de bonnes raisons de ne pas avoir peur de se lancer dans la sélection de projets anonymes; bien au contraire.

En conséquence, qualifier un logiciel libre est une tâche proche d’une activité de reverse engineering et demande donc des compétences et du temps, mais à l’autre extrémité, le logiciel commercial que l’on achète seulement pour ce qu’il fait au moment où on l’achète, fait figure d’inquiétante boite noire. Et ce ne sont certainement pas les discours marketing invérifiables sur la qualité, la pérennité et la capacité d’évolution du produit qui sont de nature à pouvoir rassurer l’acquéreur. Le caractère intrinsèquement ouvert d’un projet open source augmente ainsi considérablement le niveau d’exigence que l’on peut exprimer à l’égard du logiciel.

L’analogie entre d’une part, le monde de la prestation de service au forfait et celui du logiciel fermé et d’autre part la prestation de service en régie et le logiciel ouvert, est évidente. A ce détail près : dans le cas du logiciel open source, l’obligation de résultats s’additionne avec une obligation de moyens - scientifiquement mesurables. Alors n’hésitez plus ; avant chaque représentation, demandez le programme….et prenez le temps de le lire.

Java On WallStreet

JavaOnWallStreet
Lieu: New York

Intersection de la communauté Java et du monde de la finance de marché.
Prometteur sur le papier, mais décevant par le nombre d'intervenants.
Quelques rencontres interressantes comme Cameron PURDY de Tangosol racheté par Oracle en 2007.