Commentaires

Envoyé par frfancha

Pourquoi le lien 'Forum' n'est pas disponible dans cette news? Du coup il est impossible de voir les discussions sur le site mobile

Et en fait même sur le site web je n'ai pas trouvé de façon autre de voir les commentaires au delà des quelques premiers autrement qu'en cliquant sur "répondre" ?

Le DSI ne sait pas ce qu'est "EJB", mais se limiter à dire que ça sert à faire du CRUD relève du mensonge car l'information est trop incomplète. Ensuite tu dis qu'un développeur Java doit connaitre, en plus de Java, les outils comme Maven, Jenkins, Tomcat, Sonar. D'accord, Node.js n'a pas besoin de serveur HTTP comme Java, mais pour le reste tu tends juste le bout des doigts pour te faire taper dessus, n'importe quel professionnel sait à quel point ces outils sont importants et qu'ils ne sont pas spécifiques à Java. Tu prends PHP, tu vas retrouver le même modèle, l'outil de build qui ne sera plus Maven mais Composer par exemple, Jenkins et Sonar etc. Bref si tu veux faire du Node.js pour ne pas avoir à faire du Maven/Jenkins/Sonar, tu peux toujours rester sur du Java.

Sans vouloir te vexer, cet article c'est un peu du WTF. On ressent certes la volonté de convaincre quelqu'un à passer sous Node.js mais limité à la vision d'1 développeur, donc si tu veux convaincre un DSI je te dis tout de suite ce que tu dois faire : migrer des applications critiques vers Node.js puis faire un benchmark et dire que Node.js lui coute revient moins cher.

Citations :

• Par curiosité, qu'as-tu voulu dire avec "la technologie JEE permet de faire face à la montée en charge en clonant les « tiers » (aussi appelé scalabilité)" ?
• "Quant à la mise en production d'une application JEE, cela nécessite d'utiliser des ressources en CPU et RAM très importantes sur la plateforme d’hébergement." => Fais nous un joli benchmark d'application réelle please.
• "Sur un prochain post, je montrerai comment migrer en douceur de JEE vers AngularJS et Node.js." AngularsJS 1 c'est devenu has been, alors faudra surtout pas oublier de nous montrer comment migrer des applications Java EE Servlets & Spring & Struts & JSF vers du AngularsJS 2 en TypeScript.

Pourquoi le lien 'Forum' n'est pas disponible dans cette news? Du coup il est impossible de voir les discussions sur le site mobile

Je ne vous pas bien pourquoi cela est "java 8". La classe Fonction n'étant pas dans le standard...
Même si le code est propre et totalement valable. J'aurai tendance à utiliser un Apache Commons Math pour gérer ce genre de chose.
Ils ont une partie dédié au intégration : 4.5 Integration

Note : Je n'ai pas testé celle-ci, mais déjà proposé ici : How to solve an Integral in Java?

Cordialement,
Patrick Kolodziejczyk.

Je comprendrais jamais cette logique de vouloir migrer absolument sous node.js. C'est pourtant le sentiment que reflète cet article quand je le lis. C'est peut-être très bien mais c'est pas absolu...

Envoyé par yildiz-online

Maven, jenkins et sonar sont des outils améliorant la qualité des déliverables, en terme de code, et de reproduction et automatisation de build, en quoi une petite ou moyenne application n'a pas besoin de qualité?

Maven ne nécessite pas la création ni l'administration d'un entrepôt, soit on utilise un repo local auquel cas, rien a faire, soit effectivement un manager de repo comme archiva ou nexus, mais ça n'a de sens que si il est partagé par plusieurs applications, donc déjà existant...

Jenkins ne fonctionne pas obligatoirement dans un tomcat, il est également possible de le télécharger en package natif ou mieux en image docker. https://jenkins-ci.org/

Je partage totalement cette critique. Même sur un petit projet, ne pas utiliser des outils d'automatisation et de suivi est une aberration. On n'utilise pas Node.js ou AngularJS pour se passer des outils de production...

Par contre, deux remarques :
- Ces outils ne sont pas des outils améliorant la qualité. Maven et Jenkins sont des outils d'automatisation, Sonar est un Dashboard. C'est tout. Il peuvent servir à appliquer la politique qualité mise en place et alors l'améliorer mais leur simple mise en place n'a pas d'autre impact sur la qualité que que celle apportée par l'automatisation de tâches.

- Archiva, Artifactory ou Nexus ont un sens déjà en tant que cache (penser contraintes de gestion de licence). Ils ont un sens dès qu'on pense composants et non applications. Donc mis à part si on est dans une Start-up avec une grosse culture Git, ils sont fondamentaux dès l'outillage.

Envoyé par yildiz-online

C'est un point de vue intéressant, il serait bien que tu le développes pour définir en quoi tout cela relève de la médiocrité pour les autres points.

Je n'ai pas dit que les autres points relèvent également de la médiocrité mais que le reste du poste y est un appel. D'ailleurs, ce n'est pas ces points en soient qui entretiennent la médiocrité du SI (comprendre entre autres l'absence d'innovation, l'entretien du manque d'efficacité et de compétitivité) mais la considération qu'en négliger un fragilise le système. C'est ce que j'ai voulu illustrer dans l'exemple pour lequel la considération aurai pu être remplacée par le cout de migration.

Oh, quand même, le plus aberrant : "compatibilité avec de système existant (IC, build chain, autres frameworks actifs dans la boite...)". Le plus terrifiant est ce qu'il y a dans la parenthèse. Une techno n'est pas choisie pour s'intégrer dans les caprices des gestionnaires de l'IT mais pour répondre à un besoin relevant du business.

Tu pars du prédicat que la compétence interne est faible sur la technologie actuelle, j'ai un peu de mal à comprendre sachant que les dev ont tout de même été embauchés sur base de connaissance sur cette technologie, si ce n'est pas le cas, il faut voir ça avec la hiérarchie et RH, ce genre de situation me parait particulièrement inquiétant...

Connaitre une techno et être compétent sont deux choses différentes. Comment est évaluée une compétence lors de l'embauche ? Pas par les RH, on est sur Développez, on sait que les RH sont des incompétents qui ne comprennent rien à la techno. Reste ces fameux entretiens techniques. Comment sont ils réalisés ? En général, c'est des tests évalués par les "experts" en place qui considèrent les bonnes réponses comme étant celles de leurs habitudes de pratique. Essayez d'emmener la personne qui réalise votre entretien en dehors de SA zone de compétence...

Je ne sais pas quelles technologie vous employez, chez nous c'est majoritairement du java, ce qui offre un panel appréciable de librairies, framework et outils.

Je ne vais pas citer tout le dernier bloc pour une question évidente de lisibilité.
J'ai eu le titre d'expert technique Java, Architecte et Urbaniste. Je sais ce que propose Java, mais les libs et frameworks relèvent de l'implémentation, pas de l'architecture. Rien que considérer que la techno est Java, on ne parle plus architecture mais implémentation.
Là dessus, si votre argument de vente par excellence est la productivité, comment la vendez-vous ? Quels sont vos métriques et engagements ?

En tant qu'architecte, il faut vivre avec ces contraintes, les ignorer c'est aller droit dans le mur à moyen terme avec un panel de techno que les gens ne maîtrisent pas à cause du turn over, avec des briques logicielles intermédiaires pour assurer la compatibilité avec des services existants, avec des technos abandonnées au bout d'un certain temps,...
Si la médiocrité est le terme pour éviter ça, alors ce mot prend pour moi une connotation totalement positive.

Si on parle de la prise en compte de ces contraintes, on ne parle plus d'architecture mais de politique. L'architecte en question ne fait plus d'architecture et n'agit plus en tant "qu'architecte logiciel" mais en tant que médiateur.

En cliquant sur le premier (netflix) le mec explique qu'ils n'ont pas encore migrer certains services qui demeurent en java même si ils prévoient une migration pr obtenir une appli JS full stack...

Apres je suis quand mm surpris du nombre d'appli utilisant cette techno ! moi je pense que dans la "Bay" il faut être à la mode, et les devs se font vite chier si ils innovent pas ... c'est valable aussi ailleurs mais c'est moins marqué, il y a une certain image à cultiver la-bas :-)

Mais ce qu'ils oublient souvent de dire ce sont les heures passés à retranscrire des algos etc. d'un langage vers un autre, à réécrire les API, refaire la roue etc. pour au final jouir d'un service REST ecrit en 10 lignes sous VIM mais qui derriere reste difficile à exploiter, les mecs analysent les dump Node et sont obliger d'utiliser des frameworks "observable" c'est pas pr rien à mon avis :-)

Je poste ici car je ne réponds jamais par MP.
@Thierry : je fais une somme majorante et minorante et je la moyenne en final pour avoir une valeur finale entachée de moins d'erreur
Et oui je déclinerai solution en JAVA propre dans un prochain post

Bonjour,

en lisant le titre je me suis précipité pour avoir plus d'arguments sur ce sujet mais j'ai vraiment rien trouvé sauf des "préjugés"

1- node.js est utilisé par plusieurs boites niveau production ( liste des appli + sites utilisant node.js dans l'onglet stack http://stackshare.io/nodejs )
2- la présentation de la complexité pour le travail avec l'architecture JEE en intégrant Jenkins, sonar etc est vraiment a coté du vrai sujet sur la complexite car ces outils sont optionnels et sont la pour le respect de normes de codage, détection des bugs et l'intégration et le test du travail de l'équipe sur un environnement d'intégration ( pour ne plus tomber dans la fameuse "ça marche sur ma machine" )
3- le couple node.js / angular.js n'est pas le seul FullStack JS qu'on peut utilisé , donc je comprend pas la présentation de ces deux la comme alternative ou fatalité au lieu de présenter des FULL StackJS et laisser le libre choix au développeurs ou architecte de choisir selon le besoin
4- je ne vois aucun argument qu'on trouve facilement sur des forums qui traitent ce sujet pour l'après développement ! déploiement, load-balancing comme si c'était bénifique seulement pour les développeurs d'adopter ces frameworks ou passe vers du JS

Liste des app et site utilisant Node.js avec une explication d'un de leurs développeurs sur la partie sur laquelle il l'utilise :

Netflix (http://www.talentbuddy.co/blog/build...js-at-netflix/)
ebay ( http://www.talentbuddy.co/blog/build...de-js-at-ebay/ )
dowjones ( http://www.talentbuddy.co/blog/build...-at-dow-jones/ )
New York Times (http://www.talentbuddy.co/blog/build...ew-york-times/ )
PayPal ( http://www.talentbuddy.co/blog/building-with-node-js/ )
Medium ( http://www.talentbuddy.co/blog/on-bu...s-a-developer/ )
LinkedIn (http://www.talentbuddy.co/blog/build...s-at-linkedin/)

on peut avoué que c'est des app, sites qui ont du trafic

Pour n'en dire que quelques mots, nous pouvons parler d'outils :
de Build comme Maven, qui peut nécessiter la création et l'administration d'un entrepôt ;
intégration continue comme Jenkins qui s’exécutera dans un serveur TOMCAT ;
ou de qualimétrie comme sonar.
Développer en JEE impose donc de maitriser toute une pile logicielle. Quant à la mise en production d'une application JEE, cela nécessite d'utiliser des ressources en CPU et RAM très importantes sur la plateforme d’hébergement.

Ca n'a absolument aucun rapport, maven, jenkins et sonar sont totalement indépendants de JEE, sinon on faisait comment pour packager un war/ear avant?

Maven, jenkins et sonar sont des outils améliorant la qualité des déliverables, en terme de code, et de reproduction et automatisation de build, en quoi une petite ou moyenne application n'a pas besoin de qualité?

Maven ne nécessite pas la création ni l'administration d'un entrepôt, soit on utilise un repo local auquel cas, rien a faire, soit effectivement un manager de repo comme archiva ou nexus, mais ça n'a de sens que si il est partagé par plusieurs applications, donc déjà existant...

Jenkins ne fonctionne pas obligatoirement dans un tomcat, il est également possible de le télécharger en package natif ou mieux en image docker. https://jenkins-ci.org/

CPU et RAM très important? la JVM alloue un espace mémoire défini, avec son propre overhead de +/- 200 mo, c'est peu à notre époque, quant au CPU, des chiffres seraient appréciables, parce que la JVM est tout de même optimisée pour le système sur lequel elle tourne et évolue en même temps que celui-ci, ce qui ne serait pas le cas d'une application native.

Beaucoup d'informations erronées ou incomplètes.

Premièrement on ne remplace pas du JEE par du angular + node, JEE n'étant qu'une technologie backend.

Il s'agit en faite de remplacer JEE + GWT par angular + node (enfin de ce que je comprend la description de l'article).

Les bases nosql sont autant utilisables en javascript qu'en java, php, .NET ou tout autres technologies, qui plus est on peut tout à fait utiliser du MYSQL sur du node. Le choix de la base de donnée dépend surtout des usages et des contraintes d'administration (une base de donnée c'est avant tout de la gestion en run & assez peu de contraintes de développements). Sur du SI, le relationnel est souvent très utile car il décrit bien les relations entre les entités métiers (ex : une relation entre un produit et des tarifs). Le NOSQL est arrivé avec les gros acteurs du web qui avait des problèmes de gestion de très gros volume de données avec une très forte charge, c'est une approche différente.

Ensuite il n'existe pas de solution unique et miraculeuse à toutes les problématiques, NodeJS est une bonne techno pour la mise en place de plateformes simples (plateformes de médiations, routeur intelligent, système gérant les websockets etc...) et basées sur beaucoup d'IO néanmoins il souffre de grosses problématiques :
- Javascript et son environnement évolue extrêmement vite même si cela commence à se stabiliser un peu et avec énormément de manière complètement différentes d'arriver à ses fins. Si l'on prend de l'ES5 par exemple, il doit bien exister 3 ou 4 manières différentes de faire de l'objet nativement (sans parler des librairies) et il s'agit d'une des bases du langage! Cela implique de mettre en ligne tous les développeurs sur la même approche sans quoi tous les codes risquent d'être codés complètements différemment.
- Ensuite il s'agit d'un langage avec un typage TRES faible, ce qui pose rapidement des soucis sur le développement de couches métiers. Il n'y a pas trop de soucis sur du CRUD de base, mais le CRUD hormis quelques règles de validation ne comporte que peu de mécanisme métiers. Dès que l'on commence à avoir des systèmes un peu complexe, cela engendre pas mal de soucis qui sont réglés très rapidement sur des langages à fort typages (comme du java mais aussi du python ou du .NET). On peut compenser en utilisant typescript mais l'on rajoute encore une couche.

Si l'on part d'un environnement JEE il ne faut pas non plus ignorer la résistance au changement des développeurs dans ce domaine. Passer de JEE à node est quand même un changement très lourd et va prendre du temps, il ne faut pas ignorer le facteur humain. Tous les développeurs ne sont pas des as pouvant passer du jour au lendemain de JEE à javascript avant de passer le surlendemain à du scala par exemple.

Ensuite, indépendamment de la technologie, l'intégration des outils d'intégration continue tel que jenkins & sonar sont garants de la qualité et de la même manière que la base de données ne sont que peu liés à la technologie choisie. J'ai déjà mis en place une chaîne d'intégration continue sur une application ionic (angularjs + apache cordova pour du développement mobile) et j'étais bien content de l'avoir en particulier pour la partie sonar (c'est fou ce que cela peut apporter sur du javascript pour détecter des gros soucis liés à de petites erreurs de code). Après je suis d'accord que sur de petits projet ce n'est pas forcément essentiel, mais sur de de gros projets c'est le passage obligé!

Bref tout cela pour dire que le post décrit avant toute chose une envie de développeur plutôt qu'une lettre pour motiver un DSI. Un DSI se fiche complètement de la technologie en elle même, ce qui l'intéresse c'est surtout les avantages (et les faiblesses) associés que ce soit sur le développement mais aussi sur l'impact en terme de compétences requises, d'opérations, de supervisions, de gestion de l'historique etc... Et à ce titre il n'existe aucune solution miracle.

A titre personnelle, j'aurais plutôt tendance à conseiller à une entreprise fortement axé sur JEE de regarder les frameworks agiles de la stack java (play framework, grails ...) qui ont l'avantage de pouvoir être déployés sur le même type d'infrastructure que les vieilles applications JEE mais peuvent être aussi être déployées de manière autonome (comme node). Il n'y a pas de changement de langage nécessaire (ou alors vers un langage proche de java : groovy) et il est possible de réutiliser des composants déjà existants. Il est aussi important en parallèle de faire monter en compétences les développeurs sur les technologies du web (et ne plus cacher cette partie au travers d'un GWT ou d'un framework type wicket) pour la partie client.

Envoyé par martopioche

Autant je suis entièrement d'accord avec la première phrase, autant le reste est une ode à la médiocrité.

C'est un point de vue intéressant, il serait bien que tu le développes pour définir en quoi tout cela relève de la médiocrité pour les autres points.

Envoyé par martopioche

Exemple : parmi les points cités, la disponibilité et le bas cout des compétence est un des points auxquels les entreprises tiennent énormément pour ne pas être fragilisées. Sauf qu'il s'agit en général d'un cercle vicieux où les compétences disponibles seront majoritairement... peu compétentes. Et la conséquence sera un cout élevé en production et maintenance...

Tu pars du prédicat que la compétence interne est faible sur la technologie actuelle, j'ai un peu de mal à comprendre sachant que les dev ont tout de même été embauchés sur base de connaissance sur cette technologie, si ce n'est pas le cas, il faut voir ça avec la hiérarchie et RH, ce genre de situation me parait particulièrement inquiétant...

Envoyé par martopioche

L'architecte doit veiller à la cohésion, bien sûr. Cohésion, pas identité. Si il n'est pas possible d'avoir un pilote sans impact sur "tout l'écosystème", alors il est temps de revoir en profondeur l'architecture.

Je ne sais pas quelles technologie vous employez, chez nous c'est majoritairement du java, ce qui offre un panel appréciable de librairies, framework et outils.
Cette richesse a un contre coût, la compatibilité des éléments, si la plupart s'imbriquent correctement entre eux, il est possible(et même probable) d'avoir des effet secondaires ennuyeux: allongement important du temps de build, incompatibilité au niveau des librairies transitives, documentation non disponible pour l'intégration avec une librairie utilisée...
Tout cela peut sembler trivial au premier abord, pourtant ça nuit clairement à la productivité, et la productivité c'est quand même l'argument par excellence lorsqu'on vend un changement de techno au décisionnel.

Un changement de technologie ne peut pas être identitaire, il a forcément des chances d'être répercuté sur d'autres projets à venir pour éviter la disparité, ce qui veut dire former les développeurs qui passeront sur ces projets, c'est ça la cohésion.

Ce soucis est fortement amoindri en .net où on aura moins de choix mais une forte cohésion par essence.

Enfin, il est parfois effectivement temps de revoir en profondeur l'architecture, ça arrive, les besoins évoluent, les systèmes aussi, ce n'est pas un mal, mais ça prend du temps et n'est hélas pas toujours prioritaire.

En tant que dev, je te rejoins totalement, je ferais abstraction du système extérieur pour me concentrer sur mon application et sur ses impacts directs.
En tant qu'architecte, il faut vivre avec ces contraintes, les ignorer c'est aller droit dans le mur à moyen terme avec un panel de techno que les gens ne maîtrisent pas à cause du turn over, avec des briques logicielles intermédiaires pour assurer la compatibilité avec des services existants, avec des technos abandonnées au bout d'un certain temps,...
Si la médiocrité est le terme pour éviter ça, alors ce mot prend pour moi une connotation totalement positive.

Bonjour à tous,

On peut jouer sur les mots, mais quand je lis :

L'architecte logiciel est-il trop déconnecté du développement ?

Et ensuite

....d'exiger de l'architecte une maîtrise du développement et de ses problématiques.

Je me demande à quoi peut ressembler un architecte logiciel qui n'a jamais fais de développement ?

Peut-être que dans cet article on parle donc plus de d'architecte fonctionnel et/ou applicatif ?

On entend très souvent les développeurs séniors se plaindre des options retenues par l'architecte sur leurs projets. Ces plaintes font bien souvent surface lorsque le développeur se trouve confronté à une difficulté majeure qu'il estime due au choix d'architecture.

Il faut bien se plaindre de quelqu'un non ? Plus sérieusement, je n'imagine pas quelqu'un réaliser l'architecture parfaite d'une solution du premier coup, qui répond parfaitement à 100% des besoins (qui évoluent dans le temps rappelons nous), performante dans tous les cas et simple à mettre en place etc... C'est impossible ! Si il y a des difficultés dans l'implémentation d'une solution, les développeurs et l'architecte doivent travailler ensemble pour la surmonter. L'architecture du produit doit vivre et s'adapter à son contexte, ce n'est pas quelque chose de figée et gravée dans le marbre.
De plus, des divergences de point de vue entre dev et archi sont compréhensible, ils n'ont pas les mêmes objectifs.

Au final, je pense que cet article met bien en avant les problématiques autour de l'architecture : il y a plusieurs domaines d'expertise (métier, donnée, applicatif, logiciel, technique, réseau, système...) et on les mélanges tous. Mais aussi, trop souvent l'architecture est vue comme une activité d'avant projet, réalisée une fois, avant le lancement des développements, et qui s'arrête à ce moment la, alors qu'elle devrait accompagner le produit tout au long de sa vie, pour s'assurer qu'elle répond toujours aux besoins.

Je ne vois pas le rapport entre GWT et JavaEE !
Ensuite, côté env de dev, il n'y a pas besoin de sortir l'artellerie lourde (i.e intégration continue) pour développer une petite appli...
De plus si on te suit tu vas utiliser gulp, bower, etc, pour construire ton appli... bref, tu vas remplacer des outils de build par d'autre outil de build !!!!

Côté techno... pour une petite/moyenne appli, la pile Java est bien plus lourde à mettre en oeuvre... mais quand ton appli va monter en charge tu devras aussi mettre en oeuvre des technos comparables à celle de la puile Java...

a+
Philippe

il manque une grosse partie ... il n'y a que la vision dev (et je la trouve très étroite, désolé )

attention à la partie exploitation et toute la problématique de :
- charge de l'appli
- load balancing / scalabilité
- maintenance et patching de l'appli
- multiples instances mutualisées

les applis node.js que nous hébergeons actuellement ne tiennent pas la charge (mais pas du tout) comparée à une app php/j2ee.
En fait, elles n'ont jamais été prévues pour l'exploitation, cette partie est tout simplement oubliée.

Pour les développeurs avec un certain bagage, il n'y a pas de soucis pour faire de petites applications avec les grosses architectures et une belle usine logicielle, ça pérennise l'application dans le temps. De plus Maven nous propose tous un tas d'artefacts qui permettent de faire un starter en 2 temps 3 mouvements.

Mais javascript offre beaucoup plus de possibilités intéressantes en terme de développement (surtout pour l'UI, j'adore le prototypage), j'ai hâte qu'il atteigne le niveau de maturité de Java et l'écosystème qui va avec, J'attend la suite de ce post avec impatience.

Moi je dit oui sans soucis mais attention au dimenssionnement de l'appli, car j'ai toujours pas vu tourner un site angular JS avec des milliers de requetes, de l'upload de fichiers lourds et des traitements complexes, à voir.

Par contre ce que je vois davantage c'est un mix JEE/Angular il me semble que c'est un bon compromis, et puis coté IDE que peut-on utiliser ? il me semble pas que javascript bénéficie d'une intégration aussi avancé que Java en terme d'IDE ? Meme chose pr les API faut-il importer "à la mano" les dépendances ? Car faut pas oublier que si Maven existe c'est pas pour rien ! :-)

Envoyé par yildiz-online

On ne choisi pas une technologie parce qu'elle est hype, mais bien parce qu'elle répond à un besoin.

Lors de ce choix, il y a de nombreux critères à prendre en compte:

-adéquation avec le besoin
-pérennité
-maturité
-sécurité
-support et documentation
-compétence interne et coût de formation
-compatibilité avec de système existant(IC, build chain, autres frameworks actifs dans la boite...)
-coût de migration si remplacement
-...

Si un seul de ces point n'est pas positif, c'est tout le système qui s'en retrouve fragilisé.

Bref, soumettre un POC sans avoir pris le reste en compte a effectivement de grande chance d'être refusé et c'est bien normal.

C'est là la différence entre l'architecture et le développement, le développeur se concentre sur sa partie applicative, tandis que l'architecte doit aussi veiller à la cohésion de tout l'écosystème autour, et oui ça prend du temps et peut potentiellement ralentir l'innovation mais c'est nécessaire pour garantir une base solide et délivrer des logiciels, ce qui est au final notre métier à tous.

Autant je suis entièrement d'accord avec la première phrase, autant le reste est une ode à la médiocrité. Exemple : parmi les points cités, la disponibilité et le bas cout des compétence est un des points auxquels les entreprises tiennent énormément pour ne pas être fragilisées. Sauf qu'il s'agit en général d'un cercle vicieux où les compétences disponibles seront majoritairement... peu compétentes. Et la conséquence sera un cout élevé en production et maintenance...

L'architecte doit veiller à la cohésion, bien sûr. Cohésion, pas identité. Si il n'est pas possible d'avoir un pilote sans impact sur "tout l'écosystème", alors il est temps de revoir en profondeur l'architecture.

Mais intéressons-nous maintenant à savoir pourquoi l'architecte ne possède pas toujours cette connaissance du développement.
Tout d'abord parce que le parcours qualifiant pour devenir architecte ne passe pas forcement par un poste de développeur sur les technologies sur lesquelles il intervient. En effet, certains développeurs sur des technologies « non web » se sont réfugiés dans l'architecture pour éviter d'affronter les frameworks web (JEE notamment) qu'ils ont laissés aux plus jeunes.

Heu... Je ne vois pas le rapport et le problème n'est il pas simplement là ? L'architecture est indépendante de frameworks et des technos. Le problème bien souvent (monde JEE en particulier) est que l'organisation de l'IT comporte une "cellule architecture" qui décide jusqu'aux frameworks utilisés. Le problème est que nous avons alors des "architectes" en tour d'ivoire qui n'ont aucune notion des besoins applicatifs (et oui les fameux cols blancs/cols bleus).