Des logiciels et des hommes. Part Two

Un sujet récurrent dans le développement logiciel, c'est l'architecture.

Il y aurait de bonnes et de mauvaises architectures. Ou plutôt, il y aurait des architectures bien adaptées à tel ou tel produit ou environnement technique, et d'autres qui le seraient moins.

Mais est-ce l'essentiel ? N'oublierait-on pas quelque chose ?

Imaginons que je veuille construire ma maison moi-même. J'étudie tout ça, me plonge dans différents ouvrages ou sites sur le sujet, puis je décide finalement de construire une maison bio-climatique, avec toutes les caractéristiques qu'une maison du XXI° siècle devrait avoir. Je conçois la maison idéale. La maison avec la bonne architecture.

Bon il n'y a plus qu'à la fabriquer, alors. Oups. Moi, en dehors de clouer quelques planches... Heureusement, mon cousin m'a dit qu'il m'aiderait. Il est maçon. Le hic, c'est que ma maison à l'architecture parfaite, elle doit être en bois et en paille... Et puis mon cousin, tous ces trucs bio-machin... Lui, il monte des parpaings.

La bonne architecture, c'est un compromis entre l'architecture "idéale" et celle que l'on est capable de réaliser. Et surtout celle qui reçoit l'adhésion de ceux qui vont l'implémenter, "pour de vrai" !

La bonne architecture, c'est celle que l'équipe "sent" le mieux. Pas celle impos.. pardon, proposée par l'architecte en chef ou je ne sais quel expert.

Et vous savez quoi ? Il y a une méthode infaillible pour qu'une équipe adhère à une architecture. C'est qu'elle la définisse elle-même...

Et vous savez quoi (bis) ? Si cette équipe a des compétences variées, des jeunes prêts à tout changer, des vieux expérimentés (ou l'inverse) et que tout ce monde a envie de réussir... ils trouveront certainement l'architecture idéale.