IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Open source et architecture logicielle

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

Note : 2 votes pour une moyenne de 5,00.
par , 26/12/2015 à 17h29 (2249 Affichages)
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.
Lorsqu'il est avéré que l'architecture retenue est en inadéquation avec les développements demandés sur le projet, on est droit de se poser des questions sur la légitimité de l'architecte.
Si le risque était prévisible, alors il est évident qu'il y a eu un trou dans la raquette durant la conception de l’architecture. Mais comment corriger ce problème ?

Pour pallier ce défaut de compétence nuisible au projet, une réponse serait de conseiller à l'architecte d'impliquer le développeur pour le choix de la solution logicielle. Malheureusement, pour des raisons de coût autant que de planning, cette solution n'est pas idéale. En effet, le choix d'architecture se fait souvent avant que le projet n'entre réellement en phase de développement, voire avant que l'on ait décidé si le projet serait ou non réalisé.
Ne reste plus alors comme solution directe en première approche, que d'exiger de l'architecte une maitrise du développement et de ses problématiques.

Une autre solution serait d'apporter de la souplesse au processus de conception réalisation en faisant un point rapide après une première phase de développement pour faire valider par les développeurs l'architecture retenue. On a d'ailleurs de plus en plus souvent recours à des prototypes servant de Proof Of Concept pour l'architecture, sur des projets de grande taille. Néanmoins, même pour ce type de projet, l'architecte devra posséder une culture du développement suffisante pour dialoguer de façon constructive avec le développeur. L'architecte devra avoir également pensé son architecture de façon suffisamment générique pour l'adapter au cours du projet.

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.
Mais aussi parce que les métiers de la conception d'architecture et de développement sont parfois totalement exclusifs l'un de l'autre. C'est particulièrement le cas des projets qui font l'objet de marchés publics, pour lesquels il y a une AMOA (assistance à maitrise d'ouvrage) tournée vers le métier et le fonctionnel, mais qui conçoit l'architecture du SI cible et une MOE (maitrise d’œuvre) qui réalise le logiciel. Et ces deux entités (cols blancs et cols bleus) ne sont pas reconnues pour leur capacité à communiquer pour le bien du projet.

Et vous ?

Chez vous, comment les architectes et développeurs cohabitent-ils ?

Envoyer le billet « L'architecte logiciel est-il trop déconnecté du développement ? » dans le blog Viadeo Envoyer le billet « L'architecte logiciel est-il trop déconnecté du développement ? » dans le blog Twitter Envoyer le billet « L'architecte logiciel est-il trop déconnecté du développement ? » dans le blog Google Envoyer le billet « L'architecte logiciel est-il trop déconnecté du développement ? » dans le blog Facebook Envoyer le billet « L'architecte logiciel est-il trop déconnecté du développement ? » dans le blog Digg Envoyer le billet « L'architecte logiciel est-il trop déconnecté du développement ? » dans le blog Delicious Envoyer le billet « L'architecte logiciel est-il trop déconnecté du développement ? » dans le blog MySpace Envoyer le billet « L'architecte logiciel est-il trop déconnecté du développement ? » dans le blog Yahoo

Mis à jour 27/12/2015 à 07h37 par ClaudeLELOUP

Catégories
Sans catégorie

Commentaires

  1. Avatar de eclesia
    • |
    • permalink
    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.
    C'est le travail de l'architecte de connaitre un minimum les outils qu'il va mettre en pratique. Un architecte, un vrai, est une personne qui a une dizaine d'année en tant que developpeur, c'est sensé être un developpeur respectable. Si ce n'est pas le cas ce n'est pas un architecte mais un parvenu qui a su se vendre aupres d'un patron peu regardant.

    ..., 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.
    JEE n'est pas du web, c'est deux pieds dans le serveur, une main sur les services et un dans le web. Mais je comprends parfaitement cette aversion pour le web, car les librairies changent tous les ans ou presque, les navigateurs sont tous plus ou moins buggés à différents niveaux, la lenteurs affligeantes des chargements, de la réactivité ... le developpement web est une plaie comparé au desktop.

    Mais aussi parce que les métiers de la conception d'architecture et de développement sont parfois totalement exclusifs l'un de l'autre. C'est particulièrement le cas des projets qui font l'objet de marchés publics, pour lesquels il y a une AMOA (assistance à maitrise d'ouvrage) tournée vers le métier et le fonctionnel, mais qui conçoit l'architecture du SI cible et une MOE (maitrise d’œuvre) qui réalise le logiciel. Et ces 2 entités (cols blancs et cols bleus) ne sont pas reconnues pour leur capacité à communiquer pour le bien du projet.
    C'est un problème de reconnaissance des compétences de chacun. C'est une question de mathématique pour les employeurs, un bac+5 vaut plus qu'un bac+2 avec 5ans d'exp. hors c'est faux, le niveau d'etude nous offre des outils pour évoluer plus vite, pour mieux apprendre, mais ce n'est pas absolue.
    Pour faire simple tous le monde devrait commencer au premier niveau et monter plus ou moins vite selon ces capacités. C'est le principe des apprentis.
    Malheureusement le systeme actuel fait que des personnes sans expériences se retrouve 'col blanc' sans expérience pour diriger des 'cols bleus' qui peuvent etre dans la boite depuis une 20ene d'années (et qui reste des col bleus car ils sont doués, le passage a col blanc n'est pas une fatalité).

    S'il y des accros, de la jalousie ou un sentiment d'injustice, c'est normale. On le sait tous intérieurement, il y a une autre hiérarchie dans une boite, une hiérarchie qui n'est pas lié au salaire, c'est l'importance des personnes, leurs valeurs réels. Dans cette hiérarchie, patron et actionnaires sont en bas de cette pyramide, ils n'apportent rien à l'entreprise, au plus se sont des supports. Et inversement ceux vers qui on se tourne naturellement quand on a un probleme ou pour des conseils sont dans le haut de la pyramide.
    Hors le 'col blanc' est sensé etre quelqu'un dans la partie haute de cette pyramide, si ce n'est pas le cas alors il n'est pas a sa place et il a des frictions.

    C'est parcequ'il y a une trop forte incohérence entre la réalité de la valeur de chacun et les fonctions/salaires que ca clash entre les 'col blanc' et 'col bleu'. cela s'applique a bien d'autres domaines, politiciens/peuples, profs/eleves, ...
  2. Avatar de Potomac
    • |
    • permalink
    il faudrait peut-être un "choc de simplification" dans la manière de gérer les projets de développement, en supprimant certaines strates type architecte pour ne garder que l'essentiel : le(s) développeur(s) et le commercial en informatique chargé de négocier avec le client le cahier des charges,

    en supprimant des maillons de la chaine plus ou moins bureaucratiques on peut améliorer la réactivité et la cohérence du processus de développement, les acteurs réellement impliqués au jour le jour dans le développement ( le développeur et le commercial ) travailleront plus efficacement,

    pour que cela fonctionne il faut que le métier de développeur informatique soit vu comme un poste à longue carrière et non pas comme un statut temporaire ( l'exemple du jeune développeur qui veut rapidement devenir chef de projet parce que rien que le nom ça fait chic, impression de pouvoir ), on doit laisser au développeur le temps d'améliorer ses connaissances, il doit accumuler de l'expérience pour pouvoir ensuite encadrer de plus jeunes développeurs tout en restant lui même développeur même à 50 ans, un développeur expert qui saura prendre en charge les problématiques d'architecture tout en travaillant aussi sur le codage en lui même,

    on gagne en autonomie et réactivité des équipes développement en supprimant certaines strates hierarchiques et bureaucratiques qui engendrent surtout de la lourdeur et de l'inertie dans les processus de développements
  3. Avatar de yann2
    • |
    • permalink
    Bonjour

    Je suis un peu surpris par cet article. Personnellement, en 9 ans, les "architectes" que j'ai rencontrés ont des connaissances techniques pointues. J'ai mis architecte entre guillemets, parce que je préfère les appeler référents techniques. A moins que l'article parle d'architecture fonctionnelle ?

    Pour ma part, j'ai plus l'impression que ce qui peut mettre une architecture technique à défaut sont les problématiques opérationnelles. Par exemple, si l'architecte ne connait pas la volumétrie des données ou le nombre d'utilisateurs simultanées. Certaines fois, il est difficile d'obtenir ces données en avance.
  4. Avatar de martopioche
    • |
    • permalink
    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).
  5. Avatar de vincent.poupet
    • |
    • permalink
    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.
  6. Avatar de autran
    • |
    • permalink
    @Potomac : Je suis entièrement d'accord avec toi.
    A ceci près que, si tu connais une entreprise qui recruterait un développeur de plus de 50 ans indique la moi car je n'en ai jamais vu.
    OK, tant pis pour le développeur, il fera un super architecte logiciel.
    .... Finalement je vais peut-être monter une SSII de développeurs cinquantenaires, si certains sont intéressés.
  7. Avatar de Zineb2014
    • |
    • permalink
    Tracer La limite entre le travail d'un architecte fonctionnel et celui d'un développeur a toujours posé problème, arrêter le niveau de détail autorisé à un architecte n'est pas une chose simple mais on peut toujours s'arranger sur un compromis.
    Ce dont on est tous d'accord c'est qu'on peut pas monter un projet juste par une vision architecturale fonctionnelle sans se soucier du coté technique ( plate-forme, performances, BDD,requêtes ...) ,Personnellement lors de l’établissement des spécifications fonctionnelles je garde des cases spécifiques à des aspects techniques genre : temps de réponse d'une requête donnée ,sécurité d’accès ...et quand je discute ces spécifications avec le développeur je me trouve très souvent entrain de négocier des choix en mettant en évidence les gains et les pertes en terme de performances,rapidité,charge,récurrence, mon souci est d'optimiser l’interactivité système-utilisateur et le sien est d'optimiser l'appel du serveur applicatif et de la base de données . Être initié au domaine du développement c'est recommandé mais on n'est pas censé savoir développer pour faire des choix appropriés et efficaces ,de tel choix peuvent être réalisés en coopérant avec compétences architecturales techniques.
    il n'a y a pas de solutions idéales ou de bons choix , c'est juste un monde ou l'architecte fonctionnel et le développeur doivent communiquer,négocier, s'entendre et se compléter.