Open source et architecture logicielle

[Actualité] Comment proposer une nouvelle technologie à un architecte ?

par

autran

, 26/12/2015 à 19h11 (1007 Affichages)

Quel développeur n'est jamais allé proposer à un architecte de s'engager vers une nouvelle plateforme logicielle pour s'entendre répondre qu'il fallait d'abord la tester pour vérifier si ce nouveau langage était stable et répondait aux exigences d'un système en production ou si le nouveau framework était compatible avec l'existant...
Et quel développeur n'a jamais eu l'impression que ces réponses n'étaient qu'une façon d'évacuer la proposition innovante ? Surtout quand on entend : « il faut d'abord qualifier une solution avant de l'utiliser sur un projet, et ça n'est pas aussi simple que tu le penses ».

Alors l'architecte logiciel est-il trop frileux face aux demandes innovantes des développeurs ?
C'est sans doute l’interprétation qu'en fera le développeur. Mais il faut reconnaître qu'avant d'adopter une technologie, il faut tout de même en mesurer les risques et les opportunités. Et c'est bien cette étude de la valeur qui prend du temps, voire enterre l'innovation dans l’œuf.

Une solution pour faire élire votre langage ou votre framework fétiche au rang d'opportunité à saisir, serait de la rendre séduisante au regard du boss et de l'architecte. Bref, proposez une analyse de la valeur qui consacre votre plateforme. Pour cela, voici quelques pistes :

porter aux yeux du boss, via la mobilité, quelques fonctionnalités embryonnaires d'un système qui reste à développer pour 95 %. Cette méthode est très employée dans le décisionnel ;
faire un Proof Of Concept avec l'accord du chef de projet sur un périmètre faible pour montrer le temps de développement gagnable. C'est le chef de projet qui portera le risque et éventuellement les lauriers de l'innovation. Mais importe peu la gloire pourvu que le développeur ait l'ivresse (d'utiliser son nouveau langage préféré) ;
produire une analyse focalisée sur les axes favoris de l'architecte. Pour cela, il faudra dialoguer avec l'architecte au cours d'une partie de bowling ou d'un baby-foot pour connaitre ses préoccupations (ingénierie sociale).

Mon prochain post présentera quelques arguments à faire valoir auprès de l'architecte pour l'adoption de node.js et angular.js en lieu et place de JEE.

Et vous ?

Qu'en pensez-vous ?

Mis à jour 27/12/2015 à 10h03 par ClaudeLELOUP

Tags: architecture logicielle, développement

Catégories: Sans catégorie

« L'architecte logiciel est-il trop déconnecté du développement ? Liste des billets Comment convaincre votre DSI d'adopter Node.js et AngularJS pour remplacer JEE »

Commentaires

RyzenOC - 27/12/2015 09h31
- |
[QUOTE]Comment proposer une nouvelle technologie à un architecte ?
L'architecte logiciel est-il trop déconnecté du développement ?[/QUOTE]
Ces 2 news relèvent d'une même thématique générale ?

Mis à jour 28/12/2015 à 14h28 par autran
yildiz-online - 27/12/2015 10h18
- |
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.
martopioche - 28/12/2015 02h05
- |
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.
yildiz-online - 28/12/2015 11h26
- |
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.
martopioche - 29/12/2015 00h14
- |
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.