Discussion :

[ludovic.fernandez]

Bonjour à tous,

Comment justifiez-vous le besoin de refonte architecturale d'une application ?

Je m'explique:
Les modèles, les besoins et les connaissances évoluent sans cesse et dans une vision à long terme, il peut s'averer judicieux de refondre l'architecture d'une application avant meme de connaitre l'ensemble des contraintes a venir: "openness", "flexibility", "scalability" ...

Par exemple, un composant est de plus en plus utilisé au sein d'une equipe/entreprise alors qu'il n'avait ete concu que pour repondre a un ensemble de contraintes. Une vision a long terme serait de l'orienter service pour élargir son champ d'action.

Aujourd'hui, le choix se pose donc entre une integration de k*x hommes*jours (k=nb de composants et x=cout moyen) et k*y+z hommes*jours ou z>x.

Quelles sont vos experiences face a ce dilemne ? Comment justifiez vous hierarchiquement ce besoin de maniere marketing ?

Ludo

[djo.mos]

La refonte architecturale, pour moi en tout cas, est une chose trés fréquente.

Pour des petrits projets, pas de problèmes, je me lancais tout de suite dans la programmation, et au fur à mesure que des problèmes surviennent, je bricolais une solution (sale), le plus important etait de finir.

Mais quand un jour, j'ai eu l'imbécile idée de developper un moteur 3D (Delphi, openGL), J'en ai vu des vertes et des pas mûres !
A chaque fois que je voulais ajouter un effet ou une fonctionnalité, j'avais à réecrir d'énormes portions de code, pour que la chose marche.
Ca m'a laissé un trés mauvais souvenir, et j'ai du abandonner aprés presque un an de travail pour aboutir à près de 15 Mo de code non fonctionnel !

La refonte architecturale, peut être soit bénéfique, soit une chose à éviter, selon le cas :

- si c'est au sein d'un même projet, on commence par une architecture, et au milieu du chemin, on décide de changer : ça implique que vous n'avez pas pris le temps de réfléchir avant de commencer à programmer, très mauvaise pratique

- si c'est pour une mise à jour d'un ancien projet par exemple, là, ca ne peut qu'être bénéfique.

[Katyucha]

La seule refonte architecturale que j'ai proposé, a été refusée...

Un programme en VB/Access/shell Unix...etc, qui avait pris de grosses proportions, avec des ajouts un peu partout, qui passe plus dans la rubrique bricolage que programmation
Impossible de le maintenir sans perdre énormément de temps, perte de données...etc

Ma justification : On passe plus de temps à la maintenir, la reviser, relancer les divers scripts interfacés...etc qu'a refaire une application correcte, qui nous pose pas de problème, et qui en plus aura migré vers les besoins des utilisateurs, qui ont un peu glissé...

Réponse du responsable :
- On a acheté cher le programme, alors la direction informatique va refuser qu'on le jette et qu'on le refasse, surtout que ca touche d'autres directions...

Je ne vois pas francement, ou informatiquement, ca péchait... ni pourquoi ma justification a été rejetée...surtout que je pense qu'elle tient la route...
Peut etre, certaines personnes préfèrent ne rien faire, plutot que montrer une erreur précédente...

[ggnore]

Le problème de la refonte architecturale, c'est le coût.
Il faut réussir à justifier que la perte de temps immédiate engendrée par cette refonte fera vraiment gagner du temps et de l'argent par la suite.

Le développement de nouvelles fonctionnalités sur un logiciel ancien est souvent rodée : on peut facilement estimer combien de temps va prendre telle ou telle fonctionnalité à rajouter.
La refonte prend beaucoup de temps puisqu'il va sûrement falloir tout reprendre de zéro et tout recoder alors qu'on pourrait consacrer ce temps à rajouter de nouvelles fonctionnalités.

Il faut des résultats rapides avec des coûts minimums. De plus une refonte implique que la personne à laquelle on accepte cette demande va forcément prendre du galon.
C'est un peu comme donner un coup de pied dans une fourmilière.
Je ne suis pas sûr d'avoir apporté grand chose dans ce message, mais ce dont je suis sûr c'est que réussir à justifier ce genre de chose n'est pas chose aisée.

bon courage

[neo.51]

Le problème de la refonte architecturale, c'est le coût.

Tout à fait

Mettons de coté les petits projets ou la refonte architecturale ne pose pas de problèmes particuliers car le cout n'est pas significatif.

Pour un gros projet, la refonte architecturale à un coût significatif, que ce soit en heure de dev, en analyse, et en testing. Je pense que pour justifier un tel coût il faut profiter d'une évolution majeure de l'application. Parce que sinon, qui va payer le coût du changement d'architecture ? Ce n'est pas le genre d'investissement prioritaire dans une entreprise.

Par contre à partir du moment où on a un besoin spécifique qui commence à devenir important en terme de temps de developpement, c'est là qu'il faut remettre en cause son architecture.
Oui je dois répondre à tel besoin, mais quel besoin sont succeptible d'en découler ?
Qu'est-ce qui actuellement va me faire perdre du temps en dev dans le développement de ces fonctionnalitées ? Que dois-je remettre en cause dans mon architecture pour implémenter plus facilement ces nouvelles fonctionnalitées ?


Aprés y a remise en cause et remise en cause ... suivant les spécifications de départ et l'architecture de départ. On peu trés bien isoler certain composant et remettre en cause une partie de l'application. Le plus dur et de savoir où on doit s'arreter dans ce changement d'architecture... suivant la complexité des applications c'est plus ou moins évident.

Pour en revenir au sujet qui est comment justifier une remise en cause de l'architecture, moi je présente souvent les choses comme ça :
On a une applis qui marche mais qui n'est pas prévue/étudié pour ces nouvelles fonctionnalitées (sinon on voudrait pas revoir l'architecture).
Soit :
-On bricole un dev rapidement.
-On prend un peu plus de temps pour revoir les composants qui ne sont pas adaptés à ces nouveaux développements.

La solution 1 va plus vite, mais c'est là qu'il faut mettre en avant le fait que remettre en cause son architecture permettra de mieux faire évoluer l'application dans le futur. Et si on le fait pas maintenant, plus tard ça sera encore plus long (donc plus couteux) à faire. De plus un changement d'architecture permet de gagner en perf / temps de dev (pour les prochainnes versions à venir).

C'est tout ça qu'il faut éssayer de quantifier

Mais bon en principe une fois qu'on a galéré à la refonte de l'architecture de quelques projet, on réflechit plus à la conception
Car le moins couteux et le plus rapide c'est de bien concevoir du premier coup

[Bruno75]

une approche peut être un développement en parallele avec une équipe chargée de continuer avec l'ancienne architecture et une équipe qui va mettre en place petit à petit la nouvelle architecture, puis petit à petit porter les programmes qui s'appuie sur cette architecture. Les ressources de dév basculant au fur et à mesure sur la nouvelle architecture

ça dépend évidemment du contexte, du nombre de personnes/logiciels qui utilisent cette architecture, si la société est de taille suffisament importante, etc., si les applis qui s'appuient sur cette architecture peuvent être intégrées petit à petit en évitant une approche big bang.

et effectivement, suivant la taille du projet, la politique peut beaucoup jouer. Dès que les petits chefs se sentent dépassés/menacés, c'est peine perdu puisque c'est eux qui au final justifieront le coût auprès du grand manitou financier qui en général ne comprend pas tout à l'info

[Piotrek]

Et il faut aussi considerer le risque qu'implique une refonte complete d'un systeme complexe...
- Le systeme d'origine doit etre compris et tres bien compris
- Les nouvelles possibilites doivent etre sondees et planifiees tres precisement, dire que "ca sera mieux" meme si on est tous d'accord, ca suffit pas (a quoi bon faire qq chose de nouveau pour que ca fasse pareil?)
- Les delais de transition sont systematiquement sous-estimes
- Les fonctionnalites redeveloppees peuvent ne pas etre a la hauteur de ce qu'il y avait precedement (cas classique du passage au web)
- Le nouveau projet peut se planter pour Xmille raisons classiques

Les seules possibilites que je vois c'est:
- le besoin d'un avantage particulier impossible a realiser (ou trop tordu a realiser) dans le systeme d'origine (communication avec les clients ou fournisseurs, passage a l'ISO...)
- La fusion/acquisition de la societe qui utilise le SI
- Societes qui ont le besoin d'etre a la pointe et qui ont des cesterces a lancer par la fenetre

Aussi puissant le marketing soit-il, il y a des choses qui ne peuvent pas passer

[Bruno75]

Les fonctionnalites redeveloppees peuvent ne pas etre a la hauteur de ce qu'il y avait precedement

Déjà entendu dans une société de gestion financière : volonté de se passer d'Excel. Vu la puissance d'Excel, le fait que dans la finance tout le monde connaît excel et sait faire ses propres macros en vba, la simplicité avec laquelle on peut plugger des composants et des dll de calculs mathématiques, ... même si effectivement excel pose parfois des problèmes de centralisation et de maintenance, on peut se demander si ce genre d'idées a été murement réfléchie.

L'idée étant bien sûr que l'équipe informatique se charge de mettre à jour ce qui doit être mis à jour.
1 Le coût va être très important
2 l'organisation va être complètement différente
3 il va falloir une très grande réactivité de l'informatique sans cela les utilisateurs qui veulent faire des choses rapides vont gueuler
4 Comme tout le monde connaît excel, la moindre imperfection dans le nouveau soft, le moindre truc un peu moins pratique que l'ancien système, le moindre poil de couille de travers va être une occasion de se plaindre
5 besoin de formation
...
Peut-être même que les gens vont garder leur propre truc avec leurs propres développeurs privant ainsi la nouvelle architecture de plein de ressources mettant la nouvelle équipe dans une situation impossible.

On pourrait continuer longtemps.

C'est jouable mais c'est pas comme le rappelle Piotrek, c'est pas un truc que l'on fait comme ça ...

[mat.M]

Mais quand un jour, j'ai eu l'imbécile idée de developper un moteur 3D (Delphi, openGL), J'en ai vu des vertes et des pas mûres !
A chaque fois que je voulais ajouter un effet ou une fonctionnalité, j'avais à réecrir d'énormes portions de code, pour que la chose marche.

Cela tient plutôt de la méthodologie et analyse d'un projet.
La POO et méchanismes comme l'héritage peuvent résoudre ce problème.
On a une classe de base on veut rajouter des fonctionnalités alors on crée un e nouvelle entité hérité de la classe de base qui reçoit attributs et méthodes.

La seule refonte architecturale que j'ai proposé, a été refusée...

Piotrek et autres ont tout dit
Si la DSI a refusé cela peut s'expliquer par le fait que les moyens financiers manquaient pour refondre l'application et qu'une solution informatique qui donne satisfaction, même largement bricolée et faite de bric et broc , c'est risqué de la refaire

Déjà entendu dans une société de gestion financière : volonté de se passer d'Excel. Vu la puissance d'Excel, le fait que dans la finance tout le monde connaît excel et sait faire ses propres macros en vba, la simplicité avec laquelle on peut plugger des composants et des dll de calculs mathématiques, ... même si effectivement excel pose parfois des problèmes de centralisation et de maintenance, on peut se demander si ce genre d'idées a été murement réfléchie.

Et dire qu'il ya un débat Open Office versus Ms Office
C'est pas pour troller

[Matthieu Brucher]

On essaie aussi chez nous de demander une refonte de l'outil qui a été développé dans la maison depuis plus de 10 ans, programmé en C au départ sous Windows, puis sur des HPs, puis maintenant sur des Intel sous Linux. Un doctorant en avait tellement marre qu'il a développé depuis 0 une librairie graphique - http://imlib3D.sourceforge.net/ - et ce truc est vraiment génial. Sauf qu'étant donné qu'elle n'est pas vraiment compatible avec l'ancienne plate-forme, on a des espèces de ponts entre les 2 et ctte semaine, je me suis rendu compte que l'appel à certaines fonctions de l'outil de base faisait planter la sauvegarde des images avec ImLib3D !
Tout ça pour dire que le plus gros problème en général, c'est le financement, mais aussi parfois la volonté d'imposer un mode de fonctionnement qui n'est pas optimal - par ex lier la librairie graphique à l'interface graphique -

[ludovic.fernandez]

En définitive et je suis heureux, la refonte a été acceptée et est en phase finale de développement (une centaine de jours/homme). A savoir que le contexte général de l'entreprise va dans ce sens.

Le but était de proposer un framework de calcul générique accessible depuis des logiciels et composants tiers en lieu et place d'un simple composant interne (Justification 1). En cela, la refonte ouvre de nouveaux horizons pour les clients que je n'aurais jamais envisagé (Justification 2) et devient un élément de référence pour les futurs développement (Justification 3). Comme quoi, l'informatique a parfois de bons côtés; en bidouillant légèrement les estimations en terme de coût, la refonte n'aura pas coûter plus de jours/hommes que les améliorations requises à l'origine pour cette release (Justification 4) . C'est à dire qu'au lieu de modifier le code pour étendre les fonctionalités, il suffit de développer un plugin ou un client.

Côté maintenance, un expert technique pourra s'approprier l'infrastructure générique lorsque des experts fonctionnels pourront maintenir leurs clients. A l'origine, les personnes en charge de maintenir ce code devaient avoir autant de compétences techniques que fonctionnelles.

Ludo