Blogounage

Je me pose la question depuis que je suis censé exercer ce métier. Je dis censé parce que c'est ma fonction officielle, mais que je ne saurais pas encore précisément la décrire en quelques phrases simples. De plus, j'ai conscience de ma relative faible expérience dans le domaine. Idéalement, je me qualifierais donc plutôt architecte junior^[1], pour montrer un peu d'humilité, chose dont j'ai souvent besoin, mais je me soigne.

Ce qui me rassure, c'est qu'il semble que je ne sois pas le seul à me poser la question, quant à la définition de mon métier...

Pour moi, pour faire court, un architecte, c'est un gars qui sait programmer. Quelqu'un qui adore ça. Curieux et ouvert, ce quelqu'un se doit de concevoir un système non pas pour se faire plaisir, mais pour qu'il soit à la fois propre, évolutif sans être non plus sur-conçu ^[2] et le plus simple possible à utiliser.

Je pense donc qu'un architecte (informatique) doit savoir programmer. En fait, je pense même plus précisément qu'un architecte n'est finalement qu'un bon programmeur. Et il doit continuer à coder, toujours, sinon il ne peut plus prétendre être architecte, c'est aussi simple que ça : comment une personne peut-elle oser (pro)poser des règles si ce ne sont pas celles qu'il utilise tous les jours et dont il est convaincu du bien fondé ?

Plusieurs articles vont dans ce sens. D'abord, le célèbre anti-pattern ArchitectsDontCode, demandant notamment :

How can someone who never writes a line of code be responsible for how that code will be written?

ou en français :

Comment quelqu'un qui n'écrit jamais une ligne de code peut-il être responsable de comment ce code sera écrit ?

En fait, il y a une différence importante entre un architecte du bâtiment et celui de l'informatique. C'est d'ailleurs le sujet d'un article de Martin Fowler :

A software architect is seen as a chief designer, someone who pulls together everything on the project. But this is not what a building architect does. A building architect concentrates on the interaction with client who wants the building. [...] Given the focus on client interaction I think the closest equivalent in software development is a user-interface designer.

Le travail d'un architecte logiciel

• Via a19s, les erreurs les plus courantes des "architectes". Everybody Hates Architects. Écrit sur un ton humoristique qui le rend très agréable à lire, ce billet donne néanmoins des points très intéressants. Un qui me touche particulièrement

Do You Talk A Lot? Then Just Shut Up - Have a nominated day where you don't try to take over a conversation with either Technology, Patterns or some hair-brained new idea you've had that involves something you read in the new MSDN magazine regarding vector graphics on a device implanted inside the human skull using web services. Find the person on your team that you talk to the least, and spend some time listening to what they do and how they do it. Really try to just shut up and listen. If you don't want to be the software world's equivalent of a corridor bogey man, then practice some humility as often as you can. An occupational hazard of all that zippy confidence and rapid mouth action is that you'll be blind-sided when the day comes that you didn't listen enough.

• Autre aspect, issu du non moins célèbre « Who needs an architect? » de Martin Fowler (encore lui), à propos du architectus oryzus :

This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem.

Ce billet n'est évidemment en rien exhaustif, mais il a le mérite de m'avoir permis de vous donner les quelques liens que je trouvais intéressants ci-dessus :).