Certains pourraient penser que la génération de code et la modélisation en général vont brider la créativité de leurs développements en leur imposant un carcan dont ils ne pourraient s’échapper !
Cette vision de la modélisation est très restrictive : elle laisse à penser que l’approche modélisation s’utilise comme une boîte noire dans laquelle on rentre un modèle et dont il ressort une application prête à l’emploi.
Si certaines approches MDA tentent de simplifier à l’extrême la génération d’applications (approche Crud par exemple), il est largement entendu que ces approches ne permettent que la générations d’applications très simples voire simplistes. Le MDA ne se résume pas à ces approches : dans nombre de cas d’utilisation, ces techniques sont utilisées sur des parties du projet laissant au concepteur la possibilité d’exprimer sa créativité dans les autres parties et dans la pertinence de la solution.
Pour rester sur ce sujet de créativité, on peut décomposer l’apport de la créativité aux activités de programmation sur deux axes : la créativité fonctionnelle et la créativité technique. Pour la première, l’approche modélisation/génération est extrêmement bénéfique : moins on passe de temps à coder plus on est disponible pour travailler sur les aspects fonctionnels, plus la solution apportée par l’application est innovante ou en adéquation avec les besoins de l’entreprise.
Pour la créativité technique, en première approche, il pourrait en être différemment : où trouver de la créativité dans des tâches largement automatisées ? En fait, la créativité se situe alors à un autre niveau : dans la conception du template de génération. C’est dans cet élément essentiel à la génération automatique que l’on retrouve les capacités créatives et d’innovation des développeurs. C’est dans la qualité du template que l’on retrouvera les performances de l’application, la qualité du code qui, soit dit en passant, ne doit pas être de qualité inférieure à celle d’un code écrit manuellement. La créativité technique reste absolument nécessaire pour imaginer ces solutions innovantes porteuses de gain de productivité.
Pour la créativité technique, en première approche, il pourrait en être différemment : où trouver de la créativité dans des tâches largement automatisées ? En fait, la créativité se situe alors à un autre niveau : dans la conception du template de génération. C’est dans cet élément essentiel à la génération automatique que l’on retrouve les capacités créatives et d’innovation des développeurs. C’est dans la qualité du template que l’on retrouvera les performances de l’application, la qualité du code qui, soit dit en passant, ne doit pas être de qualité inférieure à celle d’un code écrit manuellement. La créativité technique reste absolument nécessaire pour imaginer ces solutions innovantes porteuses de gain de productivité.
Pour finir, et pour replacer dans le contexte réel les défenseurs de la créativité, quel est le réel pourcentage de code « créatif » dans les applications ? Peut-on vraiment parler de créativité quand on passe une bonne partie de son énergie dans l’écriture de code transformant des données d’une représentation dans une autre ? N’est-il pas préférable d’utiliser une machine pour ces tâches pénibles et répétitives ?
1 commentaire:
Bonjour Philippe,
vos interrogation porte sur un point très sensible qui tends à stigmatisé les effets pervers d'une compétition annoncé entre l'occident et les pays en voie de développement Avant tout autre chose il est une préalable qu'il faut souligner, L'automatisation des métiers de la banque sont les principales causes de cette participation a cette compétition en ce sens qu'il existe de plus en plus de taches récurrentes qui se propage a tous les étages de la transformation des données.
Je crains que les métiers de l'information se soient dangereusement orientés vers une modélisation abstraire très dangereuse qui montre aujourd'hui ses limites et surtout ses effets très pervers. Les spécialistes en ingénierie en sont pour beaucoup les vrais responsable. En ce sens on peut constater l'acharnement des spécialistes en ingénieur dans ces dix dernières années à vouloir rajouter de l'intelligence autour des données en les marquants, les transformants et par la même leur données un cycle de vie à l'intérieur d'un objet conceptualisé.
Rien n'a été fait pour propager la données brute au cœur même des systèmes et de son exploitation. Ainsi la démultiplication des référentiels a laisser s'exprimer l'explosion des passerelles transformant une modélisation simple en une architecture en cascade ou chaque maillon devient un procédé critique. Les banques ont subit un chemin de croissance informatique dédié à la maîtrise de la modélisation et de la transformation plutôt que l'automatisation de la distribution de la données. Dans les métiers de la grande distribution, l'évolution rapide des pratiques du « juste à temps » on pourtant démontrer le formidable avantage de l'automatisation de la distribution plutôt que de formater et d'enrober d'intelligence un élément brute.
On peut constater l'aveuglement sans bornes des chaînes de productions dans les banques se transformer en un gigantesque conglomérat de technologies transformant , enrichissant et recréant une quantité astronomique de données reconceptualisées. De fait , les besoins en capacité de stockage on littéralement explosé. Chaque nouveaux systèmes réinventant son propre système de référentiel. Pourtant la données étant unique, son enrichissement aurait pu se faire par étape sans pour autant perturber sa consommation. Le modèle est simple la données au cœur de son identification et ses clés d'identification virtuel son enrichi au fur et à mesure que les types de consommation augmentent.
Voici en préambule ce qui me permet de commenté vos propos sur les effets de compétition entre les modèles de production « on-shore » et « off-shore » ou les modèles mixtes.
Tous l'intérêt d'une chaîne de production est de profiter des progrès technologique permettant non pas de réduire les coûts comme simple objectif mais bien d'assurer un très bon MTBF ( Temps moyen avant une panne ). En ce sens réduire les coûts de production mais diminué son MTBF on des effets critiques sur nos métiers. Hors ni le « on-shore » ni le « off-shore » n'ont osé répondre à cette véritable question. De fait la géopolitique peut se permettre de rentrer dans le débat tant que cette question n'est pas soulevé. C'est ce qui permet de généraliser la question a tout les systèmes de production virtuel ou physique. Si pour un système le MTBF n'est pas une donnée critique, alors le choix d'une chêne de production la moins chére est le plus important. Quelque soit la méthodologie utilisé , le rendement le plus économique est intrinsèquement lié au MTBF.
L'utilisation de génération de code permet d'assurer un très bon MTBF dans la partie éprouvé du code et demande un effort minime dans le contrôle du domaine d'utilisabilité. Hors les ingénieurs ont de tout en temps éprouvé une très grande difficulté à incorporer dans leur code, des patterns ou des templates algorithmique L'avènement de la STL en C++ n'a pas eu l'effet escompté et l'arrivée tardive de BOOST ne permet pas encore de mesurer la pertinence de la génération de code a bas niveaux. De même les architectures minimaliste CRUD fondement même des architectures juste-à-temps ne valide pas une très grande abstraction fonctionnel. Curieusement un outil comme Mathlab répond depuis de très nombreuse données a cette abstraction nécessaire mais l'outil reste rangé dans les placards de la recherche tout comme ROOT/CINT.
Je gage que .NET et JAVA apportant tout une batterie de macro objet cacheront au plus vite les vrais questions de réplication des données en promettant toujours plus de couche d'abstraction et de transformation et en enterrant définitivement les espoirs d'avoir enfin un vrai système juste-à-temps avec un unique référentiel de données. Les politiques commerciales des fournisseurs d'objet ne visant clairement pas l'intérêt des entreprises a diminuer leur MTBF dans leur chêne de production de code, on peut craindre l'accélération des effets d'opportunités que présente l' «off-shore» temps il est difficile aujourd'hui de produire un code à très haut niveaux fonctionnelle avec un très bon MTBF. De fait les spécialistes de production de code fonctionnel se retrouve prisonnier du substrat de la technologie et apporte une réponse aux problèmes avec une triple compétence ( Analyste technique , Développeur, Spécialiste fonctionnel ). Le monde de l'ingénieur se sépare en deux catégories , les spécialistes et les simples codeurs dématérialisé, pour répondre aux deux demandes, un code de moins en moins cher à produire mais sans contenu fonctionnel et de très basse qualité et un code fonctionnel de très haute qualité s'appuyant sur un liant très robuste et très sécurisé.
Dans cette analyse, je suis contraint de penser que le modèle de la données unique et de sa distribution en juste-à-temps est voué à disparaître et ainsi laissé les grandes chaînes de distribution régner en maître sur leur contrôl des coûts via cette technologie. L'échec vient de plusieurs facteur néanmoins qui ne sont pas forcément du choix des représentant à la stratégie des systèmes. Reuters, Bloomberg , PrLine et d'autres fournisseurs de données brutes font payer leur technologie de distribution de deux manière, d'une part avec l'obligation d'utiliser leur décodeurs et d'autre part en licenciant la redistribution des données brutes à la CPU, emprisonnement d'un coup tous les consommateurs aux modèles de la transformation immédiate ( La licence stipulant que la distribution de données de ne peut se faire que si il n'existe pas de fonction linéaire permettant de retrouver la données initiales ). De la même façon, les technologies permettant une consommation de la données en juste-à-temps sont paradoxalement très coûteuses, MQSeries,TibCo ou Fiorino JMS ont des performances largement au dessus des besoins et des architectures, mais leur implémentation au sein d'une banque est toujours très politique et très agressives sur la méthode de rémunération.
Dans ce conflit qui tends a forcer les banques dans un modèle tout objet et services, on s'aperçoit bien vite que l'intérêt commerciale est très grand. En effet tout modèle SOA tend pernicieusement à exploser les dictionnaires de référentiel ( Grand consommateur de passerelles et de middleware réseaux sécurisés ), exploser les conditions de réplication d'environnement ( Une plate forme de PROD, de DEV et d'homologation impose quelque soit le sous dimensionnement l'utilisation massive de middleware et de persistance en base de données ) et l'obligation de spécialiste dédiés ( Coût de lancement pharaonique, coût de migration imposant des passerelles, coût de mise a jour technologique inutile et surtout coût de maintenance incontrôlable ). Le modèle BUS est tout aussi compliqué avec des problèmes de redondances des données dans leur distribution, de consommation cyclique ingérable et surtout de l'impossibilité d'ordonnances les traitements a grandes échelles.
De fait et subissant de plein fouet la dictature des fournisseurs de technologie, le pari du tout maison est très ambitieux, malheureusement faire du tout maison en suivant les dogmes du marché et des politiques commerciales des fournisseurs est une erreur condamnable et injustifiable. Pourtant je crains que les banques n'aient guère le choix dans leur survie à long termes de s'assurer de la maîtrise de leur coûts en maîtrisant les deux piliers technologiques qui font leur fondement,
la technologie de distribution des données en tout point intérieur dans des temps courts, sécurisés et à la demande
le contrôles absolu du nombre de référentiels indexant les données critiques
En tant que spécialiste des systèmes de l'information financière, je voie le danger réel pour les banques et assurances comme pour d'autre secteurs, la prise de pouvoir des spécialistes des technologies et la condamnation a long termes des entreprises a devenir prisonnière de leur propre système d'information et d'être dans l'obligation de recourir a de l'off-shore pour toute la production de code non fonctionnelle pour réduire les coûts tout en augmentant en des proportions non négligeable la rémunérations des spécialistes.
Chose amusante, lorsque l'on regarde ce dont a besoin d'une banque d'investissement c'est d'un système permettant de confirmer une vente, de préserver la marge et de retirer une certaine rémunération entre l'espérance de paiement annoncées et la gestion quotidienne de cette vente. La quantité de données pour s'assurer de ce travail est paradoxalement trés faible.
Enregistrer un commentaire